-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
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
Direct 3D 12: Implement proper fallback for format casting #88027
Conversation
c96d676
to
285bec3
Compare
I ran into this exact issue so I should confirm later if it works. |
The PR kind of works as expected and doesn't. In its current state, it did not fix the issue at all for me, but apparently it's because whenever this is called... D3D12_FEATURE_DATA_D3D12_OPTIONS12 options12 = {};
res = device->CheckFeatureSupport(D3D12_FEATURE_D3D12_OPTIONS12, &options12, sizeof(options12));
if (SUCCEEDED(res)) {
format_capabilities.relaxed_casting_supported = options12.RelaxedFormatCastingSupported;
} My system in particular (NVIDIA RTX 3090 Ti with latest driver, Windows 11 with the latest Windows SDK) will return that this feature is supported. However, as I mentioned to @RandomShaper before, it seems like a bit of a false positive as the view creation expecting relaxed format casting to work will fail and result in a crash afterwards. That poses a bit of a problem, as it seems either the driver or the SDK being used to build it is causing this weird issue (I tested with different SDKs and could not get the result to be different). It seems that whatever driver stack I'm stuck with will incorrectly report that the feature is supported when it's not. Force-disabling the setting however works as expected and finally makes SDFGI work in D3D12, so I can confirm that the path does its job as long as the format capability is detected properly. I'm not sure the PR is at fault here as the format capability checking is a pretty standard implementation. But it seems likely we can't quite rely on the format casting flag to identify if it truly works or not in some particular scenarios. Perhaps we can rely on creating something and checking if it fails instead? Or address the IHVs who report this feature as true into checking what the problem is? EDIT: The fallback might not be that viable as the error is pretty fatal when it occurs.
|
An option would be to disable the use of relaxed casting even if advertised as supported depending on OS and GPU vendor, but I'd rather do that in a separate PR or, in any case, consider it a separate issue that should indeed be interesting to report to Nvidia. |
It might be the safest option to indeed just not check for support until we have a solid confirmation that the feature is widely available and supported on more hardware. |
240d958
to
e84f7d0
Compare
Are you sure sure that a driver update won't do the trick for you? |
I don't have more driver updates to do. 😞 |
e84f7d0
to
c66b24d
Compare
I've added temporary code to disable it. See the updated PR description. (Warning: the PR description asks to check your comment above. If one then reads the next comment, that is, this one, they will enter an infinite loop.) |
c66b24d
to
081422c
Compare
081422c
to
7e7e44f
Compare
Rebased! (And retested.) |
1f76d61
to
5938407
Compare
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.
The fallback does work for me, there's just a couple of changes we might want to do like addressing the bitset that is using more bytes than it needs to. I haven't spotted anything on the implementation of the fallback itself.
f5f2018
to
a63db29
Compare
ff28397
to
5004a7e
Compare
Can be rebased now that the first commit was merged. |
5004a7e
to
3f530c7
Compare
Done. I was just now wondering why GitHub didn't just subsume the superfluous commit. Didn't that use to be the case? |
I don't think it does, but merging the PR as is might still work and not introduce an extra commit. It's just that the PR itself still looks like it includes two new commits not in |
Thanks! |
In short, this removes the ugly aliasing hack used when relaxed casting is not available and adds the proper reinterpret-copy or copy-via-buffer approach.
In other words, this PR fixes SDFGI for those drivers not implementing relaxed casting and where the current hack was not working properly.
Includes #87872.
UPDATE: I've updated the code disabling relaxed casting for now. (See #88027 (comment).)