[Mesa-dev] [RFC] [BRANCH] Floating point textures and rendering for Mesa, softpipe and llvmpipe
tfogal at sci.utah.edu
Wed Sep 1 12:34:58 PDT 2010
Luca Barbieri <luca at 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
> 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...
More information about the mesa-dev