[Mesa-dev] req'd resolution (was: Floating point textures and rendering for Mesa, softpipe and llvmpipe)
tfogal at sci.utah.edu
Wed Sep 1 13:14:45 PDT 2010
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:
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.
More information about the mesa-dev