Help with floating point textures

Started by
4 comments, last by Duel93 17 years, 5 months ago
I've read several articles for HDR where a scene is rendered to a floating point texture. I am having a couple of problems with this and hopefully someone can point me in the right direction. I choose not to render the scene to a Frame Buffer Object (FBO), since there is no support for anti-aliasing. I instead do what NVIDIA suggests in one of their examples to maintain anti-aliasing. I copy the rendered scene from the back buffer to a texture. This texture is then used for any post render filtering. If the texture I copy to is a GL_RGBA16F_ARB (floating point formatted texture), the copy is extremely slow. Copying to a GL_RGBA or GL_RGBA16 (non-floating formatted texture), the copy is fast. My card supports all of this, so that is not the issue. Anyone have any ideas as to what causes this to be so slow? I've torn up a congeries of examples trying to figure it out. I've read that you cannot blend to a floating point texture (or FBO) but NVIDIA has an example where blending is enabled and the render target is floating point (although the target is a pbuffer). Thanks in advance.
Advertisement
What is your hardware? What filtering mode are you using? Try GL_NEAREST. Try PBO's... You can also try the NV extensions for FP textures vs. the ARB. But IIRC the ARB should work fine.
I have an NVIDIA GeForce 6600 GT.

I tried using GL_NEAREST, but that only helped a little. With a non-floating point texture, I can render a scene with 80 - 100 FPS. With floating point (and GL_NEAREST), it goes down to 20 FPS. There is no difference when using NV extensions Vs. ARB.

I guess I'm wondering if it is indeed supposed to be a higher framerate, such as with a non-floating point texture. Just doing a glCopyTexImage2D should not be significantly different. Or is that expected? I don't see this when running other examples.
128-bit floating point (4*sizeof(float)) takes up four times the bandwidth as compared to a simple RGBA32 vector which fits into a single DWORD. Hence, if you're completely fill rate (or gpu memory bandwidth) limited, it is to be expected that the frame rate drops by a factor of 4.

I recommend using half-precision floats to halve the memory bandwidth requirements, or simply scaling back your pixel shaders.

Niko Suni

He is already using half-precision floats. If the speed drops even when moving from ARGB16 to ARGB16F, memory bandwith is propably not an issue.

Basically, the Geforce6 series should support all of the requested operations and filters on both ARGB16 and ARGB16F. Maybe the texture copy tries to do some decompression because of the "special" number format of an 16Bit float. Are there any ReadOnly-Flags or something you could apply?

Bye, Thomas
----------
Gonna try that "Indie" stuff I keep hearing about. Let's start with Splatter.
Even if I use a floating point FBO, the same result happens; very slow. With non-floating point FBO's, it's considerably faster. With glCopyTexImage2D and floating point textures...the result is slow.

I'm 99% sure I'm missing some vital piece of information to make this work correctly. I assume this since scenes with true HDR are rendered to a floating point texture, so it's supposed to be fast.

At this point, my shaders are off. I'm just attempting to get it working with just either a glTexCopy or and FBO.

This topic is closed to new replies.

Advertisement