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

Wed Dec 25 15:19:15 PST 2013

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 <maraeo at 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 <michel at daenzer.net> wrote:
> > On Son, 2013-12-22 at 03:46 +0100, Marek Olšák wrote:
> >> From: Marek Olšák <marek.olsak at 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131225/31ab062b/attachment.html>