<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 17, 2014 at 1:24 PM, Marek Olšák <span dir="ltr"><<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Incorrect. You have to manually check if the pack and unpack functions<br> access the components using bitwise operations or arrays.<br> <br> Consider char pix[]. The array formats use arrays for accessing, for example:<br> <br> char *p = &pix[(y*width+x)*4];<br> p[0] = r;<br> p[1] = g;<br> p[2] = b;<br> p[3] = a;<br> <br> Packed formats use bitwise operators for accessing, for example:<br> <br> uint32_t *p = &pix[(y*width+x)*4];<br> *p = r | (g << 8) | (b << 16) | (a << 24);<br></blockquote><div><br></div><div>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.</div> <div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br> <br> It's okay to have both RGBA8 array and packed formats. For example,<br> Gallium has these array formats:<br> PIPE_FORMAT_R8G8B8A8_UNORM<br> PIPE_FORMAT_B8G8R8A8_UNORM<br> PIPE_FORMAT_A8R8G8B8_UNORM<br> PIPE_FORMAT_A8B8G8R8_UNORM<br> <br> And it defines these packed formats by using the array formats<br> according to the CPU architecture:<br> <br> #if defined(PIPE_ARCH_LITTLE_ENDIAN)<br> #define PIPE_FORMAT_RGBA8888_UNORM PIPE_FORMAT_R8G8B8A8_UNORM<br> #define PIPE_FORMAT_BGRA8888_UNORM PIPE_FORMAT_B8G8R8A8_UNORM<br> #define PIPE_FORMAT_ARGB8888_UNORM PIPE_FORMAT_A8R8G8B8_UNORM<br> #define PIPE_FORMAT_ABGR8888_UNORM PIPE_FORMAT_A8B8G8R8_UNORM<br> #elif defined(PIPE_ARCH_BIG_ENDIAN)<br> #define PIPE_FORMAT_ABGR8888_UNORM PIPE_FORMAT_R8G8B8A8_UNORM<br> #define PIPE_FORMAT_ARGB8888_UNORM PIPE_FORMAT_B8G8R8A8_UNORM<br> #define PIPE_FORMAT_BGRA8888_UNORM PIPE_FORMAT_A8R8G8B8_UNORM<br> #define PIPE_FORMAT_RGBA8888_UNORM PIPE_FORMAT_A8B8G8R8_UNORM<br> #endif<br> <br> This way, Gallium has all the possible RGBA8 array formats and also<br> the possible RGBA8 packed formats, so we can use whatever we want.<br></blockquote><div><br></div><div>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:</div> <div><br></div><div><div>/*</div><div> * Define endian-invariant aliases for some mesa formats that are</div><div> * defined in terms of their channel layout from LSB to MSB in a</div><div> * 32-bit word. The actual byte offsets matter here because the user</div> <div> * is allowed to bit-cast one format into another and get predictable</div><div> * results.</div><div> */</div><div>#ifdef MESA_BIG_ENDIAN</div><div># define MESA_FORMAT_RGBA_8 MESA_FORMAT_A8B8G8R8_UNORM</div><div># define MESA_FORMAT_RG_16 MESA_FORMAT_G16R16_UNORM</div> <div># define MESA_FORMAT_RG_8 MESA_FORMAT_G8R8_UNORM</div><div># define MESA_FORMAT_SIGNED_RGBA_8 MESA_FORMAT_A8B8G8R8_SNORM</div><div># define MESA_FORMAT_SIGNED_RG_16 MESA_FORMAT_G16R16_SNORM</div><div># define MESA_FORMAT_SIGNED_RG_8 MESA_FORMAT_G8R8_SNORM</div> <div>#else</div><div># define MESA_FORMAT_RGBA_8 MESA_FORMAT_R8G8B8A8_UNORM</div><div># define MESA_FORMAT_RG_16 MESA_FORMAT_R16G16_UNORM</div><div># define MESA_FORMAT_RG_8 MESA_FORMAT_R8G8_UNORM</div><div># define MESA_FORMAT_SIGNED_RGBA_8 MESA_FORMAT_R8G8B8A8_SNORM</div> <div># define MESA_FORMAT_SIGNED_RG_16 MESA_FORMAT_R16G16_SNORM</div><div># define MESA_FORMAT_SIGNED_RG_8 MESA_FORMAT_R8G8_SNORM</div><div>#endif</div></div><div><br></div><div><br></div><div>Mark</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <span><font color="#888888"><br> Marek<br> </font></span><div><div><br> On Fri, Jan 17, 2014 at 9:41 PM, Mark Mueller <<a href="mailto:markkmueller@gmail.com" target="_blank">markkmueller@gmail.com</a>> wrote:<br> ><br> ><br> ><br> > On Fri, Jan 17, 2014 at 8:58 AM, Brian Paul <<a href="mailto:brianp@vmware.com" target="_blank">brianp@vmware.com</a>> wrote:<br> >><br> >> On 01/17/2014 03:45 AM, Mark Mueller wrote:<br> >>><br> >>> Change all 4 color component unsigned byte formats to meet spec:<br> >>> s/MESA_FORMAT_RGBA8888\b/MESA_FORMAT_ABGR_UNORM8/g<br> >>> s/MESA_FORMAT_RGBA8888_REV\b/MESA_FORMAT_RGBA_UNORM8/g<br> >>> s/MESA_FORMAT_ARGB8888\b/MESA_FORMAT_BGRA_UNORM8/g<br> >>> s/MESA_FORMAT_ARGB8888_REV\b/MESA_FORMAT_ARGB_UNORM8/g<br> >>> s/MESA_FORMAT_RGBX8888\b/MESA_FORMAT_XBGR_UNORM8/g<br> >>> s/MESA_FORMAT_RGBX8888_REV\b/MESA_FORMAT_RGBX_UNORM8/g<br> >>> s/MESA_FORMAT_XRGB8888\b/MESA_FORMAT_BGRX_UNORM8/g<br> >>> s/MESA_FORMAT_XRGB8888_REV\b/MESA_FORMAT_XRGB_UNORM8/g<br> >>><br> >><br> >><br> >> I'm not sure this is right. If you look at the existing code such as<br> >> src/mesa/main/format_{un}pack.c you'll see that these formats are treated as<br> >> packed formats, not arrays.<br> >><br> ><br> > Ah. Array formats are really rare with OGL, that was unexpected but now<br> > really ancient issues with memory throughput optimization are surfacing.<br> > Those were the days.<br> ><br> > Thus Array Types would only include the much smaller group of all 32<br> > bit-per-component formats, and formats with an odd number of 8 or 16 bit<br> > components. Right?<br> ><br> > So the naming convention would be a derivation of MESA_FORMAT_R8G8B8A8_UNORM<br> > for these.<br> ><br> > Mark<br> ><br> ><br> </div></div><div><div>> _______________________________________________<br> > mesa-dev mailing list<br> > <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a><br> > <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br> ><br> </div></div></blockquote></div><br></div></div>