[Mesa-dev] req'd resolution (was: Floating point textures and rendering for Mesa, softpipe and llvmpipe)

[tom fogal]

keith whitwell <keith.whitwell at gmail.com> writes:
> On Wed, Sep 1, 2010 at 8:34 PM, tom fogal <tfogal at sci.utah.edu> wrote:
> > Luca Barbieri <luca at luca-barbieri.com> writes:
> >> 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.
>
> Is that 8-fixed and 16-float (ie half-float)?  Or does a 16-bit fixed
> format also work?

It's RGBA8 vs. RGBA16F_ARB vs. RGBA32F_ARB.

I attempted to hack GL_RGBA16 and GL_RGBA32I_EXT into our app.  With
the former, my nvidia driver pegs 100% of a core && gets stuck deep
in a call stack; we must be hitting a software path (growl).  With
GL_RGBA32I_EXT the "fbo allocation" (intertwined w/ the creation of the
backing texture to complete the fbo) fails.

I put one such example up at:

  http://www.sci.utah.edu/~tfogal/tmp/depth-test/

try to view them in something where you can 'flip' images quickly --
notice how the rgba8 compositing darkens a particular area, implying
there's more depth than there is.  I don't see any difference at all
between rgba16f and rgba32f for this case.

HTH,

-tom