Email or username:

Password:

Forgot your password?
All posts Julien's posts Post Back to profile
Julien Barnoin

[1/3]
The current language situation for GPGPU programming is rather depressing from my point of view.
Today we have a wealth of CPU languages but not a hint of standardized GPU-side compatibility.

I'd love to program everything (CPU, GPU compute, GPU graphics) in the same basic, standardized language.
Does that sound unreasonable? I understand that it's not there yet but I don't see any major effort towards this.

#gamedev #programming

27 February at 14:35 | Open on mastodon.gamedev.place
20 comments
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?

[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.

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

[3/3]
Regardless, none of these address natively compiling to the CPU.
There's promising things like VCC 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
Andrzej Lichnerowicz

@julienbarnoin scopes? 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
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
Danil

@julienbarnoin >standardized GPU-side compatibility.

Compute-shader pipeline is your "default".

To compile binary for GPU with your compiler - you have opensource driver for AMD GPUs in Linux or some ARM-GPUs.

27 February at 14:48 | Open on mastodon.gamedev.place
doseijin // 𐌊𐌀𐌏𐌄𐌔 :BestOS:

@julienbarnoin Zig has an experimental SPIRV backend that allows it to be compiled for both shader and compute applications,and it already can compile some basic shader code to be used in Vulkan (some of the work can be viewed here and compute here). It’s early, but some Zig engines are interested in using it and it could make for some really interesting integration for both CPU and GPU code.

27 February at 14:57 | Open on pl.comofas.org
Julien Barnoin

It feels like the people in the best situation to address this would be the Khronos group. Sadly they seem uninterested in this, they feel like GLSL is just fine as it is and have no one working on evolving it or a next version (I asked).
Their solution seems to be to rely more and more on HLSL instead... Great. 😑

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

@julienbarnoin At the point where there is a push for pointers in the shading languages, that will be the kick in the pants required

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

@NOTimothyLottes Well, I already use pointers in GLSL thanks to VK_KHR_buffer_device_address and GLSL_EXT_buffer_reference, even though they're a pain to use and limited.
I would definitely want what VCC promises - more generic and easier to use pointers, including function pointers.

Not shooting myself in the foot with it performance-wise is my job.
Writing a suboptimal GPU function can be a performance win, if it saves me a CPU/GPU roundtrip. This is my main concern.

27 February at 15:20 | Open on mastodon.gamedev.place
Julien Barnoin

@NOTimothyLottes A related missing feature in GLSL that is a pain for me is characters and string manipulation.

I don't care if it's inefficient, I want to be able to do it and save the pain of a roundtrip to setup some text to be displayed in my UI code (that is already mostly on GPU except for the text parts).

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

@julienbarnoin I'd like code pointers, with ability to setup explicit blocks of register state. So it's possible to have functions that apply to state in registers without all the push/pop stack nonsense which would be prohibitively expensive.

27 February at 15:41 | Open on mastodon.gamedev.place
Julien Barnoin

@NOTimothyLottes Actually on my end, I'd already be happy to see just function pointer constants that could be fully inlined at compile time. This would be quite easy probably, but GLSL doesn't offer even this. Maybe with another layer of ugly macros I could make something work...

See for instance examples here: iquilezles.org/articles/sdfrep
Every time there's an "sdf()" call represents a use for a function pointer that could be known at compile time and still make code reusable.

27 February at 15:48 | Open on mastodon.gamedev.place
Lynne
Max Hollmann

@julienbarnoin CPUs and GPUs are inherently different architectures and the kind of code I'd want to run on each differs. As a result I don't see much value in being able to run code on both. Rather I'd like to have a good language for GPGPU programming, something that facilitates writing GPU programs for GPUs. Maybe something from the APL or Haskell families of languages.

27 February at 15:52 | Open on mas.to
Go Up