Luca Barbieri <l...@luca-barbieri.com> writes: > > It's an impressive amount of work you did here. I'll comment only > > on the llvmpipe of the changes for now. > > Thanks for your feedback!
While we're on the topic: yes, this is great to see Luca. Thank you! > > So instead of going through a lot of work to support multiple > > swizzled types I'd prefer to keep the current simplistic (always > > 8bit unorm) swizzled type, and simply ignore errors in the > > clamping/precision loss when rendering to formats with higher > > precision dynamic range. > > > > In summary, apart of your fragment clamping changes, I'd prefer to > > keep the rest of llvmpipe unchanged (and innacurate) for the time > > being. > > Note that this totally destroys the ability to use llvmpipe for high > dynamic range rendering, which fundamentally depends on the ability > to store unclamped and relatively high precision values. FWIW, we've got an app that allows one to choose the bit depth we do our compositing in, and the difference between 8 and 16 for some data is quite striking. 16 and 32 not so much, though sometimes visible. The 8bit mode is really just coded up due to driver support; it really does look poor. Though we're doing vis apps, not games, so perhaps our use case is considered niche. > Using llvmpipe is important because softpipe can be so slow on > advanced applications (e.g. the Unigine demos) to be unusable even > for testing. ... having said the above, we're still using swrast. I'd like to someday jump to softpipe / llvmpipe though... -tom _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
