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

[Brian Paul]

On 12/18/2013 12:23 PM, Mark Mueller wrote:
>
>
>
> On Wed, Dec 18, 2013 at 7:36 AM, Brian Paul <brianp at vmware.com
> <mailto: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>
>         <mailto: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>
>              <mailto: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>
>         <mailto: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>
>         <mailto: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?

I think we're all interested in improving the MESA_FORMAT_ naming so if 
you've got a proposal, go ahead and post it.

> Towards this end, I'd like to start by adding UNORM, or UINT, where
> applicable, to all of the MESA_FORMATs listed in the "basic hardware
> formats" section. Are there any objections?

Sounds OK to me.

-Brian