[NNNN] New proposal for feature profiles

[llvm-beanz]

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]

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.

[damyanp]

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

[s-perron]

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.

[s-perron]

I think this is the minimum, but in practice many more are supported. This would be a good place to bring up another issue with Vulkan. Not all features are enabled by extensions. Some features are enabled by feature bits. We might want a way to describe features bits as well. Note that when a feature becomes core, it gets a feature bit and does not use the extensions.

The second issue is that the SPV_* extensions that get enabled in Vulkan do not necessarily map to a SPIR-V feature. For the backend, we'll have to map the vulkan extensions to available spir-v extensions.

With that said, I think that using the vulkan extensions is the right direction. It will be easier for Vulkan developers because that is what they are using.

[s-perron]

Do you need to call out that features can be explicitly disabled, even if they are "Required".

[bogner]

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