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

Tue Dec 17 19:10:33 PST 2013

On 12/17/2013 06: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 - 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 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. 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);
> 
> 
> 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
> 
> 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.
> 
> Cheers,
> Mark

Mapping from GL to MESA_FORMAT to hardware formats has always confused
me - there does seem to be some inconsistency between MESA_FORMATs.  For
example, a bunch of the integer formats seem to use a different
convention than the unorm formats.

It would be great to:
1. Document the prevailing convention for MESA_FORMAT.
2. Document how it compares to GL and DX.
3. Fix formats to follow the convention, either one format at a time, or
a related group of formats that have the same problem.

It may be worth sending out any proposed renames before actually coding
it up, so people can discuss the convention.

--Ken