[Mesa-dev] [PATCH 1/2] mesa: Add gl_formats to cover all GLUser provided format/type combinations

[Mark Mueller]

On Wed, Dec 18, 2013 at 7:36 AM, Brian Paul <brianp at vmware.com> wrote:

> On 12/17/2013 07:50 PM, Mark Mueller wrote:
>
>>
>>
>>
>> On Tue, Dec 17, 2013 at 12:19 PM, Mark Mueller <markkmueller at gmail.com
>> <mailto:markkmueller at gmail.com>> wrote:
>>
>>
>>
>>
>>     On Sat, Nov 23, 2013 at 4:10 PM, Marek Olšák <maraeo at gmail.com
>>     <mailto:maraeo at gmail.com>> wrote:
>>
>>         On Sat, Nov 23, 2013 at 10:23 PM, Mark Mueller
>>         <markkmueller at gmail.com <mailto:markkmueller at gmail.com>> wrote:
>>          >
>>          >
>>          >
>>          > On Sat, Nov 23, 2013 at 2:26 AM, Marek Olšák
>>         <maraeo at gmail.com <mailto:maraeo at gmail.com>> wrote:
>>          >>
>>
>>
>>
[..]


>
>>
>> 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.
>>
>
> 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.
>
> 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.
>
> Throw in big vs. little endian issues and it's kind of a mess.
>
>
>
>  For
>> example these two cases in _mesa_choose_tex_format:
>>
>>     case GL_BGRA:
>>        RETURN_IF_SUPPORTED(MESA_FORMAT_ARGB8888);
>>
>> vs.
>>
>>     case GL_RGBA32F_ARB:
>>        RETURN_IF_SUPPORTED(MESA_FORMAT_RGBA_FLOAT32);
>>
>
> 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.
>
>
>
>>
>> and Mesa defines these:
>>
>>     MESA_FORMAT_ARGB1555,/*                     ARRR RRGG GGGB BBBB */
>>     MESA_FORMAT_ARGB1555_REV,/*                     GGGB BBBB ARRR RRGG */
>>
>> while in OGL it's this way:
>> GL_UNSIGNED_SHORT_5_5_5_1
>> GL_UNSIGNED_SHORT_1_5_5_5_REV
>>
>
> Again, the apparent inconsistency comes from old OpenGL (SGI) conventions
> vs. PC hardware conventions.
>
>
>  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.
>>
>
> 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?
>
> -Brian
>
>
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:
- 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.

- The PIPE_FORMATs and BRW_SURFACEFORMATS serve better for hardware/GPU
specificity.

- 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.

- 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

- 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.


So is that convincing enough to justify a more direct mapping of
MESA_FORMAT names to API names?

Mark

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131218/b24f3629/attachment.html>