[Mesa-dev] [Bug 46631] It's really hard to hit the fast path for the fallback glReadPixels code

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=46631

--- Comment #8 from Neil Roberts <neil at linux.intel.com> 2012-02-26 13:41:46 UTC ---
Ok, I think I understand this a bit better now.

I think the problem is that Mesa is doing the wrong thing when converting from
the framebuffer format to the temporary floating point RGBA representation.
According to the GL 3.0 spec in the section on reading pixels, it says
“Internal components are converted to an RGBA color by taking each R, G, B, and
A component present according to the base internal format of the buffer (as
shown in table 3.15). If G, B, or A values are not present in the internal
format, they are taken to be zero, zero, and one respectively”. Table 3.15
shows that the L component of an internal luminance format maps to only the R
component. Mesa is currently mapping the luminance value to all three
components. You can see that on the proprietary Nvidia driver it only maps to
the R component because if you set the R scale to 0.0 when reading the pixels
you get 0.0 back for the luminance.

So I guess we could make a patch that changes the luminance functions in
format_unpack.c to only copy to the R component. However I'm not sure if this
will break other things because those functions are also used in a lot of other
places. It is clearly a separate bug though so for now I'll just make the
luminance patch obsolete and we can file another bug sometime.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.