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

[Jose Fonseca]

----- Original Message -----
> The predominant feedback on this adventure has been to make the MESA_FORMATs
> match the PIPE, or gallium formats but every journey I've made down that
> path has been fraught with peril. There are some cases where PIPE_FORMATs
> are even more confusing then MESA_FORMATs*. Either there is something that I
> am missing, or there are things about the PIPE_FORMATS that people aren't
> aware of, so let me pull out some specific references.
> 
> The first problem is that in PIPE_FORMATS there is no distinction between
> array and packed formats

This is not true anymore, at least not entirely.  There are the PIPE_FORMAT_XYZW1234_UNORM formats:

src/gallium/include/pipe/p_format.h:#define PIPE_FORMAT_RGBA8888_UNORM PIPE_FORMAT_R8G8B8A8_UNORM
src/gallium/include/pipe/p_format.h:#define PIPE_FORMAT_RGBA8888_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
[...]

and the hope to extend to other formats.

Jose



, and this has proven to be a big cause for format
> ambiguity that some are wanting to see addressed. One proposed solution is
> to represent array formats like (hypothetically): R8G8B8A8; and packed
> formats as RGBA_8888 (or vice versa) in the MESA_FORMATs and subsequently
> modifying the PIPE_FORMATs to suit. But that makes RGBA_1010102 kinda messy
> (though it could be RGBA_aaa2). So then how to handle this:
> 
> So how about a poll! Isn't that the rage these days?
> 
> Please vote on:
> 
> 1) Should MESA_FORMAT names clearly distinguish between array and packed
> formats, yes or no?
> 
> 2) What is your preference for array format naming convention:
> a) RGBA8888_UNORM
> b) R8G8B8A8_UNORM
> c) RGBA_UNORM8
> 
> 3) What is your preference for packed format naming convention:
> a) RGBA5551_UNORM
> b) R5G5B5A1_UNORM
> 
> 4) What is your preference for naming packed formats with 10 or more bits:
> a) RGBA1010102_UNORM
> b) R10G10B10A2_UNORM
> c) RGBAaaa2_UNORM
> d) Croque-monsieur
> 
> 
> Please vote just once!
> 
> Thanks,
> Mark
> 
> * code snip-it from p_format.h
> #if defined ( PIPE_ARCH_LITTLE_ENDIAN )
> #define PIPE_FORMAT_RGBA8888_UNORM PIPE_FORMAT_R8G8B8A8_UNORM
> #define PIPE_FORMAT_RGBX8888_UNORM PIPE_FORMAT_R8G8B8X8_UNORM
> #define PIPE_FORMAT_BGRA8888_UNORM PIPE_FORMAT_B8G8R8A8_UNORM
> #define PIPE_FORMAT_BGRX8888_UNORM PIPE_FORMAT_B8G8R8X8_UNORM
> #define PIPE_FORMAT_ARGB8888_UNORM PIPE_FORMAT_A8R8G8B8_UNORM
> #define PIPE_FORMAT_XRGB8888_UNORM PIPE_FORMAT_X8R8G8B8_UNORM
> #define PIPE_FORMAT_ABGR8888_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
> #define PIPE_FORMAT_XBGR8888_UNORM PIPE_FORMAT_X8B8G8R8_UNORM
> #elif defined ( PIPE_ARCH_BIG_ENDIAN )
> #define PIPE_FORMAT_ABGR8888_UNORM PIPE_FORMAT_R8G8B8A8_UNORM
> #define PIPE_FORMAT_XBGR8888_UNORM PIPE_FORMAT_R8G8B8X8_UNORM
> #define PIPE_FORMAT_XRGB8888_UNORM PIPE_FORMAT_B8G8R8X8_UNORM
> #define PIPE_FORMAT_ARGB8888_UNORM PIPE_FORMAT_B8G8R8A8_UNORM
> #define PIPE_FORMAT_XRGB8888_UNORM PIPE_FORMAT_B8G8R8X8_UNORM
> #define PIPE_FORMAT_BGRA8888_UNORM PIPE_FORMAT_A8R8G8B8_UNORM
> #define PIPE_FORMAT_BGRX8888_UNORM PIPE_FORMAT_X8R8G8B8_UNORM
> #define PIPE_FORMAT_RGBA8888_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
> #define PIPE_FORMAT_RGBX8888_UNORM PIPE_FORMAT_X8B8G8R8_UNORM
> #endif
> There is more below the surface here too because the above macros aren't
> employed consistently throughout the gallium drivers as best as I can tell.
> 
> 
> 
> On Thu, Dec 26, 2013 at 7:48 PM, Mark Mueller < markkmueller at gmail.com >
> wrote:
> 
> 
> 
> 
> 
> 
> 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
> 
> 
> 
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=P34HjAy2nt%2B51ZkAtPbSzhy3wkcSxNYCFBu%2BwMq%2F0BU%3D%0A&s=ae99117c6f4e83010af07bdb0a3253897d0074a33d3e2b3e6d3f1e451c9a2c59
>