Skip to content

Conversation

@llvm-beanz
Copy link
Collaborator

This proposal suggests a different approch for handling target feature profiles which is both more flexible and more meaningful across APIs. The goal is to redefine the concept of target profiles as DXC represented them to extend more clearly across the whole ecosystem.

This proposal suggests a different approch for handling target feature
profiles which is both more flexible and more meaningful across APIs.
The goal is to redefine the concept of target profiles as DXC
represented them to extend more clearly across the whole ecosystem.
@jenatali
Copy link

jenatali commented Sep 4, 2025

I like this direction, personally. I think there's 3 interesting axes that shader models have historically meant:

  • Opting into a dialect of HLSL, e.g. shader model 3 vs 4. With DXC and Clang, we've done a really good job of separating this out into HLSL language versions, distinct from shader models, so I don't think this particularly interacts with this proposal anymore.
  • Opting into a set of features that you would like the compiler to make available to you, e.g. ResourceDescriptorHeap[].
  • Controlling the interchange format, e.g. DXIL 1.6 vs DXIL 1.9 vs SPIR-V 1.X.

Right now a shader model controls both the set of features you can use, and the interchange format that will be produced. With (very) few exceptions, in DXC, enabling a more capable shader model doesn't allow you to disable any of the optional parts of it. So I'm very much in favor of separating out compiler enablement of functionality to a per-feature basis rather than a bundle of features.

I would also argue that in general, developers don't care about the interchange format, as long as it is sufficient to express their shader code. There might be exceptions to this: for example, DXIL 1.9's vectorization may provide performance or size benefits with no new features being used in the shader source.

I think what developers will generally want is a way to enable the set of features that are supported by their target devices, with the "oldest" interchange format that can support those features, and have the compiler error if they attempt to use a feature that's not explicitly enabled, and then also have a way to optionally select a specific bytecode format that's newer.

Copy link
Collaborator

@damyanp damyanp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of comments, but this looks ready to be merged and discussed further to me.

@llvm-beanz llvm-beanz requested a review from s-perron September 4, 2025 23:44
Copy link
Collaborator

@s-perron s-perron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. I like this direction. It was confusing using the shader models because they do not map nicely to when features were made available on Vulkan.

Copy link
Collaborator

@bogner bogner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is in good shape to be merged and have further consideration in tree.

Copy link
Collaborator

@s-perron s-perron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can work out the details as we move one. I'm fine with merging this.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants