Hi all, I've been working fixing the piglit tests around glDrawPixels, and I'm not sure what the correct behaviour of glDrawPixels is when any texturing units are enabled (tested with the draw-pixel-with-texture piglit test). After asking on irc, imirkin suggested I bring the issue here as it isn't clear how to proceed. I've tried to review the specification, and I have an idea, but I'm not sure if it is correct.
All of this is done against the OpenGL 3.0 specification (updated September 23, 2008), as that is what the old context reports for gallium swrast and radeonsi. This only covers the fixed function pipeline. According to figure 3.1, glDrawPixels (pixel rectangle rasterization in the diagram) output fragments do go through the regular fixed function fragment pipeline. The introduction for the rasterization chapter backs this up: "The color values assigned to a fragment are initially determined by the rasterization operations (sections 3.4 through 3.8) and modified by either the execution of the texturing, color sum, and fog operations defined in sections 3.9, 3.10, and 3.11, or by a fragment shader as defined in section 3.12. The final depth value is initially determined by the rasterization operations and may be modified or replaced by a fragment shader. The results from rasterizing a point, line, polygon, pixel rectangle or bitmap can be routed through a fragment shader." (pg 112). The question becomes how to implement this. There are two main problems: 1) How to input the pixel data into the texture stage 2) How to find the texture coordinates for sampling the textures. For problem 1, I think this is easily resolved. For the texturing side, the following paragraph says the fragment is passed through as is: "If all texturing is disabled, a rasterized fragment is passed on unaltered to the next stage of the GL (although its texture coordinates may be discarded). Otherwise, a texture value is found according to the parameter values of the currently bound texture image of the appropriate dimensionality using the rules given in sections 3.9.6 through 3.9.8. This texture value is used along with the incoming fragment in computing the texture function indicated by the currently bound texture environment. The result of this function replaces the incoming fragment’s primary R, G, B, and A values. These are the color values passed to subsequent operations. Other data associated with the incoming fragment remain unchanged, except that the texture coordinates may be discarded." (pg 227) To my understanding, this says as long as the output fragments in the glDrawPixels look like fragments from the primitive rasterization process, texturing occurs as normal. This leads into problem two, which is getting the texture coordinates for sampling the textures (along with getting a primary colour). For this, section 3.7.4 discusses building the fragments' output data. The relevant paragraph is: "A fragment arising from a group consisting of color data takes on the color index or color components of the group and the current raster position’s associated depth value, while a fragment arising from a depth component takes that component’s depth value and the current raster position’s associated color index or color components. In both cases, the fog coordinate is taken from the current raster position’s associated raster distance, the secondary color is taken from the current raster position’s associated secondary color, and texture coordinates are taken from the current raster position’s associated texture coordinates. Groups arising from DrawPixels with a format of DEPTH_STENCIL or STENCIL_INDEX are treated specially and are described in section 4.3.1 ." (pg 163) Which implies the colour is just the colour generated from the glDrawPixel's operations. The texture coordinates come from the raster position, but are not changed, and thus are *constant* over the entire rectangle rasterized in the process. This created the most confusion on IRC, since constant texture coordinates don't seem to make much sense. As best as I can understand, this is what the specification requires. So, does it make sense to move forward with this interpretation of the specification? Are they any errors in my understanding of the specification? If everything looks good, I have a patch to the draw-pixel-with-texture piglit test (with an update sitting on my computer) that tests this behaviour more thoroughly that I'd like to get committed. I also have a patch against the mesa state tracker to basically implement this behaviour (except for the texture coordinates). These patches deal with ~80% of the behaviour, enough to make piglit happy. As this is old behaviour, and I assume relatively unused, is it worth it to test and implement the other parts of the specification surrounding this behaviour? For instance, glBitmap includes similar language in its section that imply the same behaviour, but it is currently untested, and the programmable pipeline probably has some issues as well. Also, the raster position as used above is described in chapter 2.18. To properly implement the above, I need to get access to the raster position's state. However, I wasn't able to find it in my investigations of mesa. Is this currently implemented/tested, and if so where would I have to go to get access? If it isn't fully realized, is it worth it to test/implement this section, since its removed in the core profile? Would a reduced implementation to fix this test be OK (ignoring things like passing it through the vertex shader)? Thanks, -- Matthew
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev