-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Paul wrote: > Ian Romanick wrote: > >> This is one of the tricky / annoying parts of sending pixel data between >> the client and the server. The pixel pack / unpack settings are not >> stored as persistent state. They are included with each pixel transfer >> command. So, the protocol for glTexImage2D and glReadPixels embed all >> of the needed pixel storage information. What this means is that the >> sender of the data, be it the client or the server, can do whatever >> voodoo it wants on the data so long as it includes the pixel storage >> settings to correctly describe it. >> >> As it turns out, both sides in our implementation do all the packing / >> unpacking locally and send zeros for all three of these settings. > > I wonder why the GLX protocol was originally spec'd to pass all the > packing parameters with the command? I can understand the alignment and > byte-swapping parameters getting shipped along, but not the skip/stride > parameters.
I don't know. That was way before my time in the ARB. :) > The new twist to all this is pixel buffer objects. When a PBO is bound, > glRead/DrawPixels becomes a server-side-only operation; no pixel data > would get transferred over the wire. Did you start to look into the GLX > protocol for this at one point? Anyway, the pixel store parameters > become relevant on the server side in this scenario. As it turns out, there is protocol defined for glPixelStore[fi]. It's just not used by libGL. When ARB_pixel_buffer_object came up, I concluded that the right answer was to modify libGL to send glPixelStore[fi] protocol when the application calls those functions. On the server we'd have to make several modifications to the existing pixel functions. They would have to detect whether or not a pixel buffer object was being used. If not, they'd have to push PixelStore state, do the existing code, then pop PixelStore state. If a pixel buffer object was in use, they'd skip all the code that interacted with pixel store state and just call the relevant function (e.g., glDrawPixels, etc.). That was as far as I worked through it. It is somewhat moot. I got totally blocked on ARB_vertex_buffer_object protocol. Since the data sent to the server is an amorphous blob (as far as the protocol layers can tell), getting byte-ordering issues right is a major nightmare. Imagine the case where the client and server have a differing byte orders. Let's say the client is x86-64 and the server is PowerPC. The client calls glBufferData and sends a 2MB block of data to the server. The client then calls 'glVertexPointer(4, GL_FLOAT, 20, BUFFER_OFFSET(0))' and 'glColorPointer(4, GL_UNSIGNED_BYTE, 20, BUFFER_OFFEST(16))'. Now part of the buffer needs to be byte-swapped and part of it does not. Ouch. To make matters worse, imaging the app calls glReadPixels to load pixel data into the buffer. Swap the data or not? After that, the app calls glGetBufferSubData to read the data out of the buffer. Swap the data or not? Everytime I thought of a solution, I thought of a few more cases that would be broken. In the end, it gave me a bad head ache and I wandered off to write some code I could understand. >>> Ian, you should test this with the drawpix demo: decrease the image >>> height to about half by pressing 'h'. Then increase the skipRows value >>> by pressing 'R'. Things should blow up on the server side if the >>> __glXImageSize computation is wrong. >> >> I'll give that a try before I commit anything. > > The test should work if the client-side code is always setting the > skip/stride values to zeros/defaults. As you guessed, it worked perfectly. I've gone ahead and committed the patch, but we may end up revisiting this issue later. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDPxTyX1gOwKyEAw8RAqJuAJ4qy7pq55s3DNT7PJJ5CHnekVloewCgnAa6 SD+Z0fjWrGFj7lfoHFjnaik= =CSpv -----END PGP SIGNATURE----- ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
