zlacker

[parent] [thread] 9 comments
1. sylwar+(OP)[view] [source] 2024-02-10 12:41:06
I guess the less troublesome would be something like HLSL/GLSL->SPIR-V<->DXIL, or shaders could be authored directly in SPIR-V.

In vkd3d (from wine), I think you have a DXIL->SPIR-V translater (much more robust than any high level shading language converter since it is a much more simple intermediate language).

That said, apart from this abomination of llvm, is there a HLSL->DXIL compiler written in plain and simple C99 (namely which require NOT gcc or clang to compile)?

replies(2): >>noahwh+o2 >>slimsa+p2
2. noahwh+o2[view] [source] 2024-02-10 13:10:14
>>sylwar+(OP)
"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

replies(2): >>NekkoD+E5 >>sylwar+va2
3. slimsa+p2[view] [source] 2024-02-10 13:10:21
>>sylwar+(OP)
Yes, SPIRV->DXIL does seem tempting and worth exploring. Very recently I learned Mesa has such a tool, spirv2dxil, though unsure how robust/featureful it is compared to HLSL->DXC->DXIL.
replies(1): >>sylwar+o92
◧◩
4. NekkoD+E5[view] [source] [discussion] 2024-02-10 13:50:02
>>noahwh+o2
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.
replies(1): >>sylwar+za2
◧◩
5. sylwar+o92[view] [source] [discussion] 2024-02-11 10:28:51
>>slimsa+p2
I compile mesa every week and I missed that... lol.

That said, vkd3d(wine) is plain and simple C, and I suspect that mesa tool to be part of microsoft "push" in mesa, dirtying it with c++.

replies(1): >>slimsa+zW3
◧◩
6. sylwar+va2[view] [source] [discussion] 2024-02-11 10:42:22
>>noahwh+o2
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).

◧◩◪
7. sylwar+za2[view] [source] [discussion] 2024-02-11 10:43:08
>>NekkoD+E5
llvm (apple) is a mistake, but I am not expecting microsoft to do anything else than mistakes anyway.
◧◩◪
8. slimsa+zW3[view] [source] [discussion] 2024-02-12 03:04:12
>>sylwar+o92
are you saying vkd3d also has a SPIRV->DXIL converter? I imagine it having the opposite (DXIL->SPIRV)
replies(1): >>sylwar+fk6
◧◩◪◨
9. sylwar+fk6[view] [source] [discussion] 2024-02-12 20:32:31
>>slimsa+zW3
Nope, I said vkd3d has a DXIL->SPIRV converter (since it runs dx12 on vulkan), not a SPIR-V->DXIL (which would be running vulkan on dx12).
replies(1): >>slimsa+Tp7
◧◩◪◨⬒
10. slimsa+Tp7[view] [source] [discussion] 2024-02-13 04:08:06
>>sylwar+fk6
makes sense, thanks :) Just wanted to check I didn't miss something haha!
[go to top]