Hello, so I have a compute shader code moved into a burst job. The code works nicely when doing a schedule(1,1) (only one thread) However I would like to make it multithreaded. Before i was doing compute.Dispatch(0,numThreads,1,1). What would be the equivalent version with Schedule()?
#Multithread code to Burst Job
primal forge
Also, before the compute shader was reading and modifying the same array from multiple threads, thing that can't be done on with burst, right?
livid rampart
IJobFor or similar, and ScheduleParallel
You can read and write from the same array as long as you modify the same index provided to the Execute function. You can bypass that restriction too if you know what you're doing and won't create race conditions.
primal forge
Mmm, the problem is that it's a simulation code meaning that at each iteration it moves around diferent indexes
Im not sure how the compute shader can read and write multiple times on diferent threads to the same index without breaking
if i add [NativeDisableContainerSafetyRestriction]
it works but
it's not cool
Is it even possible to run simulation code multithreded when you don't know the indexes of each simulation step?
I think being more clear it's going to help. I have a bunch of mesh vertices and I run hydraulic erosion, that takes a random point and moves along the gradient, changing the height of the vertices that it finds
livid rampart
Surely there's some literature out there on parallelising that logic, seeing as it's probably fairly common?
primal forge
Yeah, the literature I have found just say to not care about reading and writing on the same array since after a lot of passes, the results are fairly similar, which makes the race condition less important
hoary galleon
if that's true, why is it not cool to just disable the safety restriction?