[Mesa-dev] [PATCH 1/1] Adjust MESA_FORMAT color component ordering to match API docs

[Mark Mueller]

On Thu, Dec 19, 2013 at 5:47 PM, Michel Dänzer <michel at daenzer.net> wrote:

> On Don, 2013-12-19 at 13:56 -0800, Mark Mueller wrote:
> > Adjust MESA_FORMAT color component ordering to match API docs, driver
> > specific formats (e.g. PIPE_FORMATs),
>
> Actually, there are a couple of examples of other format definitions
> which match the Mesa formats before your change but no longer after it,
> e.g. in the DRI and i915, nouveau and radeon driver code.
>

It's just not fair to hold the mesa formats to the varied conventions in
the DRI driver code because they are all over the place across all the
different drivers, past, present, and future (the confusion with
MESA_FORMATs may be partly to blame). Moving the mesa formats closer to
those of the API, instead of a nasty mix in-between,  brings at least some
clarity to the situation and the documentation burden can be left to the
API specs - minus a few outliers.

I'm pretty confident that this naming confusion is resulting in some
unnecessary texture re-packing work due to _mesa_choose_tex_format
returning less then optimal formats, though by name they look to be the
best choice. My next series attempts to address that.


> Changing the Mesa format definitions will be confusing for people
> switching between branches with and without your change.
>
> Also, because these Mesa formats are defined as packed values, you're
> essentially changing the notation from big endian (aka human readable)
> to little endian. It's unfortunate that the packed PIPE_FORMATs are
> named in little endian order, that's a concession we had to make when
> adding them.
>

Are they all really big endian, currently it looks like a mix of who knows
what. The main role the MESA_FORMATs are serving is to fortify the GLenums
coming from the API, which are close to useless on their own. I don't think
there is any question that there is a lack of convention and using the
conventions already provided by the API offers the best fit for lots of
reasons.



> Overall, I'm afraid this change doesn't look very good at all to me. At
> the very least though, you'd also have to change the order of component
> sizes for formats such as MESA_FORMAT_BGRA2101010_UNORM or
> MESA_FORMAT_BGRA1555_UNORM, otherwise they're just plain wrong.
>
>
> > and actual use on common platforms.
>
> What does that mean?
>

I'm referring to PIPE_FORMAT, BRW_SURFACEFORMAT, RADEON_TXFORMAT, etc here.

>
>
> > Remove comments giving MESA_FORMAT color packings, some of which are
> > misleading.
>
> Which ones are misleading, and how?
>

Bottom line, if the MESA_FORMATs follow the API's convention, then the
reader can go to the API for clarification and we don't have to maintain
that in the code. There are some special cases which can be dealt with in
the code.

>
>
> > diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h
> > index 94fc7a0..f224ed5 100644
> > --- a/src/mesa/main/formats.h
> > +++ b/src/mesa/main/formats.h
> > @@ -62,67 +62,68 @@ typedef enum
> >     MESA_FORMAT_NONE = 0,
> >
> >     /**
> > -    * \name Basic hardware formats
> > +    * \name Basic API user space data formats
>
> All of Mesa is in user space. :)


> > +    * Please refer to API documentation for more information on format
> > +    * packing
> >      */
>
> What API documentation?
>

opengl.org/wiki/Pixel_Transfer
opengl.org/wiki/Image_Format
http://msdn.microsoft.com/en-us/library/windows/desktop/bb172558(v=vs.85).aspx


>

Thanks for your input Michel. Do you still think this is a bad idea?

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