Stride: Shader System Rewrite Epic

[xen2]

Our shader system current implementation is slow, complex and difficult to maintain.

Terminology:

• XKSL: Xenko Shader Language

There was an underway effort to switch to something based on https://github.com/KhronosGroup/glslang and https://github.com/KhronosGroup/SPIRV-Cross :

• We only have to work on the part that interest us (XKSL) rather than the full shader stack (HLSL to GLSL, etc...)
• Maintenance is greatly reduced
• Much more things supported out of the box (CS, GS, new shader models, optimizers, etc...)

The design idea is:

• Customize glslang HLSL frontend to be able to parse XKSL to SPIRV (with some XKSL extensions)
• Rewrite a new XKSL "mixer" that will work at SPIRV level (rather than source AST level, making things much simpler)
• Leverage on SPIRV-Cross to output to any format we want: HLSL, GLSL, Metal, SPIR-V, etc...

So far we have a prototype for HLSL generation but there's still quite some work to do on it, and then need to add support for GLSL and others.

[tzachshabtay]

Have you considered ShaderGen as a possible alternative?
https://github.com/mellinoe/ShaderGen

[tebjan]

@tzachshabtay interesting tool, that could help with code completion when writing shaders... if you add/use the right fake shader libraries to the c# file, the visual studio c# editor would provide all the comfort of code completion and so on... see also #157

[tebjan]

also this looks very interesting, maybe it can help, even has a gpu debugger: http://www.ilgpu.net/

[indigozero]

I just want to be clear on the design for this Epic.

• Take the code from https://github.com/KhronosGroup/glslang/tree/master/hlsl (or start from scratch) and extend a copy of it to create support for XKSL
• Use result to be able to use glslang to convert XKSL to SPIRV.
• Use resulting SPIRV with SPIRV-Cross to convert to any shader language depending on desired shader architecture.
• Implement compilation workflow in to existing tooling/compilation workflow of Xenko.
• Include support for other shader types to use conversion part of the workflow
• Include support for other shaders in existing tooling

The last two list items I'm not sure are part of the expectation of this Epic.

[xen2]

There is already such a fork at https://github.com/xenko3d/glslang
Last time it was tested, D3D was working.

What needs to be done:

• Add proper unit testing on our glslang (there was manual tests but this needs to be reorganized)
• Bring up OpenGL (last time I tested there was a bunch of small issues, esp. Semantic Name to properly transmit)
• Bring up Vulkan
• Review Xenko integration

[berwyn]

Just out of curiosity, how open would the team be to supporting something like ShaderGen or ILGPU? Personally, as a newbie to gamedev but an old hat at C#, it really appeals to me being able to apply my existing knowledge and tooling to the problem of shader programming rather than having to learn a new syntax (and, to be fair to XKSL, this would apply equally to HLSL, GLSL, and MSL) and potentially having to deal with no tooling or at least tooling that may not be up to par with e.g. OmniSharp, Visual Studio, StyleCop, and even just the built-in things Roslyn itself has like quick fixes.

I think XKSL and SPIRV-Cross is definitely a good approach to re-using existing shader code people might have and to welcome folks that do have experience with shading languages, but a C# solution might be more friendly to people newer to the field, and just generally to new programmers at large (though honestly a visual shader setup like Unity and Unreal have is probably better for people entirely new to programming, but that's a whole different can of worms).

Collaborating on these solutions with Eric or Marcel could also be a way to share the burden of maintenance on that front as well, since they both already have vested interest in their respective libraries being capable and useful. ShaderGen, at least, already has very broad output support covering D3D11, the OpenGL families, Vulkan, and Metal (namely, all the things Eric's Veldrid rendering library supports).

Sorry that this turned into a bit of a long-winded thing, but it's a feature I'm super keen on.

[xen2]

@berwyn Interesting subject.
I worked on such a C#/MSIL=>shader system many years ago too.
I would be totally fine to have it as an additional approach to write shader code.

[Aminator]

@xen2 I am actually currently working on a MSIL to HLSL compiler in my little DirectX 12 engine where you can set shaders as material attributes at runtime. It is still in its early stages but it works quite well and even works with the new DirectX Shader Compiler which would allow cross-compiling to other shader languages. I tried to keep it very similar to how materials and shaders work in Xenko so i can maybe port it over later.

[xen2]

@Aminator9000 Great, please keep us posted! Can't wait to see what comes out of it.

BTW, if still discussing about MSIL=>HLSL, please make a new github issue on next answer.