Well frame delay in that case is like an instruction to pass the param on next frame, I think if you try to pass the output back inside the shader you gonna pass it on same frame this called iteresation witch was a special hidden pin on shader node (dunno if it survived) but I was looking on sort shaders examples recently and thay were all using this iterations basically.
I tried to convert the buffer in a texture with a tFX from microdee (BufferToTexture)
And use Framedelay for textures.
This way it is possible to sample the feedback buffer in the compute shader with SampleLevel().
But it doesnt work correctly and the algorithm glitches away by sampling wrong values. Seems like it is caused from the BufferToTexture working only every second frame.
Patching a workaround for that is slwoly getting too hacky for my use case.
The algorithm works in general. I tested it against a readback and normal framedelay.
It realy needs “only” a framedelay for compute shader buffers, either in patch or as a code solution.
I hope someone can help here. What means the hidden pins “defines” and this “iterastion count” (should probably mean iteration count)
Files are here, probably needs MD.ecosystem and InstanceNoodles
Ah cool, and so funny that always there is some weird stuff appearing.
Same here, I also upload my implementations of OddEvenMergeSort for you to look at it.
There are two versions:
Based on Texture Feedback: works, but is slow and only works with preview open for the framedelay node.
Based on RW Buffer: has a data sink bug. Somehow the algorithm looses the particles over a certain amount of frames (or sets them all at index 0).
So it works half way and needs some bug fixing and an idea where this data loss comes from (???) OddEvenMerge_CS.zip (19.9 KB)