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

[Brian Paul]

On 03/22/2015 05:50 PM, Matthew Dawson wrote:
> 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.

Yes, the current raster texcoord (and secondary color and fogcoord, etc) 
is applied to every fragment of the glDrawPixels image, so having 
texturing enabled when calling glDrawPixels() is rather pointless and 
can produce unexpected results.


> 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.

FWIW, this should all work correctly with swrast but it's probably not 
done correctly in the state tracker.  It's always been a low priority 
item and, frankly, nobody has ever complained or filed a bug against it.


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

As Roland said, see the ctx->Current.Raster* fields.

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

If this is all about fixing the piglit draw-pixel-with-texture test, I'm 
not sure it's worthwhile.  As I said, it's a "feature" that few people 
care about.

There definitely are apps out there that use glDrawPixels() (a fair 
number of CAD apps) but luckily they don't depend on glDrawPixels with 
some strange application of texture or fog.

-Brian