Difference between floating point render target and normal render target
Author
Could someone please explain what is the difference between floating point render targets and a normal render target like A8R8G8B8? I mean both types of render target takes float4 as output from the pixel shader, so what is the difference?
Is A8R8G8B8 a integer render target? What happens in the pixel shader when I write:
return float4(1.0, 0.0, 0.0, 1.0);
So my question is if A8R8G8B8 is an integer render target then what happens when i return a color value in the range of 0.0 and 1.0? Does the hardware automatically convert it to between 0 and 255 (integer) and display the result?
Thanks in advance :)
Quote:Original post by JBond
So my question is if A8R8G8B8 is an integer render target then what happens when i return a color value in the range of 0.0 and 1.0? Does the hardware automatically convert it to between 0 and 255 (integer) and display the result?
Yep, it's an integer render target (0-255).
I'm not if the hardware does it, or if the shader-compiler changes your code to use special integer maths behind the scenes... But yes, the end result is that you're really only working with [0-255] integers, and not with floating point.
An integer rendertarget, like A8R8G8B8, takes a value between 0.0 and 1.0 and converts it into an integer by multiplying with the maximum integer value for each channel. For instance, if you output 0.75 to a channel from the shader using an A8R8G8B8 rendertarget, it writes 0.75*255 = 191 to that channel. Same for other integer formats.
A floating-point rendertarget will directly write whatever value you output, using the precision of the target (i.e. FP16, FP32, etc.).
A floating-point rendertarget will directly write whatever value you output, using the precision of the target (i.e. FP16, FP32, etc.).
Author
What happens when I write something out of the 0-1 range into an integer rener target? does it clamp? overflow?
Do you mean I can safely write any floating point number into a floating point render target even if its outside of the 0-1 range?
Thanks!
Do you mean I can safely write any floating point number into a floating point render target even if its outside of the 0-1 range?
Thanks!
Quote:Original post by JBondOkay, I don't really do any hardware 3D programming at all, but IIRC it would clamp, as that is the basics of how High Dynamic Range (HDR) works.
What happens when I write something out of the 0-1 range into an integer rener target? does it clamp? overflow?
Do you mean I can safely write any floating point number into a floating point render target even if its outside of the 0-1 range?
Thanks!
Quote:Original post by JBond
What happens when I write something out of the 0-1 range into an integer rener target? does it clamp? overflow?
It will clamp (or "saturate", to use the lingo).
Quote:Do you mean I can safely write any floating point number into a floating point render target even if its outside of the 0-1 range?
Absolutely. That is why HDR works. Floating-point values allow you to represent very large differences in light intensity in your scene, without knowing beforehand what the maximum and minimum light values will be (hence this range is dynamic).
Quote:converts it into an integer by multiplying with the maximum integer value for each channelso what terminologie is correct: integer render target or fixed-point render target? I believe integer ... any thoughts?
Quote:Original post by wolfI prefer fixed-point, to differentiate between "normalized" integer and the newer "unnormalized" integer formats (as in GL_EXT_texture_integer, I'm not sure of the D3D counterpart).
so what terminologie is correct: integer render target or fixed-point render target? I believe integer ... any thoughts?
Author
Another question, how is floating point represented in the hardware in the floating point render target? I mean does it have a sign bit, an expont part, and a significand part as in IEEE floating point? what kind of precision can I expect from say a R32F? Thanks!
According to NVidia, sometimes when you ask for a 16-bit float texture, they'll actually give you a 32-bit texture instead.
32-bit floats do follow the IEEE standard.
I'm not sure if there is a IEEE standard for 16-bit floats, but they probably have 1 sign bit, 5 exponent bits, and 10 mantissa bits.
32-bit floats do follow the IEEE standard.
I'm not sure if there is a IEEE standard for 16-bit floats, but they probably have 1 sign bit, 5 exponent bits, and 10 mantissa bits.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement