[Mesa-dev] [V3 PATCH 2/8] mesa: Change 4 color component ubyte formats

[Mark Mueller]

On Fri, Jan 17, 2014 at 1:24 PM, Marek Olšák <maraeo at gmail.com> wrote:

> Incorrect. You have to manually check if the pack and unpack functions
> access the components using bitwise operations or arrays.
>
> Consider char pix[]. The array formats use arrays for accessing, for
> example:
>
> char *p = &pix[(y*width+x)*4];
> p[0] = r;
> p[1] = g;
> p[2] = b;
> p[3] = a;
>
> Packed formats use bitwise operators for accessing, for example:
>
> uint32_t *p = &pix[(y*width+x)*4];
> *p = r | (g << 8) | (b << 16) | (a << 24);
>

Hang on, that's precisely what I did and when I tallied up the results from
the manual inspection, the rule I provided below fit. For example, in
format_pack.c, any pack_ubyte function that does not use a PACK_COLOR_
macro is either 32 bits per component, or an odd number of components with
8 or 16 bits: MESA_FORMAT_R_UNORM8, MESA_FORMAT_RGB_UNORM8. I admit that I
messed one, which is 16 bit floats - those are arrays too.



>
>
> It's okay to have both RGBA8 array and packed formats. For example,
> Gallium has these array formats:
> PIPE_FORMAT_R8G8B8A8_UNORM
> PIPE_FORMAT_B8G8R8A8_UNORM
> PIPE_FORMAT_A8R8G8B8_UNORM
> PIPE_FORMAT_A8B8G8R8_UNORM
>
> And it defines these packed formats by using the array formats
> according to the CPU architecture:
>
> #if defined(PIPE_ARCH_LITTLE_ENDIAN)
> #define PIPE_FORMAT_RGBA8888_UNORM PIPE_FORMAT_R8G8B8A8_UNORM
> #define PIPE_FORMAT_BGRA8888_UNORM PIPE_FORMAT_B8G8R8A8_UNORM
> #define PIPE_FORMAT_ARGB8888_UNORM PIPE_FORMAT_A8R8G8B8_UNORM
> #define PIPE_FORMAT_ABGR8888_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
> #elif defined(PIPE_ARCH_BIG_ENDIAN)
> #define PIPE_FORMAT_ABGR8888_UNORM PIPE_FORMAT_R8G8B8A8_UNORM
> #define PIPE_FORMAT_ARGB8888_UNORM PIPE_FORMAT_B8G8R8A8_UNORM
> #define PIPE_FORMAT_BGRA8888_UNORM PIPE_FORMAT_A8R8G8B8_UNORM
> #define PIPE_FORMAT_RGBA8888_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
> #endif
>
> This way, Gallium has all the possible RGBA8 array formats and also
> the possible RGBA8 packed formats, so we can use whatever we want.
>

The MESA_FORMATs are used to literally tag the application's Internal
formats such that the driver can better know the application's intention
(admittedly I'm also looking beyond _mesa_choose_tex_format, but that is
for another time). The Array Type formats were proposed to indicate that
the component order is independent of endianess, whereas Packed Type
component orders _do_ depend on endianess. Acknowledging these Types is an
attempt to eradicate the confusion. I have no input about mixing types
within Gallium, but within Mesa my preference is to adhere to that
distinction. I find Francisco's method to be less confusing then Gallium's
(not just because of the helpful comment). Here it is with P Type formats:

/*
 * Define endian-invariant aliases for some mesa formats that are
 * defined in terms of their channel layout from LSB to MSB in a
 * 32-bit word.  The actual byte offsets matter here because the user
 * is allowed to bit-cast one format into another and get predictable
 * results.
 */
#ifdef MESA_BIG_ENDIAN
# define MESA_FORMAT_RGBA_8 MESA_FORMAT_A8B8G8R8_UNORM
# define MESA_FORMAT_RG_16 MESA_FORMAT_G16R16_UNORM
# define MESA_FORMAT_RG_8 MESA_FORMAT_G8R8_UNORM
# define MESA_FORMAT_SIGNED_RGBA_8 MESA_FORMAT_A8B8G8R8_SNORM
# define MESA_FORMAT_SIGNED_RG_16 MESA_FORMAT_G16R16_SNORM
# define MESA_FORMAT_SIGNED_RG_8 MESA_FORMAT_G8R8_SNORM
#else
# define MESA_FORMAT_RGBA_8 MESA_FORMAT_R8G8B8A8_UNORM
# define MESA_FORMAT_RG_16 MESA_FORMAT_R16G16_UNORM
# define MESA_FORMAT_RG_8 MESA_FORMAT_R8G8_UNORM
# define MESA_FORMAT_SIGNED_RGBA_8 MESA_FORMAT_R8G8B8A8_SNORM
# define MESA_FORMAT_SIGNED_RG_16 MESA_FORMAT_R16G16_SNORM
# define MESA_FORMAT_SIGNED_RG_8 MESA_FORMAT_R8G8_SNORM
#endif


Mark



>
> Marek
>
> On Fri, Jan 17, 2014 at 9:41 PM, Mark Mueller <markkmueller at gmail.com>
> wrote:
> >
> >
> >
> > On Fri, Jan 17, 2014 at 8:58 AM, Brian Paul <brianp at vmware.com> wrote:
> >>
> >> On 01/17/2014 03:45 AM, Mark Mueller wrote:
> >>>
> >>> Change all 4 color component unsigned byte formats to meet spec:
> >>>   s/MESA_FORMAT_RGBA8888\b/MESA_FORMAT_ABGR_UNORM8/g
> >>>   s/MESA_FORMAT_RGBA8888_REV\b/MESA_FORMAT_RGBA_UNORM8/g
> >>>   s/MESA_FORMAT_ARGB8888\b/MESA_FORMAT_BGRA_UNORM8/g
> >>>   s/MESA_FORMAT_ARGB8888_REV\b/MESA_FORMAT_ARGB_UNORM8/g
> >>>   s/MESA_FORMAT_RGBX8888\b/MESA_FORMAT_XBGR_UNORM8/g
> >>>   s/MESA_FORMAT_RGBX8888_REV\b/MESA_FORMAT_RGBX_UNORM8/g
> >>>   s/MESA_FORMAT_XRGB8888\b/MESA_FORMAT_BGRX_UNORM8/g
> >>>   s/MESA_FORMAT_XRGB8888_REV\b/MESA_FORMAT_XRGB_UNORM8/g
> >>>
> >>
> >>
> >> I'm not sure this is right.  If you look at the existing code such as
> >> src/mesa/main/format_{un}pack.c you'll see that these formats are
> treated as
> >> packed formats, not arrays.
> >>
> >
> > Ah. Array formats are really rare with OGL, that was unexpected but now
> > really ancient issues with memory throughput optimization are surfacing.
> > Those were the days.
> >
> > Thus Array Types would only include the much smaller group of all 32
> > bit-per-component formats, and formats with an odd number of 8 or 16 bit
> > components. Right?
> >
> > So the naming convention would be a derivation of
> MESA_FORMAT_R8G8B8A8_UNORM
> > for these.
> >
> > Mark
> >
> >
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140117/1fd40c0e/attachment-0001.html>