zlacker

"Shaders could be authored directly in SPIRV" oh god please no lmao

Also to answer your question, no. The hlsl to dxil translation is basically owned by microsoft. There's been little effort to move away from that

>>noahwh+(OP)
Well... they are rewriting & upstreaming DXC to LLVM main (https://github.com/microsoft/DirectXShaderCompiler/wiki/Cont...) and want to kinda deprecate DXC. IIRC currently only compute shaders are supported but I may be very wrong.

>>noahwh+(OP)
I am really serious about direct authoring of shaders using SPIR-V (with probably a little SSA checker on the side). We can reasonably think it will significantly increase the compatibility and bug avoidance of shaders among various drivers (and that is priceless when you think QA of big video games spaning many different drivers).

I am perfectly aware this will require a bit more upfront work to write shaders, but due to their life cycle, it should be benign and we should get all the benefits (not even mentioning to free the SDK dependency from a massive and complex high level shading language compiler).

I am going to give it a try. I need first a SPIR-V assembler, the one from the khronos spriv tools and the one from llvm are c++ diarrhea then a definitive nono, have to write my own. Let's think long run here: we don't have a _REAL_ standard very high level language yet (python? lua? javascript? perl5? ruby? so_many_others?), I'll go rv64 assembly then (I'll write a mini rv64 interpreter for x86_64).

>>NekkoD+g3
llvm (apple) is a mistake, but I am not expecting microsoft to do anything else than mistakes anyway.