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

Mark Mueller markkmueller at gmail.com
Wed Dec 25 20:35:13 PST 2013


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




>
>
> 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?

My work with cleaning up the mesa format names is a precursor to adding
more formats without associated pack and unpack functions (in other words,
beyond MESA_FORMAT_COUNT). If a slew of big endian formats need to be
added, they could be included in the same way.

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


More information about the mesa-dev mailing list