Deprecate Hull, Domain and Geometry Shaders

[llvm-beanz]

Is your feature request related to a problem? Please describe.
The industry has largely moved away from tessellation and geometry shaders. We should make a clear statement to the industry about future support for these features in shader languages and authoring tools.

Describe the solution you'd like
We should modify existing compilers to emit deprecation warnings for users of hull, domain and geometry shaders, and plan a removal of support in future releases. This does not impact existing shipping software that uses these features. It is to discourage future use for unreleased software titles and encourage adoption of more modern rendering techniques.

Strawman

We haven't figured out the exact details of a deprecation plan, but it might look something like:

1. Soon-ish we make DXC emit a warning anytime you build a shader for one of those stages.
2. 1-2 years from now, we remove support from DXC.
3. Clang never supports hull, domain or geometry shaders.

[PrismaticFlower]

I probably don't have much to add that people haven't already considered before this. But I have concerns for what this could mean for software that wants to be able to run on old hardware and also use nice modern compilers.

And this isn't hypothetical there are a lot of Pascal GPUs still in use in the world for instance. And there probably still will be in 2 years time. They may not be able to run the latest greatest games but for are still good for pretty much anything else.

Anyway to give a concrete example of why I care about this. In my spare time I maintain and develop a world editor for an old game. For it's renderer it uses D3D12 and the shaders are of course compiled with DXC. In terms of HW support it targets anything with SM 6.1 and Resource Binding Tier 2 support. Those requirements aren't randomly chosen either (they used to be a lot higher) they're as high as I've been able to make them while still allowing the people who want to use it, to use it.

Now the editor has a frequent need to draw wireframes. For this it does the classic technique of taking the distance to the closest triangle edge in the pixel shader and applying some function for falloff. When you have access to GetAttributeAtVertex this is easy. When you don't (which you can often not 😢) a way to mimic it is with geometry shaders.

Which is exactly what I do, I check if barycentrics are supported when creating the pipeline and use a different pixel shader with a geometry shader when it's not.

Now this is a very small scale example from something that isn't even a commercial product. But it does show that geometry shaders while dated do still have uses. And in this case you don't even actually have to go back that far to find a GPU that needs this workaround, the first gen Intel Arc GPUs are from 2022 and they don't support barycentrics.

I'm completely understanding that there are only so many people who work on HLSL. And if there's just no time or space to carry geometry and tessellation shaders forward into clang then that's that. However if the move to deprecate them in HLSL is being made because they're old and not fashionable I would strongly ask that it not be done lightly. Rare as they are they can still have uses and they're supported on every piece of DX12 capable HW (ignoring that compute only feature level ones).

For apps that do you use them it would be a shame to not be able to update to clang when it's ready or to have to keep using dxc, but just for geometry shaders.