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

[Michel Dänzer]

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


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


-- 
Earthling Michel Dänzer            |                  http://www.amd.com
Libre software enthusiast          |                Mesa and X developer