Status?

[ib00]

What's the status of this project?

I've been looking for a simple compute framework (like sokol_gfx)...

[bqqbarbhg]

Hi, now this is a repo I did not expect any activity on!

The project is pretty much in a weird limbo between complete/dead, it works well enough that I shipped a depth of field After Effects plugin with it, working on CUDA/OpenCL/Metal/CPU with the same set of shaders. It's also very nice to be able to debug the CPU shaders. I started a misguided rewrite of the project that in the way it always does got way too overengineered.

Unfortunately I don't have time to polish/maintain/document this as of now, but I'm still updating the sources to the newest ones from the actual project that used it, maybe it can be useful to someone.

But thanks for reminding that this project exists, it's actually pretty neat, maybe I'll end up revisiting this idea at some point in the future! (don't hold your breath though :D)

[ib00]

Thanks!

It's hard to find a nice, clean and simple library for compute. Everything is very heavy, and overengineered. In particular, anything for Vulkan is outrageous.

[bqqbarbhg]

Yea that's really true, it was in fact Vulkan backend that killed the rewrite I mentioned :D

[ib00]

Out of curiosity: what part of the Vulkan backend messed up your rewrite?

[bqqbarbhg]

It didn't mess it up by itself, but it really helped kill off my motivation as I don't find the API "fun" to work with, which is pretty important for me when doing non-work projects. My main issues with the API are barriers and memory allocation, here the barriers would have been quite simple to implement but I really didn't want to implement a new Vulkan allocator (and using something like VMA would kind of defeat the purpose of a small one header library.

Thinking back on it, I will definitely want to revisit this concept. The API was just too nice and I can't overstate how magical it was to develop compute kernels on CPU and being able to debug them like any other code. Probably will do it after I finish up with ufbx, but there's still a lot of documentation and polish to be done.

Anyways thanks again for the interest, I had completely forgot about this project!

[ib00]

If you ever decide to revisit this (and add Vulkan/GL backend), let us know. I would be happy to test.

The idea of unified shaders (for CPU/GPU) is fantastic. I have seen a couple projects along these lines:

1. Sean Baxter's circle language: https://github.com/seanbaxter/shaders
2. floor: https://github.com/a2flo/floor

Unfortunately both are super heavy...

[ib00]

I've started to tinker a bit with Vulkan and guppy. Vulkan is indeed an incredibly unpleasant API to work with. Why would anybody design such thing is beyond me...

If you were doing Vulkan backend, how would you approach the kernel compiler? Just add another wrapper that would take gp_kernel, gp_args and gp_buffer macros and just spit out glsl code with layout descriptors, etc.?

[bqqbarbhg]

Yeah Vulkan is really something else...

The issue with having unified kernels for Vulkan is that GLSL is very restrictive. The main issue is that GLSL does not support pointers, which all the other kernel languages in this project do support. I tried some Vulkan extensions that should add pointer support to the language, like VK_KHR_buffer_device_address, but couldn't get far with that.

One option would be to compile directly to SPIR-V from a non-GLSL language using something like clspv, but I haven't looked into it too much as that project seems quite experimental.

[ib00]

I thought that VK_KHR_buffer_device_address largely solved the problem of pointers. What was the issue?

I looked at various options like clspv and some other custom compilers (https://github.com/heroseh/hcc), but none are satisfactory.

It's too bad that we can't have a proper solution for compute. While GLSL is repulsive, is there a feature in OpenCL/CUDA that could not be transpiled to GLSL at source level?