JoshKlint wrote:having never used them before in any API.
I recommend reading the CS chapter of OpenGL Super Bible. Becasue it introduces the parallel programming model so well with good examples. Still applies to Vulkan. Most enlighting read i've ever had
I would say VK needs 10 times more API code than OpenCL. E.g. to upload memory to to GPU, you need to create a temporary staging buffer, copy it there, make a command buffer containing GPU copy commands and sync, upload the command buffer, execute it.
With OpenCL, all this is just one line of code.
To run kernels, you need to create pipeline layouts to specify memory buffers it uses, Make command buffers again containing kernel dispatch and memory barriers to sync.
But the complexity has upsides. Once all this is created, a single command buffer execution per frame can run your whole pipeline. There is no more need to orchestrate each dispatch and barriers from CPU, which is very slow. This gave me speedup of 2 over OpenCL for a project having hundrets of dispatches. Also the kernels themselves run usually faster than the same in OpenCL.
Feature set of the GLSL language is the same as CL 1.x, just pointers are missing. No OOP ofc.
I also found it easy to get going. Rendering with Vulkan is crazy complex, but compute shaders is pretty simple. Once some basic example is working, we can make abstractions to make it as easy to use as OpenCL.
The same would apply to DX12.
It's the only proper way, imo.
But i do not want to use it for general GPGPU things either. I would profit a lot from speeding up my fluid sim, for example. But if i port it, i have to maintain both GPU and CPU branches. And i won't do twice the work until i'm sure the simulator won't change a lot anymore.
Imo, OpenCL also missed the goal of having portable code for both CPU and GPU. Obviously - because GPU parallel programming is very different from CPU multi threading, and scalar GPU threads also differ from CPU SIMD just too much.
Using the same code for both can only work in few cases. Though, a physics solver probably is one of these.
Sadly i don't know anything about the options of using main memory directly on GPU, which would be very attractive here ofc.
AMD GCN GPUs have 256 MB of shared memory, but idk if it's on main ram or vram, and how using this would disable caching eventually.
Recent GPUs from both NV and AMD can now map the whole main ram afaik.
And pointers have been recently introduced to Vulkan, but are still lacking from DX12 afaik.
If there would be serious interest for physics on GPU, that's the first thing i'd try to clarify in detail.
They do not even deal with plain cpp classes.
No, but you could do your own CPP -> SpirV compiler, haha
)
