GPU utilization idea

[mauminimus]

I assume mchprs creates a list of components to be updated every RT, that get updated in the next RT.
This list could be sent to a compute shader where 2000 or more components would update at once.

Probably a better solution would be to create an array of the components as a buffer that gets stored in VRAM, and every component would have an update flag. There would be two buffers with the same components for gpu reasons.
A thousand threads would look at the list in buffer A at the index of their own ID, update that component if needed, and put it into buffer B. Then that thread would increment where it looks in the list by the total thread count until it gets to the end of the list.
When every thread has finished with the list, buffer A and B are swiched and it starts over.

I think this processing style of components could slow down creations where minimal components update in one RT while increasing performance of pipelined cpus for example.

I don't know how multiple plots would get processed like this, but a "single plot" proof of concept version could work with unlimited rtps.

[mauminimus]

The buffers are needed because this way one component wouldnt update based on a component that is already updated by an other thread.

[commanderguy3001]

we pondered about GPU driven simulation a bunch on the discord before, the problem is that it'd just be a metric f*ckton of work to implement, without knowing that it would be better. there's a few problems:

• you'd have to do EVERYTHING on the GPU, cause doing the actual maths on the states isn't the time consuming part
• the GPU is good at doing the exact same thing on a lot of data, but redstone is doing many different things on a lot of data (inversion, waiting (repeaters), subtraction (comparators), ORing (just two lines together), and other magic that can happen with redstone
• there's A LOT of special cases with redstone, I'll name a row of single tick repeaters fed by a 1t clock as an example, the last repeater will always be enabled (and adding those will make for even more unique cases that the GPU has to go through)
• to allow all those unique operations that can happen, you'd have to do a whole bunch of sorting them into batches, and then executing them as batches
• memory accesses with redstone are by far not sequential, but rather extremely random, which the GPU isn't super good at either
• there's more

So basically: unless someone has a bunch of time and really wants to implement it, it won't happen since it doesn't guarantee higher TPS, and is a lot of work to implement.
One big step towards implementing it on the GPU though would be simulating one plot across multiple threads on the CPU first, but even that is complicated enough.

[commanderguy3001]

to clarify on the "random memory accesses" thing: a single torch may be activated (well, turned off really) by two different circuits, and those two circuits could be any other random one anywhere in memory. and you usually have hundreds if not thousands of torches in a build.

[mauminimus]

Thanks for the feedback!
I agree that special cases would be a lot of work, and everything else too. I will probably try to implement a simple version where not many edge cases are taken care of when I undersand enough about GPU programming.

Best luck for further developement on this awesome minecraft server!