This is a wild thought I had a while back, but since then it kinda just sat in the back of my head until today. I’m thinking about making an Odin → SPIRV compiler. It should be realistic to do, and the following features theorhetically make it possible to write shaders in and feel good about yourself:
- Native support for vectors and matrices.
core:math/linalg can be used to cover the rest of the unsupported features. Initializing these vectors will be a bliss. Also being able to use swizzling is nice.
- Attributes can theorhetically be used to extend the language. Something like
@(layout=1) could be used akin to GLSL’s location(layout) thingy. Or @(in) and @(out) as extra attributes.
There are probably other things that I haven’t yet thought through, but in theory it should be possible to implement. But there are a lot of “extra” things that can get in a way:
- Import system doesn’t work for shader code. Shaders are typically small, 1 file long and they might not use other files. There are some pipelines in the wild that have fancy macros and includes in shaders, like in Unity, which may create a need for putting multiple shaders into the same directory, but main files would collide. I guess having
@(export, private="file") on the main function of each shader could make writing shaders less painful, if you were going to do that in a single directory. Otherwise I think defaulting to -file compilation compiler option sounds not bad.
- Lots of unneeded features: bitsets, bitfields, allocators, context, or_return, defer, pointers, strings. You will never use these in a shader code.
- Can’t use anything from the core library or the vendor library other than the math package.
Which lead me to think, that even if one makes a SPIRV compiler from Odin, it shouldn’t be a part of the Odin compiler. Well, I guess all of that does make it a different language. What do yall think of this idea? If something like that were to exist, would you like to be using that instead of glsl/hlsl? Is there anything else that could provide benefit to writing shaders that I haven’t thought of?
3 Likes
Googling some stuff, found this translator from LLVM to SPIRV: GitHub - KhronosGroup/SPIRV-LLVM-Translator: A tool and a library for bi-directional translation between SPIR-V and LLVM IR
Seems interesting, and also seems like Zig actually did have a SPIRV backend.
2 Likes
I’m working with wgsl and it’s a pretty bad language. I’d much rather be able to use odin and transpile that to SPIRV. The only downside is that it wouldn’t be cross-compatible with the web anymore.
1 Like
So the short answer is: I would highly recommend against using a general purpose language like Odin on the GPU, no matter how much you may dislike other shading languages.
You’d have to restrict Odin by a lot to the point it wouldn’t be Odin any more by any stretch. And you’d have to be extremely careful what parts of Odin (and the core library) you could use in the first place.
I highly recommend just using something like GLSL, HLSL, or whatever instead for the GPU.
P.S. I think a lot of people want Odin on the GPU just because they like Odin’s syntax and that’s it. There isn’t anything that special about Odin that would make it better than any other shading language.
2 Likes
Yes, and I have acknowledged it in the OP. You’d have to remove too much and it won’t be the same language anymore.
1 Like
Just for reference if you don’t know about it already: there is hcc, a C-to-SPIRV compiler by hero_dev on Twitch (a Mediamolecule guy, made this in his spare time).
No idea how good the project is though, haven’t looked at it in depth or used it myself.
Wouldn’t it make more sense to just write your own shading language that looks like Odin and compiles down to SPIR-V?
What are the pain points of the more traditional odin ↔ glsl/hlsl pipeline that would potentially be solved with an odin ↔ pseudo-odin approach? I had that off-thought in my brain too, but beside the mental load of needing 2 sets of syntax, i’m not entirely sure what else would be improved.
I’m also curious how rust-gpu approached this problem and if they actually have any benefit from using rust as a shading language. I haven’t looked much into it, but perhaps the question i asked can be answered by them.
From what I know there aren’t any major issues with GLSL. I mean of course, that might be different in more advanced pipelines where you might have a lot of shader code reuse, and may want to need to store shader code across multiple files. I’m thinking something like Unity’s URP shaders. But that should be doable with standard GLSL/HLSL, as far as I know.
Given that rust rolled own their own thing I doubt it means much about the state of problem. That’s kinda how rust tends to solve problems. If it’s there and its not rust they’d just make a rust version of it, regardless of whether existing implementation. I personally wouldn’t really use rust-gpu for anything other than compute shaders. Their docs don’t mention swizzling or anything of the sort, so out of the box it’s going to be inferior to GLSL.