On 12/18/2013 12:23 PM, Mark Mueller wrote:
On Wed, Dec 18, 2013 at 7:36 AM, Brian Paul <bri...@vmware.com <mailto:bri...@vmware.com>> wrote: On 12/17/2013 07:50 PM, Mark Mueller wrote: On Tue, Dec 17, 2013 at 12:19 PM, Mark Mueller <markkmuel...@gmail.com <mailto:markkmuel...@gmail.com> <mailto:markkmuel...@gmail.com <mailto:markkmuel...@gmail.com>__>> wrote: On Sat, Nov 23, 2013 at 4:10 PM, Marek Olšák <mar...@gmail.com <mailto:mar...@gmail.com> <mailto:mar...@gmail.com <mailto:mar...@gmail.com>>> wrote: On Sat, Nov 23, 2013 at 10:23 PM, Mark Mueller <markkmuel...@gmail.com <mailto:markkmuel...@gmail.com> <mailto:markkmuel...@gmail.com <mailto:markkmuel...@gmail.com>__>> wrote: > > > > On Sat, Nov 23, 2013 at 2:26 AM, Marek Olšák <mar...@gmail.com <mailto:mar...@gmail.com> <mailto:mar...@gmail.com <mailto:mar...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
