Closed jeremyong closed 1 year ago
We've also ran into this with our abstractions, and haven't found a nice way around it other then to break them.
Having globallycoherent
as a type modifier makes sense to me but it would also mean that it needs to be valid on return types.
We have also started running into this when converting our shaders to bindless. Since we do a direct variable -> function, the function type has to return a globallycoherent
type.
Premise
While other RHIs still do not have dynamic resource indexing, it's convenient to implement a common platform-neutral interface with getters for various resource types. However, an issue seems to arise specifically when trying to return a
globallycoherent
annotated UAV from a function. While the DXIL generated correctly annotates the resource asgloballycoherent
, the shader compilation result produces warnings. Please let me know if I missed something in the correct way to do this, thanks!Issue Description
Consider the following snippet:
Compiling this as
dxc.exe -E CSMain -T cs_6_6 -HV 2021 test.hlsl > test.dxil
produces the following warning:which is the result of this diagnostic.
However, there doesn't appear to be a clean way to propagate the annotation to the function's return type. For example:
resolves the diagnostic above, but leaves you with a new warning:
This warning may be suppressed using
-Wno-ignored-attributes
but would globally turn off the warning.