1

Recently I looked into improving texture submissions for streaming and whatnot and despite my long searches I have not found any material presenting or even mentioning any way of using PBOs with DSA only functions.

Am I not looking in the right places or is there really no way as of yet?

vallentin
  • 23,478
  • 6
  • 59
  • 81
Jack Fenech
  • 108
  • 2
  • 7
  • I'm unclear as to what you're asking. Are you referring to transferring or simply DSA functions or both? Such as using `glMapNamedBuffer()` instead of `glMapBuffer()` ? – vallentin Apr 03 '17 at 05:21
  • Sorry, I'm really tired. If you look at slide 7 of this [presentation](http://on-demand.gputechconf.com/gtc/2012/presentations/S0356-GTC2012-Texture-Transfers.pdf) you'll see in order to do the transfer you have to do some binds in a particular order. I get there are equivalent DSA functions for these like glNamed*, but I was wondering if there was a way to explicitly bind these together like how the DSA equivalent of binding buffers to a VAO comes in the form of a set of functions which take in both the buffer name and the VAO name. – Jack Fenech Apr 03 '17 at 05:43

1 Answers1

2

All of the pixel transfer functions can take either a buffer object+offset or a client CPU pointer (unlike VAO functions, for example, which can only work with buffers now). As such, allowing you to pass a buffer object+offset directly would require having a separate entrypoint for each of the two ways of doing pixel transfer. So they would need glNamedReadPixelsToBuffer and glNamedReadPixelsToClient.

So instead of further proliferating the number of functions (and instead of forbidding using client memory), they make the buffer part work the way it always did: through a binding point. So yes, you're still going to have to bind that buffer to the PACK/UNPACK binding.

Since pixel transfers are not exactly a common operation (relative to the number of other kinds of state changing and rendering commands), and since these particular binds are not directly tied to the GPU, it shouldn't affect your code that much. Plus, there's already a lot of context state tied to pixel transfer operations; what does one more matter?

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
  • I am a bit confused by this: I thought that the pixel transfer function in this case is *glReadPixels* but it does not take a buffer object nor a CPU pointer (glMapBufferRange, which is not a pixel transferfunction) does. Can you clarify what you mean by "All of the pixel transfer functions can take either a buffer object+offset or a client CPU pointer"? – Startec Mar 05 '18 at 11:21
  • @Startec: "*it does not take a buffer object nor a CPU pointer*" [Yes, it does](https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glReadPixels.xhtml). – Nicol Bolas Mar 05 '18 at 14:32