Skip to content
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

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

elasota
Copy link
Contributor

@elasota elasota commented May 13, 2018

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.

@walbourn
Copy link
Member

walbourn commented May 14, 2018

I'd have implemented these as part of the _ConvertScanline special-case path rather than _LoadScanline/_StoreScanline since it's specific to conversion codepaths. I realize something would need to change in Store with respect to the clamp, but maybe a bool clamp = true parameter would do it.

Since it's specific to FP32 to FP16 conversions, maybe name the flags: TEX_FILTER_FLOAT16_*

@walbourn
Copy link
Member

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...

@walbourn
Copy link
Member

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.

@walbourn walbourn self-requested a review March 19, 2023 04:32
Trim whitespace
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++);
Copy link
Member

@walbourn walbourn Mar 19, 2023

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.

Copy link
Contributor Author

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))
Copy link
Member

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants