<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 18, 2013 at 7:36 AM, Brian Paul <span dir="ltr"><<a href="mailto:brianp@vmware.com" target="_blank">brianp@vmware.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>On 12/17/2013 07:50 PM, Mark Mueller wrote:<br>
</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>
<br>
<br>
<br>
On Tue, Dec 17, 2013 at 12:19 PM, Mark Mueller <<a href="mailto:markkmueller@gmail.com" target="_blank">markkmueller@gmail.com</a><br></div><div>
<mailto:<a href="mailto:markkmueller@gmail.com" target="_blank">markkmueller@gmail.com</a><u></u>>> wrote:<br>
<br>
<br>
<br>
<br>
On Sat, Nov 23, 2013 at 4:10 PM, Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a><br></div><div>
<mailto:<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>>> wrote:<br>
<br>
On Sat, Nov 23, 2013 at 10:23 PM, Mark Mueller<br></div><div>
<<a href="mailto:markkmueller@gmail.com" target="_blank">markkmueller@gmail.com</a> <mailto:<a href="mailto:markkmueller@gmail.com" target="_blank">markkmueller@gmail.com</a><u></u>>> wrote:<br>
><br>
><br>
><br>
> On Sat, Nov 23, 2013 at 2:26 AM, Marek Olšák<br></div><div>
<<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a> <mailto:<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>>> wrote:<br>
>><br>
<br>
<br></div></blockquote></blockquote><div><br></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">
<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><div>
<br>
<br>
OK, I think I've realized why this is so difficult. There are some<br>
MESA_FORMAT component orders that are counter to their OGL counterparts<br>
in name, and the same appears true for the bit count numberings.<br>
</div></blockquote>
<br>
Just FYI: there's no intention that MESA_FORMATs match any OpenGL format/type/internalFormat. MESA_FORMATs are intended to match what the hardware wants. Ideally, we hit TexImage/etc paths where the user-specified format/type/internalFormat exactly matches a MESA_FORMAT to avoid conversion/swizzling.<br>
<br>
Back in the early days of OpenGL, most OpenGL formats directly corresponded to SGI hardware formats. Over time, as PC GPUs arrived, newer formats (like GL_BGR[A]) were added.<br>
<br>
Throw in big vs. little endian issues and it's kind of a mess.<br>
<br>
<br>
<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">
For<br>
example these two cases in _mesa_choose_tex_format:<br>
<br>
case GL_BGRA:<br>
RETURN_IF_SUPPORTED(MESA_<u></u>FORMAT_ARGB8888);<br>
<br>
vs.<br>
<br>
case GL_RGBA32F_ARB:<br>
RETURN_IF_SUPPORTED(MESA_<u></u>FORMAT_RGBA_FLOAT32);<br>
</blockquote>
<br>
Part of the issue here is do you treat the pixel/texel as a packed value or as an array of values? Most of the 4-byte rgba formats expect texels to be treated as packed 4-byte words while the 16-byte floating point format is treated as an array of four floats. That leads to confusion too.<br>
<br>
<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">
<br>
<br>
and Mesa defines these:<br>
<br>
MESA_FORMAT_ARGB1555,/* ARRR RRGG GGGB BBBB */<br>
MESA_FORMAT_ARGB1555_REV,/* GGGB BBBB ARRR RRGG */<br>
<br>
while in OGL it's this way:<br>
GL_UNSIGNED_SHORT_5_5_5_1<br>
GL_UNSIGNED_SHORT_1_5_5_5_REV<br>
</blockquote>
<br>
Again, the apparent inconsistency comes from old OpenGL (SGI) conventions vs. PC hardware conventions.<br>
<br>
<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">
I'll modify my additions to better match Mesa's convention and hopefully<br>
that will clear a few things up. Or would it be better to fix this<br>
dilemma once and for all? I've heard Ken suggesting that that be done.<br>
It has been causing me so much grief that I'd _love_ to eliminate the<br>
problem but would rather move on if I can't get buy in.<br>
</blockquote>
<br>
I guess I'm still not clear on what the new MESA_FORMATs are supposed to represent? API/user-space data or hardware/GPU data? Or both?<br>
<br>
-Brian<br>
<br></blockquote><div class="gmail_quote"><br></div>Yes, the confusion is definitely deeper than the naming convention, which is all the more disorienting, but I can see many sound reasons for MESA_FORMATs to directly follow the API/user-space naming conventions:<br>
<div>- A vast majority of MESA_FORMATs already match their API/user-space compatriots, their primary role is to represent user-space data formats, and that is where their meta-data is most useful. </div><div><br></div><div>
- The PIPE_FORMATs and BRW_SURFACEFORMATS serve better for hardware/GPU specificity.</div><div><br></div><div>- The API formats are already well defined and documented, trying to reach a similar nirvana among the various hardware formats within MESA_FORMATs would be hard work.</div>
<div><br></div><div>- Hardware formats are opaque within core Mesa and they are vastly complex for orthogonal reasons (like formats that can be sampled from but not rendered to, along with 7 other parameters), so this opacity is a good thing. i965 uses BRW_SURFACEFORMATS which efficiently map to MESA_FORMATs and the _mesa_choose_tex_format methodology does a passable job at making it all work</div>
<div><br></div><div>- Modern hardware can efficiently handle most, if not all, formats thrown at it so today's limits are now completely defined and maintained by the API. Color component ordering is becoming irrelevant short of knowing the order it is received from user-space.</div>
<div><br></div><div><br></div><div>So is that convincing enough to justify a more direct mapping of MESA_FORMAT names to API names?</div><div><br></div><div>Mark</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></blockquote></div></div></div>