-
Notifications
You must be signed in to change notification settings - Fork 452
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add FP16 NaN/infinity handling flags #100
base: main
Are you sure you want to change the base?
Conversation
I'd have implemented these as part of the Since it's specific to FP32 to FP16 conversions, maybe name the flags: |
… sanitization control flags.
I totally get what you are going for here, I'm just wondering about some other impacts this might have elsewhere. I'll think about it a bit more... |
Revisiting this issue part of the problem I think is the functionality offered in CVT16/F16C. These instructions let you control rounding, but don't have any ability to control NANs and/or DENORMS. I of course can implement it in software, but it will slow it down a bit. As such, I think the default behavior needs to be "use NANs and DENORMs" and provide explicit flags for flushing DENORMs (which would need to be implemented for both F16 and F32 to make sense) and preferring INFs to specials for conversions. I have some DirectXMath bugs in the handling of NANs. and DENORMS to deal with first, and when I wrap those up I'll revisit this PR. |
Trim whitespace
Code review
Conversion logic for WIC vs. non-WIC update for new flags.
XMVECTOR v = *sPtr++; | ||
v = XMVectorClamp(v, g_HalfMin, g_HalfMax); | ||
XMStoreHalf4(dPtr++, v); | ||
XMStoreHalf4(dPtr++, *sPtr++); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a little nervous about removing the clamp behavior here, but it's probably the best choice if we can do it in a way that doesn't regress behavior.
The main places where the clamping is now 'missing' is:
- BC Decompression - this shouldn't ever have specials
- TransformImage - The pixel function used needs to clamp if they care
- ConvertToRGBA32 helper - not using float16 formats as the target
- Custom resize, Custom mip generation, CopyRectange, NormalMap generation, PM Alpha conversion - If the input has specials, the output will have them.
I think the ConvertFromR32G32B32A32
helpers needs an explicit clamp added for the float16 cases. This is the primarily used for WIC interactions where WIC doesn't support the format.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* BC Decompression - this shouldn't ever have specials
BC6H signed can have -INF, even though it's not recommended.
@@ -4441,6 +4458,12 @@ namespace | |||
return false; | |||
} | |||
|
|||
if (filter & (TEX_FILTER_FLOAT16_SATURATE_TO_INF | TEX_FILTER_FLOAT16_KEEP_NANS)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before I can sign off here, I really need to see what WIC does. Does it preserve specials or always clamp them?
Adds 2 flags for more control over special floating point values when converting to FP16. May be useful for applications that depend on NaN/infinity for special handling, like using NaN as a transparency sentinel.
TEX_FILTER_FLOAT_SATURATE_TO_INF saturates out-of-range values to infinity, including existing infinities. TEX_FILTER_FLOAT_KEEP_NANS keeps NaNs instead of forcing them to zero.
Default behavior is convert NaN to zero and saturate to max range.