[Mesa-dev] [PATCH 1/2] mesa: Add gl_formats to cover all GLUser provided format/type combinations

Brian Paul brianp at vmware.com
Wed Dec 18 07:36:50 PST 2013 

On 12/17/2013 07:50 PM, Mark Mueller wrote:
>
>
>
> On Tue, Dec 17, 2013 at 12:19 PM, Mark Mueller <markkmueller at gmail.com
> <mailto:markkmueller at gmail.com>> wrote:
>
>
>
>
>     On Sat, Nov 23, 2013 at 4:10 PM, Marek Olšák <maraeo at gmail.com
>     <mailto:maraeo at gmail.com>> wrote:
>
>         On Sat, Nov 23, 2013 at 10:23 PM, Mark Mueller
>         <markkmueller at gmail.com <mailto:markkmueller at gmail.com>> wrote:
>          >
>          >
>          >
>          > On Sat, Nov 23, 2013 at 2:26 AM, Marek Olšák
>         <maraeo at gmail.com <mailto:maraeo at gmail.com>> wrote:
>          >>
>
>
>     [...]
>
>          >>
>          >> >    MESA_FORMAT_RGBA1555_REV,
>          >>
>          >> I don't think you can have R with 1 bit.
>          >>
>          >> >
>          >> >    /* Blue Green Red Alpha */
>          >> >    MESA_FORMAT_BGRA_INT8,
>          >> >    MESA_FORMAT_BGRA_INT8_REV,
>          >> >    MESA_FORMAT_BGRA_UINT8,
>          >> >    MESA_FORMAT_BGRA_INT16,
>          >> >    MESA_FORMAT_BGRA_UINT16,
>          >> >    MESA_FORMAT_BGRA_FLOAT16,
>          >> >    MESA_FORMAT_BGRA_INT32,
>          >> >    MESA_FORMAT_BGRA_UINT32,
>          >> >    MESA_FORMAT_BGRA_FLOAT32,
>          >> >    MESA_FORMAT_BGRA4444,
>          >> >    MESA_FORMAT_BGRA4444_REV,
>          >> >    MESA_FORMAT_BGRA5551,
>          >>
>          >> All these look good.
>          >>
>          >> >    MESA_FORMAT_BGRA1555_REV,
>          >>
>          >> I don't think you can have B with 1 bit.
>
>     Doesn't the _REV force A to be the first component, i.e. 1 bit? This
>     format is listed as valid in
>     http://www.opengl.org/wiki/Pixel_Transfer
>     <https://urldefense.proofpoint.com/v1/url?u=http://www.opengl.org/wiki/Pixel_Transfer&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=YqhEgUkmBDO%2B90crzawcdIBPS5y1FiM0BS%2FljcrWPrI%3D%0A&s=d19ac6c07923331addd8b21f7efab34b5ad7bc2560fbd2d51c9b392a4a1abb20>
>     - see below.
>
>          >>
>          >> >    MESA_FORMAT_BGRA1010102,
>          >>
>          >> This one looks good.
>          >>
>          >> >    MESA_FORMAT_BGRA2101010_REV,
>          >>
>          >> I don't think you can have B with 2 bits.
>
>
>     Same as above.
>
>          >>
>          >> >    MESA_FORMAT_BGRA5999_REV,
>          >>
>          >> This one doesn't exist either and cannot be specified by
>         TexImage.
>
>
>     You are correct according to the Pixel_Transfer spec, thanks.
>
>          >
>          >
>          > BGRAs and RGBAs were based on this from the spec:
>          > "GL_INVALID_OPERATION is generated if type is one of
>          > GL_UNSIGNED_SHORT_4_4_4_4, GL_UNSIGNED_SHORT_4_4_4_4_REV,
>          > GL_UNSIGNED_SHORT_5_5_5_1, GL_UNSIGNED_SHORT_1_5_5_5_REV,
>          > GL_UNSIGNED_INT_8_8_8_8, GL_UNSIGNED_INT_8_8_8_8_REV,
>          > GL_UNSIGNED_INT_10_10_10_2, GL_UNSIGNED_INT_2_10_10_10_REV, or
>          > GL_UNSIGNED_INT_5_9_9_9_REV, and format is neither GL_RGBA
>         nor GL_BGRA."
>
>         Nowhere can I see that B has 1 or 2 bits. Also the occurence of
>         GL_UNSIGNED_INT_5_9_9_9_REV seems to be a spec bug, because it
>         should
>         be GL_RGB (the 5 bits contain a shared exponent).
>
>
>     It does appear to be a spec bug. Here is a quote from
>     http://www.opengl.org/wiki/Pixel_Transfer
>     <https://urldefense.proofpoint.com/v1/url?u=http://www.opengl.org/wiki/Pixel_Transfer&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=YqhEgUkmBDO%2B90crzawcdIBPS5y1FiM0BS%2FljcrWPrI%3D%0A&s=d19ac6c07923331addd8b21f7efab34b5ad7bc2560fbd2d51c9b392a4a1abb20>
>     which addresses that an other issues above:
>
>     "OpenGL restricts the possible sizes. They are:
>     * 3_3_2 (2_3_3_REV): unsigned bytes. Only used with GL_RGB.
>
>     * 5_6_5 (5_6_5_REV): unsigned shorts. Only used with GL_RGB.
>
>     * 4_4_4_4 (4_4_4_4_REV): unsigned shorts.
>
>     * 5_5_5_1 (1_5_5_5_REV): unsigned shorts.
>
>     * 8_8_8_8 (8_8_8_8_REV): unsigned ints.
>
>     * 10_10_10_2 (2_10_10_10_REV): unsigned ints.
>
>     * 24_8 (no _REV): unsigned ints. Only used with GL_DEPTH_STENCIL​.
>
>     * 10F_11F_11F_REV (no non-REV): unsigned ints. These represent
>     floats, and can only be used with GL_RGB​. This should only be used
>     with images that have the GL_R11F_G11F_B10F​ image format.
>
>     * 5_9_9_9_REV (no non-REV): unsigned ints. Only used with GL_RGB​;
>     the last component (the 5. It's REV) does not directly map to a
>     color value. It is a shared exponent. Only use this with images that
>     have the GL_RGB9_E5​ image format."
>
>     I'm working on V2 of this patch with incorporation of Marek,
>     Brian's, and Roland's feedback. I have also made changes as a result
>     of further development and testing on the i965 GPU texture upload
>     work. I will be posting that shortly.
>
>     Thanks Marek.
>
>
> OK, I think I've realized why this is so difficult. There are some
> MESA_FORMAT component orders that are counter to their OGL counterparts
> in name, and the same appears true for the bit count numberings.

Just FYI: there's no intention that MESA_FORMATs match any OpenGL 
format/type/internalFormat.  MESA_FORMATs are intended to match what the 
hardware wants.  Ideally, we hit TexImage/etc paths where the 
user-specified format/type/internalFormat exactly matches a MESA_FORMAT 
to avoid conversion/swizzling.

Back in the early days of OpenGL, most OpenGL formats directly 
corresponded to SGI hardware formats.  Over time, as PC GPUs arrived, 
newer formats (like GL_BGR[A]) were added.

Throw in big vs. little endian issues and it's kind of a mess.



> For
> example these two cases in _mesa_choose_tex_format:
>
>     case GL_BGRA:
>        RETURN_IF_SUPPORTED(MESA_FORMAT_ARGB8888);
>
> vs.
>
>     case GL_RGBA32F_ARB:
>        RETURN_IF_SUPPORTED(MESA_FORMAT_RGBA_FLOAT32);

Part of the issue here is do you treat the pixel/texel as a packed value 
or as an array of values?  Most of the 4-byte rgba formats expect texels 
to be treated as packed 4-byte words while the 16-byte floating point 
format is treated as an array of four floats.  That leads to confusion too.


>
>
> and Mesa defines these:
>
>     MESA_FORMAT_ARGB1555,/*                     ARRR RRGG GGGB BBBB */
>     MESA_FORMAT_ARGB1555_REV,/*                     GGGB BBBB ARRR RRGG */
>
> while in OGL it's this way:
> GL_UNSIGNED_SHORT_5_5_5_1
> GL_UNSIGNED_SHORT_1_5_5_5_REV

Again, the apparent inconsistency comes from old OpenGL (SGI) 
conventions vs. PC hardware conventions.


> I'll modify my additions to better match Mesa's convention and hopefully
> that will clear a few things up. Or would it be better to fix this
> dilemma once and for all? I've heard Ken suggesting that that be done.
> It has been causing me so much grief that I'd _love_ to eliminate the
> problem but would rather move on if I can't get buy in.

I guess I'm still not clear on what the new MESA_FORMATs are supposed to 
represent?  API/user-space data or hardware/GPU data?  Or both?

-Brian

More information about the mesa-dev mailing list