<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 26, 2013 at 6:57 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mit, 2013-12-25 at 20:35 -0800, Mark Mueller wrote:<br>
<br>
> On Wed, Dec 25, 2013 at 7:25 PM, Michel Dänzer <<a href="mailto:michel@daenzer.net">michel@daenzer.net</a>><br>
> wrote:<br>
> 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<br>
> 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>
> ><br>
> > MESA_FORMAT_B4G4R4X4_UNORM /* BBBB GGGG RRRR XXXX<br>
> */<br>
><br>
> This is slightly confusing in that the PIPE_FORMATs use this<br>
> convention<br>
> for naming the components of 'array' formats, packed formats<br>
> use<br>
> BGRXnnnn (just like packed MESA_FORMATs do now). Beware that<br>
> not all<br>
> PIPE_FORMATs have been updated yet according to that<br>
> distinction.<br>
><br>
> Is this what you are suggesting then?<br>
><br>
><br>
> ---------- Format Base Type P: Packed ----------<br>
> MESA_FORMAT_[[component list][bit width per component]_[storage<br>
> type*]][_][storage type**]<br>
> * when type differs between component<br>
> ** when type applies to all components<br>
><br>
><br>
> examples:<br>
> MESA_FORMAT_RGB565_UNORM /* RRRR RGGG GGGB BBBB */<br>
> MESA_FORMAT_BGRX4444_UNORM /* BBBB GGGG RRRR XXXX */<br>
> MESA_FORMAT_Z32_FLOAT_SX824_UINT<br>
> MESA_FORMAT_RGBA1010102_UINT<br>
> MESA_FORMAT_RGBE9995_FLOAT<br>
<br>
</div></div>That would be more consistent with the current PIPE_FORMAT naming<br>
convention, but some of the component size sequences look a bit weird,<br>
your original proposal actually makes more sense for those...<br>
<div class="im"><br></div></blockquote><div>Sorry, I'm not sure which original proposal you are referring to, could you be more specific? My concern about this latest iteration is that the delimiter between bit widths per component isn't distinct, though it's generally intuitive, whereas a component followed by a bit width gives a clearer association. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
> I'm afraid there also needs to be a way to encode endianness,<br>
> either<br>
> explicitly or via something like _REV to indicate the inverse<br>
> byte order<br>
> of the host byte order. This would apply to the packed values<br>
> as a whole<br>
> and to any multi-byte components of array formats.<br>
><br>
><br>
> I have seen the gallium discussion on this. Since my current focus is<br>
> i965, I'm safely immune from big endian problems and I'm not aware of<br>
> the details around the issue. Is it not sufficient to maintain a flag<br>
> within the individual texture object or image, or a global flag per<br>
> context to indicate host big endianess?<br>
<br>
</div>Maybe? Hard to be sure without actually trying it and working out all<br>
the issues.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div> </div><div>Since the endianess issue is still in flux, and the format naming work doesn't offer a silver bullet, my recommendation is to solve the two problems independently. Thus I can produce a new set of patches based on the naming spec tomorrow for another round or review.</div>
<div><br></div><div>Mark</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
<br>
--<br>
Earthling Michel Dänzer | <a href="http://www.amd.com" target="_blank">http://www.amd.com</a><br>
Libre software enthusiast | Mesa and X developer<br>
<br>
</div></div></blockquote></div><br></div></div>