-
Notifications
You must be signed in to change notification settings - Fork 19
[NNNN] New proposal for feature profiles #337
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
base: main
Are you sure you want to change the base?
Conversation
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.
|
I like this direction, personally. I think there's 3 interesting axes that shader models have historically meant:
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. |
damyanp
left a comment
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.
A couple of comments, but this looks ready to be merged and discussed further to me.
s-perron
left a comment
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.
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.
Co-authored-by: Steven Perron <[email protected]>
Co-authored-by: Steven Perron <[email protected]>
bogner
left a comment
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.
This is in good shape to be merged and have further consideration in tree.
s-perron
left a comment
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.
We can work out the details as we move one. I'm fine with merging this.
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.