On Fri, Jan 17, 2014 at 1:24 PM, Marek Olšák <mar...@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 <markkmuel...@gmail.com> > wrote: > > > > > > > > On Fri, Jan 17, 2014 at 8:58 AM, Brian Paul <bri...@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@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev