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

Wed Dec 18 02:16:43 PST 2013

See Gallium PIPE_FORMATs. They all have consistent names. The
translation between Mesa and Gallium formats takes place in
st_format.c. I'm inclined to rename all Mesa formats to match the
Gallium names.

Marek

On Wed, Dec 18, 2013 at 3:50 AM, Mark Mueller <markkmueller at gmail.com> wrote:
>
>
>
> On Tue, Dec 17, 2013 at 12:19 PM, Mark Mueller <markkmueller at gmail.com>
> wrote:
>>
>>
>>
>>
>> On Sat, Nov 23, 2013 at 4:10 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>>
>>> On Sat, Nov 23, 2013 at 10:23 PM, Mark Mueller <markkmueller at gmail.com>
>>> wrote:
>>> >
>>> >
>>> >
>>> > On Sat, Nov 23, 2013 at 2:26 AM, Marek Olšák <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
>