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

Mark Mueller markkmueller at gmail.com
Tue Dec 17 18:50:13 PST 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131217/2c1b299c/attachment.html>


More information about the mesa-dev mailing list