You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This was raised during discussion of a Vulkan specific feature attribute and I feel it warrants a separate issue.
We currently have and will have more Vulkan specific feature attributes for Vulkan features that native language constructs of HLSL does not support. Yet HLSL is also an evolving language and it will start to have native support for those features. So just as a general strategy discussion, what process(if any) should we have in place to monitor and merge/deprecate the Vulkan attributes and replace them with HLSL native when it becomes available?
The text was updated successfully, but these errors were encountered:
I think it's fair to say that our new approach with inline SPIR-V solves this problem well enough by focusing on supporting a general purpose set attributes for any SPIR-V builtin functions, types, etc. Since we're no longer adding feature-specific attributes to DXC, this attribute churn and maintenance burden should be significantly lessened.
This was raised during discussion of a Vulkan specific feature attribute and I feel it warrants a separate issue.
We currently have and will have more Vulkan specific feature attributes for Vulkan features that native language constructs of HLSL does not support. Yet HLSL is also an evolving language and it will start to have native support for those features. So just as a general strategy discussion, what process(if any) should we have in place to monitor and merge/deprecate the Vulkan attributes and replace them with HLSL native when it becomes available?
The text was updated successfully, but these errors were encountered: