Generating chunks of noise in jobs

[cvbattum]

@CodeSmile

Waiting for a race condition of sorts. No, honestly, using a C/C++ library from within a burst compiled job is dangerous unless you know for certain that this library code behaves nicely when called from a background thread and doesn’t spawn its own threads nor muck with other threads.

Yeah that’s fair. I’m really short on time and this library is nice (and uses SIMD instructions!), that’s pretty much why I’m using it. It’s simple enough that I can just have the source code open on a second monitor and follow the call chain (no multithreading in the entire project and I can find no obvious state changes). But it definitely isn’t ideal and long-term I am planning to just assemble my own noise functions that directly burst-compile from C#.

@CodeSmile

So ultimately, your biggest problem here is the use of the FastNoise libary because it will return you a managed array and that’s no good for jobs.

Should mention that the noise library doesn’t actually return a managed object, it only copies data to a pointer. I simplified that because I didn’t think it mattered to much, but the actual call looks like this:

var noiseData = new float[size * size];
noise.GenUniformGrid2D(noiseData, chunk.worldLocation.x, chunk.worldLocation.y, size, size, 0.02f, 1337);

Obviously that means noiseData can just be any pointer to an appropriately sized chunk of contiguous allocated memory.

@CodeSmile

You omitted an attribute here?

Oop, should be [NativeDisableUnsafePtrRestriction] (will edit)

@CodeSmile

Try one of the “unsafe” collections like UnsafeNativeList. The unsafe ones can be nested in other native collections. They are marked “unsafe” because they perform no integrity checks (ie bounds).

I think you mean UnsafeList? That’s the one I can find. Some googling into this led me to a thread that mentioned ParallelWriter (link: Unsafe containers), in a very similar context as mine. Looks promising!

But I’m still not entirely sold on this approach. It seems overkill because I know the arrays allocated for each job are unique to that job alone, and no other job or thread is going read or write to it until the job is completed. At this point I’m half considering just passing a pointer to each job, pointing to an allocated array for that chunk, taking some ideas from this article (link: Run managed code in Unity’s Job System – COFFEE BRAIN GAMES), but I’m pretty sure this also prevents burst compilation.

@CodeSmile

You can but the results will be far from exciting. Just a single lock in the wrong place can make a heavily multithreaded code run slower than a single threaded code doing the same thing!

I should think that a thread that generates only new data on its own, and just needs read-only access to a noise generator (worst case I copy it), shouldn’t be running into many race conditions, if at all?