I'd like to propose a draft naming convention for MESA_FORMATs, which, if we can agree on that, then other format systems can be brought to conformance on their own time, after the MESA_FORMATS are fixed.
First, there shall be 3 naming format base types: those for component array formats (type A); those for compressed formats (type C); and those for packed component formats (type P). All format names are defined in the mesa_format enum which is found in formats.h. Each format name shall begin with MESA_FORMAT_, followed by a component label (from the Component Label list below) for each component in the order that the component(s) occur in the format, except for non-linear color formats where the first letter shall be 'S'. For type P formats, each component label is followed by the number of bits that represent it in the fundamental data type used by the format. Following the listing of the component labels shall be an underscore; a compression type followed by an underscore for Type C formats only; a storage type from the list below; and a bit with for type A formats, which is the bit width for each array element. ---------- Format Base Type A: Array ---------- MESA_FORMAT_[component list]_[storage type][array element bit width] examples: MESA_FORMAT_A_SNORM8 /* uchar[i] = A */ MESA_FORMAT_RGBA_UNORM16 /* ushort[i * 4 + 0] = R, ushort[i * 4 + 1] = G, ushort[i * 4 + 2] = B, ushort[i * 4 + 3] = A */ MESA_FORMAT_Z_FLOAT32 /* float[i] = Z */ ---------- Format Base Type C: Compressed ---------- MESA_FORMAT_[component list*][_*][compression type][storage type*] * where required examples: MESA_FORMAT_RGB_ETC1 MESA_FORMAT_RGBA_ETC2 MESA_FORMAT_LATC1_UNORM MESA_FORMAT_RGBA_FXT1 ---------- 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 */ MESA_FORMAT_Z32_FLOAT_S8X24_UINT MESA_FORMAT_R10G10B10A2_UINT MESA_FORMAT_R9G9B9E5_FLOAT ---------- Component Labels: ---------- A - Alpha B - Blue DU - Delta U DV - Delta V E - Shared Exponent G - Green I - Intensity L - Luminescence R - Red S - Stencil (when not followed by RGB or RGBA) U - Chrominance V - Chrominance Y - Luma X - Packing bits Z - Depth ---------- Type C Compression Types: ---------- DXT1 - Color component labels shall be given DXT3 - Color component labels shall be given DXT5 - Color component labels shall be given ETC1 - No other information required ETC2 - No other information required FXT1 - Color component labels shall be included in name FXT3 - Color component labels shall be included in name LACT1 - fundamental data type shall be given LACT2 - fundamental data type shall be given ---------- Type A and P Storage Types: ---------- FLOAT SINT UINT SNORM UNORM Does this address all of the concerns? Mark On Wed, Dec 25, 2013 at 11:26 AM, Marek Olšák <mar...@gmail.com> wrote: > The motivation was to use the same names as Gallium and then to fix > the Gallium naming. Also, core Mesa is likely to share u_format tools > and code generation with Gallium eventually anyway and then all the > Mesa format pack and unpack functions will get removed. Given that, I > don't see a point in improving Mesa formats alone. > > Marek > > On Tue, Dec 24, 2013 at 4:57 AM, Michel Dänzer <mic...@daenzer.net> wrote: > > On Son, 2013-12-22 at 03:46 +0100, Marek Olšák wrote: > >> From: Marek Olšák <marek.ol...@amd.com> > >> > >> The renaming was driven by the function st_mesa_format_to_pipe_format. > >> Only whole words are renamed to prevent regressions. > >> > >> For the MESA formats which don't have corresponding PIPE formats, I > tried > >> to follow the PIPE_FORMAT_* conventions except for a few REV packed > formats, > >> whose renaming is left for a future patch. > > > > This patch conflicts with Mark's MESA_FORMAT patches, right? Can you > > guys work out which way you want to take this? :) > > > > > >> /* msb <------ TEXEL BITS -----------> > lsb */ > >> /* ---- ---- ---- ---- ---- ---- ---- > ---- */ > > [...] > >> + MESA_FORMAT_B8G8R8_UNORM, /* RRRR RRRR GGGG GGGG BBBB > BBBB */ > >> + MESA_FORMAT_R8G8B8_UNORM, /* BBBB BBBB GGGG GGGG RRRR > RRRR */ > > [...] > >> + MESA_FORMAT_R8G8B8_SRGB, /* RRRR RRRR GGGG GGGG BBBB > BBBB */ > > > > I guess these are examples of formats where Mark called out the memory > > layout documentation comments being wrong. These formats cannot be > > usefully defined as packed values, so the format names and comments > > should be changed to reflect that, e.g. per this example: > > > >> - MESA_FORMAT_SIGNED_RGB_16, /* ushort[0]=R, ushort[1]=G, > ushort[2]=B */ > > > > > >> - MESA_FORMAT_RGBA_FLOAT32, > >> - MESA_FORMAT_RGBA_FLOAT16, > >> - MESA_FORMAT_RGB_FLOAT32, > >> - MESA_FORMAT_RGB_FLOAT16, > > [...] > >> + MESA_FORMAT_R32G32B32A32_FLOAT, > >> + MESA_FORMAT_R16G16B16A16_FLOAT, > >> + MESA_FORMAT_R32G32B32_FLOAT, > >> + MESA_FORMAT_R16G16B16_FLOAT, > > > > [...] > > > >> - MESA_FORMAT_R_INT16, > >> - MESA_FORMAT_RG_INT16, > >> - MESA_FORMAT_RGB_INT16, > >> - MESA_FORMAT_RGBA_INT16, > >> - MESA_FORMAT_R_INT32, > >> - MESA_FORMAT_RG_INT32, > >> - MESA_FORMAT_RGB_INT32, > >> - MESA_FORMAT_RGBA_INT32, > > [...] > >> + MESA_FORMAT_R16_SINT, > >> + MESA_FORMAT_R16G16_SINT, > >> + MESA_FORMAT_R16G16B16_SINT, > >> + MESA_FORMAT_R16G16B16A16_SINT, > >> + MESA_FORMAT_R32_SINT, > >> + MESA_FORMAT_R32G32_SINT, > >> + MESA_FORMAT_R32G32B32_SINT, > >> + MESA_FORMAT_R32G32B32A32_SINT, > > > > These changes remove the naming distinction between formats which are > > defined as packed values and formats which are defined as arrays of > > values. I think that's a bad idea, there should be an explicit naming > > distinction between the two kinds of formats. > > > > > > -- > > 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
