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

[Mark Mueller]

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.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131217/db837fa1/attachment.html>