float texture: 16 vs. 32 bits

Hi guys,

Originally, I was sending an unsigned char texture to a pixel shader program, and doing lots of computation on these data on the GPU. It actually makes more sense to pre-compute all these data since they don’t change. I therefore switched to sending a float texture to the shader, with all the right data pre-computed.

It’s all nice and well, but I first tried displaying the raw 32 bits float values sent to the shader (no other computation), and it was soooooo slow. When I changed to 16 bits floats, it was super fast. And I was wondering why is that. Is that architecture dependent? I am using a nVidia 6600.

Also, does using a float texture has an impact on the performance compared to a vanilla unsigned char texture?

Thanks

Alex

It will of course depend on what you do, but a 4-byte per-component texture will need twice as much bandwith as a 2-byte per-component one and four as much as a 1-byte-per component texture. As your card has a rather slow memory, a four-time bandwidth increase will be noticeable, while a two-time increase(using the partial precision) can be hidden by already existing bottlenecks, like the shader execution.

Sounds like you have a linear filter enabled. Try GL_NEAREST.

Originally posted by Humus:
Sounds like you have a linear filter enabled. Try GL_NEAREST.
Wow, spot on. It did indeed the trick.

Just a remark though. Say I use a linear filter. If I use a 32bits floating-point texture, that’s twice more than a 16 bits f-p texture. But the performance worsens so much more than that. WIth 16 bits, I get real-time (>20fps) but with 32 bits, it’s less than 1fps. How can it become so slow so suddenly? Is it the because of the bandwidth problem mentioned in the other answer?

Originally posted by Humus:
Sounds like you have a linear filter enabled. Try GL_NEAREST.
Another question: Are there any other filtering methods beyond nearest and linear, especially for floating-point values? I’m especially thinking about the famous anisotropic filtering. Would it be of any help in that case?

Thanks

Alex

the linear filtering of 32 float textures is so slow because it is not supported in hardware…

Originally posted by Chuck0:
the linear filtering of 32 float textures is so slow because it is not supported in hardware…
That would explain it. Is that for my GPU only? Or do they all not have this feature?

It is mentioned on the nVidia website that the series 6xxx support 64 bits filtering. What does it correspond to then?

Hm… I sort of missed the filtering thing :frowning:

Nvidia cards after the 6xxx series support filtering on 16-bit floating-point textures only(that’s 64 bit - four channels * 16). Filtering on 32-bit floating point textures will force software emulation. Don’t know about ATI.

ATI doesn’t support filtering on any floating point surface at this point.

Originally posted by Humus:
ATI doesn’t support filtering on any floating point surface at this point.
I’m not sure I got this right. They do support float texture, don’t they? (after all, the ARB extension was based on their initial work). But what you said means that we can only use GL_NEAREST with float texture on ATI hardware right? What happens if you use GL_LINEAR anyway?

Thanks a lot

Alexis

As already said, if you want other filtering mode then GL_NEAREST, you will get software emulation. This goes for nvidia and for ati. Hovewer, nvidia hardware also supports linear filtering on 16-bit fp textures.
You can also emulate the filtering in your shader, by sampling several texels and combining them together, this will work on every hardware.
Hope that sums it up(and yes, ati has support for pf textures).

If you need FP texture with filtering on ATI there’s a paper in the ATI SDK named “HDR texturing” that could be helpful.