On 14.09.2011 09:36, Jose Fonseca wrote: > ---- Original Message ----- >>> On the contrary, I think that putting norm and scaled/int in the >>> same sack is talking apples and oranges... Normalization, like >>> fixed-point integers, affects the interpretation of the 32bit >>> integer in memory, namely the scale factor that it should be >>> multiplied. Whereas the only difference between _SSCALED and >>> _SINT is the final data type (int vs float) -- the value is >>> exactly the same (modulo rounding errors). >>> >>> The pure vs non-pure integer is really a "policy" flag, which means >>> please do not implicetly convert this to a float at any point of >>> the vertex pipeline. And I believe that policy flags should be >>> outside enum pipe_format. >> While I'm tending to agree with you Jose, the other thing that we >> haven't discussed yet is that we need to add new pack/unpack >> interfaces to u_format for all these types anyways to get a integer >> clean path (no float converts in the pipeline), increasing the size >> of >> the u_format_table anyways. With separate types we could overload the >> float pack/unpack. ones most likely. > I'm not sure where u_format's code is used in hardware pipe drivers nowadays, > but for software rendering in general and state trakcer software fallback of > blits in particular, we could never just overload the float unpack/pack > entry-points, as they would corrupt 32bit integers higher/smaller than +/- 1 > << 24. I think we'd need pack/unpack functions that accept/return colors in > 32bit integers instead of floats, or another type big enough.
The pack/unpack/fetch functions of (pure) integer formats wouldn't deal with floats at all, all they'd do is sign/zero extension (so, the float array argument would become void and the function would do the "right thing" automatically). OpenGL functions like ReadPixels don't allow RGBA_INTEGER format together with float types, or blits between SINT-FLOAT, SINT-UINT, etc. anyway ... > So either we add (un)pack_rgba_uint32 and (un)pack_rgba_sint32 entry-points > for those integer formats (and it only needs to be added for the int > formats), or a simply add a new xxx_double entrypoint if we think that they > will never be used in a critical path. Converting everything to doubles would be kind of overkill (and potentially slow), and the 6 uint/sint function pointers would probably remain NULL (or useless) for more than half of the formats. > It's similar to what's currently done for (un)pack_z_32unorm and > (u)pack_s_8uscaled -- 32unorm can loose precision when converted to float (no > biggie for colors but inadimissible for depth values) and 8uscaled is much > smaller/faster to use than float, so u_format has these special entry-points, > but they are defined only on depthstencil formats. > > > I think that software renderers texture sampling code too, will need to be > rewritten substantially, to allow the sampling of integers using integer > intermediates. Draw module interpolation code too, will need to use double > intermediates to interpolate integer attributes when clipping, etc. All this Integer attributes are not interpolated. They must be declared as flat. > needs to happen, _regardless_ you choose to pass the "pure integer" policy > in pipe_format enum, or elsewhere. The fact is that integer values must not > be converted to float intermediates in such case -- while our current code > often assumes that float is general enough for everything. > > > Honestly, with LLVM code generation things are substantially easier, because > once basic code generation is in place, we can code generate integer > expressions just as easily as float ones. So I think that for each module > that needs updating, we should weight our options: is this code performance > sensitive, and if so would it be better served with LLVM code generation? If > it's not performance sensitive, we should simply bump the C code from floats > to doubles. Ditto, if LLVM is a better fit, so that the C version can still > be used as a reference / debugging-friendlier version than LLVM JIT code. > Otherwise, we'll have to resort to CPP templates, to generate the > float/uint/sint C versions. > > > At any rate, I believe that a lot of this does not usually apply to hardware > pipe drivers. I think it might be wiser to get the hardware paths done first, > given the hardware should do the right thing in most if not all cases, and > then start getting the software paths in shape. > > > Jose > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
