keith whitwell <keith.whitw...@gmail.com> writes: > On Wed, Sep 1, 2010 at 8:34 PM, tom fogal <tfo...@sci.utah.edu> wrote: > > Luca Barbieri <l...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
