Julien Barnoin

[2/3]
Even just focusing on the GPU we have:
- CUDA supporting only NVIDIA and no graphics shaders.
- OpenCL is multi-platform but no graphics shaders and pretty much dead anyway?
- Metal (MSL) is Apple-only.
- GLSL on Vulkan is viable but clearly in maintenance-only mode and no longer evolving.
- HLSL works and is being worked on, but is controlled by Microsoft and not a standard.
- WebGPU (WGSL) might be an option for native applications at some point, but not yet.

Anything else?

Like 27 February at 14:36 | Open on mastodon.gamedev.place

9 comments

Julien Barnoin

[3/3]
Regardless, none of these address natively compiling to the CPU.
There's promising things like VCC https://shady-gang.github.io/vcc/ but it seems too early and risky to base a project on it for now.

My use case is a raymarching based game engine, where the content is defined in terms of functions representing an SDF.
I want to be able to use these SDF-defining functions and their associated data in CPU and GPU compute for physics and gameplay, and on GPU graphics for rendering.

27 February at 14:36 | Open on mastodon.gamedev.place

Doug Binks

@julienbarnoin

- SYCL has potential, but it's not there yet, especially on Windows.
- ISPC on CPU is excellent, but although a test project showed SPIR-V to ISPC was workable for targetting CPU and GPU with the same code, it's not a supported feature. I also don't know if ISPC has a healthy future.

27 February at 14:47 | Open on mastodon.gamedev.place

Jari Komppa 🇫🇮

@dougbinks @julienbarnoin
Plus rocm if you want amd only, and oneapi if you want intel only.. both claim to be open but well, while controlled by a single company, not really.

27 February at 14:49 | Open on mastodon.online

Julien Barnoin

So far my kludgy solution is a mix of C and GLSL, where I can share some header files across the languages for common data structures, with some severe restrictions and terribly ugly macros. I can't share any code, I have to copy and adapt it, so my SDF has to stay in GLSL-land only.

I can actually run my GLSL code on the CPU thanks to llvmpipe, which is cool. But:
- I can't rely on it being available
- I can't debug it with standard tools
- GLSL is very restrictive for general programming

27 February at 14:48 | Open on mastodon.gamedev.place

Danil

@julienbarnoin OpenCL is dead.
Where ROCM?

27 February at 14:45 | Open on mastodon.gamedev.place

Andrzej Lichnerowicz

@julienbarnoin scopes? https://sr.ht/~duangle/scopes/ - I really wanted to give it a try. If I were more into graphics or gamedev I probably would. Everything @lritter posts about it makes me go „wow”. I just found the entry barrier too steep with its sparse documentation. But for someone more committed I think it might be great :)

27 February at 15:04 | Open on mastodon.gamedev.place

Julien Barnoin

@unjello @lritter Thanks, I hadn't seen that yet and will look into it.

27 February at 15:14 | Open on mastodon.gamedev.place

Leonard Ritter

@unjello @julienbarnoin we're still looking for a documentarian :)

27 February at 15:33 | Open on mastodon.gamedev.place

Fabian Wahlster

@julienbarnoin Ignoring HLSL/PSSL makes targeting consoles quite hard though and glslang compiler has a HLSL frontend nowadays. Having a standard is nice, but slows things down sometimes. Vcc sounds interesting, it's on my list to try next to circle-lang with SPIR-V target. Slang innovates but is not very portable either. The situation now is much better than just a few years ago. But all major game engines still heavily rely on tons of macros, transpilers, spirv-cross etc.

27 February at 15:25 | Open on mastodon.gamedev.place