Ian Romanick wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brian Paul wrote:
It's been a long time since I've looked at this stuff, but I'm not sure
that __glXImageSize() is correct. Specifically, the last part of the
function:
[...]
if (imageHeight > 0) {
imageSize = (imageHeight + skipRows) * rowSize;
} else {
imageSize = (h + skipRows) * rowSize;
}
return ((d + skipImages) * imageSize);
}
}
Why do skipRows and skipImages factor into the image size? I believe
the dimensions of the image going over the wire is W * H * D. The
skipRows and skipImages (and skipPixels) values just describe where to
find the W*H*D image inside of a larger image.
This will require some investigation. That particular block of code has
been in the server-side GLX code since day 1.
I guess it's been working then since the skip values have been zero,
as you point out below.
See figure 3.8 on page 131 of the OpenGL 2.0 specification for a diagram.
I looked that information up in the glPixelStore man page in order to
write the comment before __glXImageSize. :)
Consider a scenario in which you're replacing a single texel in a 3D
texture map. You've got a W*H*D 3D texture that in malloc'd memory
which you previously uploaded with glTexImage3D. To upload a single
changed texel in that volume at (x,y,z) you'd set
GL_UNPACK_SKIP_PIXELS=x, GL_UNPACK_SKIP_ROWS=y, and
GL_UNPACK_SKIP_IMAGES=z then call glTexSubImage3D(target, level, x, y,
z, 1, 1, 1, type, volume).
Over the wire, we should send a single texel so the result of
__glXImageSize should be pretty small. The __glFillImage() command on
the client side doesn't seem to use SKIP_ROWS or SKIP_IMAGES in the way
that __glXImageSize does.
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.
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.
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.
-Brian
-------------------------------------------------------
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
