Jump to content
  • Advertisement
Sign in to follow this  
V-man

half float

This topic is 3876 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Quick question, Does HLSL have half support? Or should I ask, does SM 2.0 support it? SM 3.0? SM 4.0? D3D 9 or D3D 10? Or maybe I need to check if the GPU supports it first?

Share this post


Link to post
Share on other sites
Advertisement
For vertex components, you should check DEVCAPS. A specific subfield is to be checked.
For textures and render targets, I don't remember if they're mandated by a shader model (possibly PS3? I'm not sure) anyway, checking them before use with CheckDeviceFormat is always a good idea.

HLSL natively supports half.

If you can use D3D10 then go for it. It's just easier to have an unified resource pool than to think at VBO/textures/buffers...

Share this post


Link to post
Share on other sites
Thanks. So inside the shader, there isn't a half support so that there is no conversion to take place from 16 to 32 bit float?

Share this post


Link to post
Share on other sites
It depends whether you're meaning storage or processing as half-precision.

Storage, as Krohm mentioned, is dependent on some device caps but most recent hardware will be okay for vertex/texture elements in FP16 format.

Processing is much less clear - older hardware implemented SM2 in half/24/single precision depending on the architecture. Both SM3 and SM4 mandate that all internal calculations are performed with FP32 precision - so even if you read from and then write to FP16 storage using SM4 the intermediary computations are all done at FP32.

hth
Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by jollyjeffers
It depends whether you're meaning storage or processing as half-precision.

Storage, as Krohm mentioned, is dependent on some device caps but most recent hardware will be okay for vertex/texture elements in FP16 format.

Processing is much less clear - older hardware implemented SM2 in half/24/single precision depending on the architecture. Both SM3 and SM4 mandate that all internal calculations are performed with FP32 precision - so even if you read from and then write to FP16 storage using SM4 the intermediary computations are all done at FP32.

hth
Jack


Assuming storage is supported.
Ok, I found that sticking a _pp on the end of instructions is for doing operation in half float. Is this ignore on older hw?
Because what's the sense of using 16 bit?
It was implemented by nVidia so that shaders would run faster starting from Gf FX.

One thing I couldn't figure out was a line like this
texld_pp r2, r0, s0 //ps2.0

but I thought r2 is a 32 bit temp. It uses the entire 32 bit feild?
There is no HI and LO?

Share this post


Link to post
Share on other sites
The partial precision flag is a hint, not a mandate, it means that hardware may run it at lower precision if it wants to. Some hardware manufacturers support doing lower precision at higher speeds, some don't.

D3D10 doesn't have half support, all half values are automatically upgraded to float. This is actually changing in the next compiler release, as we're preparing for actually having half support in D3D11. This means on D3D10 (and D3D9, to simplify porting between the two) we won't support declaring constants as half. Note that you can still declare variables as static const and assign to them to retain the ability to ensure that any calculations with those values have the possibility of being run at partial precision.

Technically we could at some point in the future support reading and writing half precision values in D3D10, since we do have integer operations. However, all calculation would still happen at 32-bit float, so this would be for more efficient memory/bandwidth usage, not to take advantage of any lower precision instructions. The primary reason we can't do this immediately is the reflection system doesn't currently understand half values, so there's no way to tell the user how to assign them correctly.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!