[Mesa-dev] [PATCH] mesa: rename MESA format names to have the same names as PIPE formats

[Mark Mueller]

On Thu, Dec 26, 2013 at 6:57 PM, Michel Dänzer <michel at daenzer.net> wrote:

> On Mit, 2013-12-25 at 20:35 -0800, Mark Mueller wrote:
>
> > On Wed, Dec 25, 2013 at 7:25 PM, Michel Dänzer <michel at daenzer.net>
> > wrote:
> >         On Mit, 2013-12-25 at 15:19 -0800, Mark Mueller wrote:
> >         >
> >         > ----------    Format Base Type P: Packed  ----------
> >         > MESA_FORMAT_[[component list,bit width][storage
> >         type*][_]][_][storage
> >         > type**]
> >         >  * when type differs between component
> >         >  ** when type applies to all components
> >         >
> >         >
> >         > examples:
> >         > MESA_FORMAT_R5G6B5_UNORM              /* RRRR RGGG GGGB BBBB
> >         */
> >         >
> >         > MESA_FORMAT_B4G4R4X4_UNORM          /* BBBB GGGG RRRR XXXX
> >         */
> >
> >         This is slightly confusing in that the PIPE_FORMATs use this
> >         convention
> >         for naming the components of 'array' formats, packed formats
> >         use
> >         BGRXnnnn (just like packed MESA_FORMATs do now). Beware that
> >         not all
> >         PIPE_FORMATs have been updated yet according to that
> >         distinction.
> >
> > Is this what you are suggesting then?
> >
> >
> > ----------    Format Base Type P: Packed  ----------
> > MESA_FORMAT_[[component list][bit width per component]_[storage
> > type*]][_][storage type**]
> >  * when type differs between component
> >  ** when type applies to all components
> >
> >
> > examples:
> > MESA_FORMAT_RGB565_UNORM              /* RRRR RGGG GGGB BBBB */
> > MESA_FORMAT_BGRX4444_UNORM          /* BBBB GGGG RRRR XXXX */
> > MESA_FORMAT_Z32_FLOAT_SX824_UINT
> > MESA_FORMAT_RGBA1010102_UINT
> > MESA_FORMAT_RGBE9995_FLOAT
>
> That would be more consistent with the current PIPE_FORMAT naming
> convention, but some of the component size sequences look a bit weird,
> your original proposal actually makes more sense for those...
>
> Sorry, I'm not sure which original proposal you are referring to, could
you be more specific? My concern about this latest iteration is that the
delimiter between bit widths per component isn't distinct, though it's
generally intuitive, whereas a component followed by a bit width gives a
clearer association.

>
> >         I'm afraid there also needs to be a way to encode endianness,
> >         either
> >         explicitly or via something like _REV to indicate the inverse
> >         byte order
> >         of the host byte order. This would apply to the packed values
> >         as a whole
> >         and to any multi-byte components of array formats.
> >
> >
> > I have seen the gallium discussion on this. Since my current focus is
> > i965, I'm safely immune from big endian problems and I'm not aware of
> > the details around the issue. Is it not sufficient to maintain a flag
> > within the individual texture object or image, or a global flag per
> > context to indicate host big endianess?
>
> Maybe? Hard to be sure without actually trying it and working out all
> the issues.
>
>
Since the endianess issue is still in flux, and the format naming work
doesn't offer a silver bullet, my recommendation is to solve the two
problems independently. Thus I can produce a new set of patches based on
the naming spec tomorrow for another round or review.

Mark



> --
> Earthling Michel Dänzer            |                  http://www.amd.com
> Libre software enthusiast          |                Mesa and X developer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131226/287f5e16/attachment-0001.html>