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

[Feature Request] Warn on use of eval intrinsics (EvaluateAttribute*, GetAttributeAtVertex) outside entry function #6478

Open
tex3d opened this issue Mar 29, 2024 · 1 comment
Labels
enhancement Feature suggestion
Milestone

Comments

@tex3d
Copy link
Contributor

tex3d commented Mar 29, 2024

Is your feature request related to a problem? Please describe.
Using an attribute evaluation intrinsic (EvaluateAttribute* and GetAttributeAtVertex) outside an entry point is not well-defined in the HLSL language. Sometimes it works for DXIL because of the way we optimize code before lowering to a DXIL operation, and many times it doesn't work. However, it can't be reliably defined or implemented in the current language due to our current calling convention that uses copy-in semantics.

See issue #6220.

Describe the solution you'd like
I suggest we introduce a warning when using these intrinsics outside of the entry function, since that's where the language does not have a well-defined way to support this.

The wording of the warning should indicate that calls to these intrinsics are unsupported outside the entry function, even though they may work in some cases on certain targets.

Defaulting this warning to error would be useful, but might be too disruptive in the short term, so we may need to limit the scope for that, perhaps to SPIR-V and HLSL 202x.

The warning should have a unique group to allow user override.

For the longer term, we will work on a clean language solution, see: microsoft/hlsl-specs#181.

Describe alternatives you've considered
A change to require nointerpolation on intermediate function arguments used for GetAttributeAtVertex has been submitted in PR #6453. However, while this may be used to catch some invalid use cases, it will also block legal use cases, won't help catch a variety of other problematic cases, and won't help with the EvaluateAttribute* intrinsics at all, which have the same problem. It will only be enabled on SPIR-V, so it may be acceptable as a helpful mitigation in SPIR-V for now, but I do not believe it points towards a solution to the general problem.

Additional context
Related issues: #6220, #6382, #6383, #6384, #6225, #3649

@tex3d tex3d added enhancement Feature suggestion needs-triage Awaiting triage labels Mar 29, 2024
@damyanp damyanp removed the needs-triage Awaiting triage label Apr 1, 2024
@damyanp damyanp moved this to Triaged in HLSL Triage Apr 1, 2024
@damyanp damyanp added this to the Backlog milestone Apr 1, 2024
@damyanp
Copy link
Member

damyanp commented Apr 1, 2024

Let's have a think about this when we get closer to deciding what's in HLSL 202x. It's not obvious at the moment if we need to do something about the current status quo, and whether or not a warning like this adds enough value to make it worth the investment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature suggestion
Projects
Status: Triaged
Development

No branches or pull requests

2 participants