I'm actually planning to resurrect a dead raytracer project (
https://github.com/mambastudio/MambaTracer) that has a GPU backend. And possible develop a future 2D API (a lot of work I know). There is an interesting world in multipurpose programming of GPUs, and it took me a while to realise prefix sum is the “hello world” in that area. As a matter of fact, most GPU code without efficient GPU prefix sum, don’t perform well for specific algorithms that might require some scan data, and that’s where CUDA dominates, which has an amazing implementation, and not in other areas such as OpenCL. The raytracer I was making, I encountered a bug that took me I think a month to deduce after some frustration, based on a discovery of my rudimentary struct implementation (through classes and annotation – which I totally agree with you they are a bit annoying) had an misalignment layout which made me rethink, something is wrong with my model approach. So, I needed to solve data and layout representation between java and native code, to be simple, concise, with little headache. If you notice the TypedMemory, the idea is to ensure a user can implement their own libraries with data models without depending on it, and thus becomes a simple plug. Unfortunately, @size will make your code have it as a dependency. Hopefully one day we have multifields as stack allocated arrays (
https://web.archive.org/web/20251101203905/https://cr.openjd...) , hence maybe have value `record(char c, float[3] array) {}`