[pixelpoet]

There's no lack of "pixel-level performance optimisations" on GPUs, and just because basically the whole world seems to think that graphics programming == using some rasterisation library like OpenGL or DX or Vulkan or whatever for realtime applications, doesn't mean you're forced to use it or that that's all there is.

Just fire up OpenCL (or CUDA, if you must) and start executing some data-parallel kernels.

[Jupe]

That's all a little beyond me at this point. But very compelling!

As the original simulation shows, the idea is to calculate the difference and proximity of the pixels. So the drawing part is just a projection...

The ease of getting a memory buffer pointer, setting pixels within my calculation loop with simple offsets was very simple and compelling. I think I should look deeper into OpenCL/CUDA for this use-case, as I mentioned in the other response to my comment.

Thanks!

[pixelpoet]

No problem, and I highly recommend using OpenCL to get started, it's actually pretty short and straightforward (lookin' at you, Vulkan compute!). So basically, the stuff in the for-loops you had before, that's the kernel you'll be writing.

I daresay it's actually easier to render things this way than getting lost in the weeds with API docs etc. A simple Mandelbrot hello-world example should be easy to understand and get compiling, and you can go from there.

[dartos]

Is vulkan strictly a rasterization library?

I thought you could also do numeric calculations with compute shaders.

[pixelpoet]

Yep you can, but there's still an astronomical amount of crap you have to do that has nothing to do with pure compute. OpenCL has none of these problems, and is IMO just the perfect compute API.