[Mesa-dev] [PATCH v2] mesa: Fix swizzling for luminance/intensity in _mesa_readpixels

[Kenneth Graunke]

On Wednesday, August 2, 2017 3:28:23 AM PDT Nicolai Hähnle wrote:
> On 01.08.2017 00:15, Chris Wilson wrote:
> > Quoting Chris Wilson (2017-07-31 22:51:25)
> >> Luminance/Intensity when converted to RGB should be replicated to fill
> >> the RGB channels, but they differ on how the alpha channel is filled, as
> >> luminance is set to 1 (unless alpha is supplied) and intensity is
> >> replicated into alpha as well.
> >>
> >> https://www.khronos.org/opengl/wiki/Image_Format:
> >>
> >>      Legacy Image Formats
> >>
> >>      Warning: This section describes legacy OpenGL APIs that have been
> >>      removed from core OpenGL 3.1 and above (they are only deprecated in
> >>      OpenGL 3.0). It is recommended that you not use this functionality in
> >>      your programs.
> >>
> >>      As with other deprecated functionality, it is advised that you not rely
> >>      on these features.
> >>
> >>      Luminance and intensity formats are color formats. They are one or two
> >>      channel formats like RED or RG, but they specify particular behavior.
> >>
> >>      When a GL_RED format is sampled in a shader, the resulting vec4 is (Red,
> >>      0, 0, 1). When a GL_INTENSITY format is sampled, the resulting vec4 is
> >>      (I, I, I, I). The single intensity value is read into all four
> >>      components. For GL_LUMINANCE, the result is (L, L, L, 1). There is also
> >>      a two-channel GL_LUMINANCE_ALPHA format, which gives (L, L, L, A).
> >>
> >> v2: luminance -> xxx1, intensity -> xxxx, luminance_alpha -> xxxw
> > 
> > If that quote is the expected behaviour for glReadPixels and
> > glGetTexSubImage, there's a similar stanza to fix in texgetimage.c
> > (As well as the piglit tests to update.)
> > 
> > With a quick grep through VK-GL-CTS I didn't anything to refer to.
> 
> Is it even possible to have an L/I texture bound as a framebuffer? I 
> would expect an attempt to do that to fail the color-renderability check.

I'm pretty sure you can, and people do.  I'm not seeing it listed as a
required color renderable format, though...

> Do you have a real application that tries to do this? If not, I'd rather 
> we reject such attempts and maybe add a piglit test to that effect if it 
> doesn't exist -- and then get rid of this code in readpix.c entirely.
> 
> I think you're right though that texgetimage.c needs to support this.

I'm not so sure.  Table 8.25 of the GL 4.4 compatibility spec (page 257),
below glGetTexImage, shows this:

   +--------------------------------------------+
   |  Base Internal Format  | R  | G  | B  | A  |
   +--------------------------------------------+
   | ALPHA                  | 0  | 0  | 0  | Ai |
   | LUMINANCE (or 1)       | Li | 0  | 0  | 1  |
   | LUMINANCE_ALPHA (or 2) | Li | 0  | 0  | Ai |
   | INTENSITY              | Ii | 0  | 0  | 1  |
   | RED                    | Ri | 0  | 0  | 1  |
   | RG                     | Ri | Gi | 0  | 1  |
   | RGB (or 3)             | Ri | Gi | Bi | 1  |
   | RGBA (or 4)            | Ri | Gi | Bi | Ai | 
   +--------------------------------------------+

which indicates that the current bizarre <R, 0, 0, 1 or A> behavior
might actually be correct for glGetTexImage (?)

Once again, luminance and intensity formats make absolutely no sense...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170802/ca44adb1/attachment.sig>