----- 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 < 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 > 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 > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
