<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 17, 2013 at 12:19 PM, Mark Mueller <span dir="ltr"><<a href="mailto:markkmueller@gmail.com" target="_blank">markkmueller@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"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">
<div>On Sat, Nov 23, 2013 at 4:10 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"><div><div>On Sat, Nov 23, 2013 at 10:23 PM, Mark Mueller <<a href="mailto:markkmueller@gmail.com" target="_blank">markkmueller@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Sat, Nov 23, 2013 at 2:26 AM, Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> wrote:<br>
>></div></div></blockquote><div><br></div></div><div>[...]</div><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">
<div><div>>><br>
</div></div><div><div>
>> > MESA_FORMAT_RGBA1555_REV,<br>
>><br>
>> I don't think you can have R with 1 bit.<br>
>><br>
>> ><br>
>> > /* Blue Green Red Alpha */<br>
>> > MESA_FORMAT_BGRA_INT8,<br>
>> > MESA_FORMAT_BGRA_INT8_REV,<br>
>> > MESA_FORMAT_BGRA_UINT8,<br>
>> > MESA_FORMAT_BGRA_INT16,<br>
>> > MESA_FORMAT_BGRA_UINT16,<br>
>> > MESA_FORMAT_BGRA_FLOAT16,<br>
>> > MESA_FORMAT_BGRA_INT32,<br>
>> > MESA_FORMAT_BGRA_UINT32,<br>
>> > MESA_FORMAT_BGRA_FLOAT32,<br>
>> > MESA_FORMAT_BGRA4444,<br>
>> > MESA_FORMAT_BGRA4444_REV,<br>
>> > MESA_FORMAT_BGRA5551,<br>
>><br>
>> All these look good.<br>
>><br>
>> > MESA_FORMAT_BGRA1555_REV,<br>
>><br>
>> I don't think you can have B with 1 bit.<br></div></div></blockquote><div> </div></div><div>Doesn't the _REV force A to be the first component, i.e. 1 bit? This format is listed as valid in <a href="http://www.opengl.org/wiki/Pixel_Transfer" target="_blank">http://www.opengl.org/wiki/Pixel_Transfer</a> - see below.</div>
<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"><div><div>
>><br>
>> > MESA_FORMAT_BGRA1010102,<br>
>><br>
>> This one looks good.<br>
>><br>
>> > MESA_FORMAT_BGRA2101010_REV,<br>
>><br>
>> I don't think you can have B with 2 bits.<br></div></div></blockquote><div><br></div></div><div>Same as above.</div><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">
<div><div>
>><br>
>> > MESA_FORMAT_BGRA5999_REV,<br>
>><br>
>> This one doesn't exist either and cannot be specified by TexImage.<br></div></div></blockquote><div><br></div></div><div>You are correct according to the Pixel_Transfer spec, thanks.</div><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">
<div><div>
><br>
><br>
> BGRAs and RGBAs were based on this from the spec:<br>
> "GL_INVALID_OPERATION is generated if type is one of<br>
> GL_UNSIGNED_SHORT_4_4_4_4, GL_UNSIGNED_SHORT_4_4_4_4_REV,<br>
> GL_UNSIGNED_SHORT_5_5_5_1, GL_UNSIGNED_SHORT_1_5_5_5_REV,<br>
> GL_UNSIGNED_INT_8_8_8_8, GL_UNSIGNED_INT_8_8_8_8_REV,<br>
> GL_UNSIGNED_INT_10_10_10_2, GL_UNSIGNED_INT_2_10_10_10_REV, or<br>
> GL_UNSIGNED_INT_5_9_9_9_REV, and format is neither GL_RGBA nor GL_BGRA."<br>
<br>
</div></div>Nowhere can I see that B has 1 or 2 bits. Also the occurence of<br>
GL_UNSIGNED_INT_5_9_9_9_REV seems to be a spec bug, because it should<br>
be GL_RGB (the 5 bits contain a shared exponent).<br></blockquote><div><br></div></div><div>It does appear to be a spec bug. Here is a quote from <a href="http://www.opengl.org/wiki/Pixel_Transfer" target="_blank">http://www.opengl.org/wiki/Pixel_Transfer</a> which addresses that an other issues above:</div>
<div><br></div><div>"OpenGL restricts the possible sizes. They are:</div><div>* 3_3_2 (2_3_3_REV): unsigned bytes. Only used with GL_RGB.</div><div><br></div><div>* 5_6_5 (5_6_5_REV): unsigned shorts. Only used with GL_RGB.</div>
<div><br></div><div>* 4_4_4_4 (4_4_4_4_REV): unsigned shorts.</div><div><br></div><div>* 5_5_5_1 (1_5_5_5_REV): unsigned shorts.</div><div><br></div><div>* 8_8_8_8 (8_8_8_8_REV): unsigned ints.</div><div><br></div><div>* 10_10_10_2 (2_10_10_10_REV): unsigned ints.</div>
<div><br></div><div>* 24_8 (no _REV): unsigned ints. Only used with GL_DEPTH_STENCIL.</div><div><br></div><div>* 10F_11F_11F_REV (no non-REV): unsigned ints. These represent floats, and can only be used with GL_RGB. This should only be used with images that have the GL_R11F_G11F_B10F image format.</div>
<div><br></div><div>* 5_9_9_9_REV (no non-REV): unsigned ints. Only used with GL_RGB; the last component (the 5. It's REV) does not directly map to a color value. It is a shared exponent. Only use this with images that have the GL_RGB9_E5 image format."</div>
<div><br></div><div> </div><div>I'm working on V2 of this patch with incorporation of Marek, Brian's, and Roland's feedback. I have also made changes as a result of further development and testing on the i965 GPU texture upload work. I will be posting that shortly.</div>
<div><br></div><div>Thanks Marek.</div><span><font color="#888888"><div><br></div></font></span></div></div></div></blockquote><div><br></div><div>OK, I think I've realized why this is so difficult. There are some MESA_FORMAT component orders that are counter to their OGL counterparts in name, and the same appears true for the bit count numberings. For example these two cases in _mesa_choose_tex_format:</div>
<div><br></div><div><div> case GL_BGRA:</div><div> RETURN_IF_SUPPORTED(MESA_FORMAT_ARGB8888);</div></div><div><br></div><div>vs.</div><div><br></div><div><div> case GL_RGBA32F_ARB:</div><div> RETURN_IF_SUPPORTED(MESA_FORMAT_RGBA_FLOAT32);</div>
</div><div><br></div><div><br></div><div>and Mesa defines these:</div><div><br></div><div><div> MESA_FORMAT_ARGB1555,<span class="" style="white-space:pre"> </span>/* ARRR RRGG GGGB BBBB */</div><div>
MESA_FORMAT_ARGB1555_REV,<span class="" style="white-space:pre"> </span>/* GGGB BBBB ARRR RRGG */</div></div><div><br></div><div>while in OGL it's this way:</div><div><font color="#000000" face="sans-serif"><span style="line-height:19.1875px">GL_UNSIGNED_SHORT_5_5_5_1</span></font><br>
</div><div><font color="#000000" face="sans-serif"><span style="line-height:19.1875px">GL_UNSIGNED_SHORT_1_5_5_5_REV</span></font><br></div><div><br></div><div>I'll modify my additions to better match Mesa's convention and hopefully that will clear a few things up. Or would it be better to fix this dilemma once and for all? I've heard Ken suggesting that that be done. It has been causing me so much grief that I'd _love_ to eliminate the problem but would rather move on if I can't get buy in.</div>
<div><br></div><div>Cheers,</div><div>Mark</div></div><br></div></div>