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, 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 <markkmuel...@gmail.com>wrote:
>
>
>
> On Thu, Dec 26, 2013 at 6:57 PM, Michel Dänzer <mic...@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 <mic...@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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
