JoeJ said:

I'm just thinking, could you add the array to the ray payload?

We should keep that small, but technically it might be still better than VRAM.

I'll try anything! I don't need to read or write the SSBO on the CPU end of things.

I tried the rayPayload method, but it hangs.

OK, I think that I have the SSBO kind of working. It takes a long time to initialize, and the output is garbage:

Nice looking bug.

I could not find the related code, but are you sure each pixel gets its own unique range in memory for the array?

I'm not sure what you mean about range. Can you please elaborate?

I guess you need a array of size N for each pixel.

So you need to allocate screenWidth times screenHeight times N times elementSize for the SSBO.

In the shader you then address it somehow like:

ssbo[(curPixelX + curPicelY*scrWidth) * N (* size) + arrayIndex]

To ensure concurrently processing pixels pixel do not accidentally overwrite each others memory.

So you'll need the memory of many frame buffers.
But you could render the image in smaller blocks one after another to reuse a smaller amount of memory ofc.

Still, required bandwidth will be huge.

Thank you for the information. I am not really certain why it works now, but it does. And it's no slower than using an array, but not much better.

Very interesting.

Also keep an eye on total VRAM usage, if you have a way to observe this.

If there is no clear winner, you should also test in on other GPUs, where the difference might be different. ; )

It's not working. I was wrong. :( Sorry JoeJ.

Hmm.. I wonder if it's perhaps an alignment issue.

Should I just make everything a vec4?