[Mesa-dev] Correct behaviour of glDrawPixels and glBitmap when texturing is enabled.

[Roland Scheidegger]

Am 23.03.2015 um 00:50 schrieb Matthew Dawson:
> 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?
I think the interpretation is correct. If it makes sense, I'm not so
sure :-). But this is all due to GL's odd definition of how glDrawPixels
work - takes into account just about all GL state, including current
vertex and fragment shaders, alpha state and so on, but all the inputs
mostly come from one source (the current raster pos).

> 
> 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.
Honestly, I've got some doubts this is worthwile to spend any time on.
Just about the only use of DrawPixels is usually for "put this bunch of
pixel data there", IIRC there were even apps which actually had bugs
because they forgot they'd need to disable things like alpha test etc.
because otherwise they'd not get the results they actually wanted.

> 
> 
> 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)?
> 

The raster pos tex coords should be in ctx->Current.RasterTexCoords[].
Can't answer the rest, I don't really care about correct DrawPixels
implementation, and unless you find some app which actually does
probably not many people are interested...

Roland