[Mesa-dev] [RFC] [BRANCH] Floating point textures and rendering for Mesa, softpipe and llvmpipe

[tom fogal]

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
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