José Fonseca schrieb: > On Tue, 2009-12-08 at 09:00 -0800, Christoph Bumiller wrote: >> michal schrieb: >>> This branch simplifies pipe/p_format.h by making enum pipe_format what >>> it should have been -- an enum. >>> >>> ... >>> >>> I would like to hear from r300 and nouveau guys, as those drivers were >>> using some internal macros and I weren't 100% sure I got the conversion >>> right. >>> >> Hi ! >> In nv50_vbo.c/nv50_vbo_type_to_hw you imply that UTIL_FORMAT_LAYOUT_ARITH >> means normalized (UNORM, SNORM) and LAYOUT_ARRAY means SCALED, which >> seems to be not the case. >> >> PIPE_FORMAT_R32G32B32A32_SNORM for instance also has layout ARRAY. >> I'm not sure what ARRAY/ARITH are supposed to mean ... > > I just documented UTIL_FORMAT_LAYOUT_*. It is really a subjective > attribute meant generating software (cpu) routines to translate pixel > to/from a format. It is quite likely this will grow/shrink with time. > > Hardware drivers are better off using other more objective attributes in > util_format_description, or even PIPE_FORMAT_xxx names themselves. > >> Anyway, you could probably base the check on channel[0].normalized, >> since the formats used >> for vertex elements are not mixed. >> I still don't see how to distinguish SCALED and INT though, which at >> some point will have >> to indicate integer attributes ... > > Could you elaborate? At least u_format.h semantics are that INT > describes how the bits should be interpreted into a value (integer as > opposed to floating point). SCALED concerns how those integer values > should be further interpreted, namely their range (0..1 or -1..1, in > opposition to INT_MIN..INT_MAX for the given bit width). I think it > covers all PIPE_FORMATS_xxx. > > Jose >
I was just thinking about *real* integer "formats" that don't get converted to floating point on input to VP or output to RT, that's what I mean with SINT/UINT as opposed to SSCALED/USCALED. Since we call the other formats the DXGI/DX10 way, we might do it in that case too. I realize the difference between SINT vs. SSCALED isn't how the formats are to be interpreted, but instead how they are to be treated (or conversely, how FP output register contents on nv50 are to be interpreted), so having both doesn't always make sense. I suppose we could add an extra flag in RT and vertex element state for that, and/or concern ourselves with this later, when it becomes an issue. Christoph ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
