<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 25, 2013 at 7:25 PM, Michel Dänzer <span dir="ltr"><<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</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">On Mit, 2013-12-25 at 15:19 -0800, Mark Mueller wrote:<br>


><br>
> ----------    Format Base Type P: Packed  ----------<br>
> MESA_FORMAT_[[component list,bit width][storage type*][_]][_][storage<br>
> type**]<br>
>  * when type differs between component<br>
>  ** when type applies to all components<br>
><br>
><br>
> examples:<br>
> MESA_FORMAT_R5G6B5_UNORM              /* RRRR RGGG GGGB BBBB */<br>
><br>
> MESA_FORMAT_B4G4R4X4_UNORM          /* BBBB GGGG RRRR XXXX */<br>
<br>
This is slightly confusing in that the PIPE_FORMATs use this convention<br>
for naming the components of 'array' formats, packed formats use<br>
BGRXnnnn (just like packed MESA_FORMATs do now). Beware that not all<br>
PIPE_FORMATs have been updated yet according to that distinction.<br></blockquote><div><br></div><div><br></div><div>Is this what you are suggesting then?</div><div><br></div><div style="font-family:arial,sans-serif;font-size:13px">
----------    Format Base Type P: Packed  ----------</div>
<div style="font-family:arial,sans-serif;font-size:13px">MESA_FORMAT_[[component list][bit width per component]_[storage type*]][_][storage type**]</div><div style="font-family:arial,sans-serif;font-size:13px"> * when type differs between component</div>

<div style="font-family:arial,sans-serif;font-size:13px"> ** when type applies to all components</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">

examples: </div><div style="font-family:arial,sans-serif;font-size:13px">MESA_FORMAT_RGB565_UNORM              /* RRRR RGGG GGGB BBBB */<br></div><div style="font-family:arial,sans-serif;font-size:13px">MESA_FORMAT_BGRX4444_UNORM          /* BBBB GGGG RRRR XXXX */<br>

</div><div style="font-family:arial,sans-serif;font-size:13px">MESA_FORMAT_Z32_FLOAT_SX824_UINT<br></div><div style="font-family:arial,sans-serif;font-size:13px">MESA_FORMAT_RGBA1010102_UINT<br></div><div style="font-family:arial,sans-serif;font-size:13px">

MESA_FORMAT_RGBE9995_FLOAT<br></div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px"><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>
I'm afraid there also needs to be a way to encode endianness, either<br>
explicitly or via something like _REV to indicate the inverse byte order<br>
of the host byte order. This would apply to the packed values as a whole<br>
and to any multi-byte components of array formats.<br></blockquote><div><br></div><div>I have seen the gallium discussion on this. Since my current focus is i965, I'm safely immune from big endian problems and I'm not aware of the details around the issue. Is it not sufficient to maintain a flag within the individual texture object or image, or a global flag per context to indicate host big endianess?</div>
<div><br></div><div>My work with cleaning up the mesa format names is a precursor to adding more formats without associated pack and unpack functions (in other words, beyond MESA_FORMAT_COUNT). If a slew of big endian formats need to be added, they could be included in the same way.</div>
<div><br></div><div>Mark</div><div></div></div></div><div class="gmail_extra"><br></div></div>