search

stephen-hqxu / superterrainplus

SuperTerrain+: A real-time procedural 3D infinite terrain engine with geographical features and photorealistic rendering.
MIT License
12 stars 1 forks source link

Low performance biome generation #6

Closed stephen-hqxu closed 3 years ago

stephen-hqxu commented 3 years ago

Issues

Biome generation algorithm was originally implemented on device side. However after some testing the performance is really bad, the program is totally not runnable when the resolution of the texture exceeds 256^2. This is due to the fact that CUDA is not a good language for critical section, warp divergence kills the performance.

Current mitigation

After that I discarded CUDA completely, and move the codes to host. I was planning to use one thread for a chunk, each chunk will be computed in parallel.

Biome generation is now moved to host side. Multi-threading support on host side was also removed in the recent release. Currently I have no idea why multi-threading will perform so much worse than a single, maybe something to do with the cache.

Quick test shows for a (512^2)*9 biome maps with similar algorithm used in minecraft:

  1. Single thread -> 800ms
  2. 4 threads -> 1200ms
  3. 8 threads -> 2600ms
  4. 12 threads -> 12500ms

(Compiler optimisation max to speed, cache size 8192 bytes for each layer, each thread is assigned with a unique cache so no critical section is needed - performance wise)

stephen-hqxu commented 3 years ago

Update

Currently multithreading support for biome generator has been removed completely, due to the unknown reason that causes low performance on multiple threads.

stephen-hqxu commented 3 years ago

Update

After some painful investigation, the problem appears to be the synchornisation. When one thread access the cache, it will start doing recursive calls, thus blocking all other threads.

I have made a prototype system and push to test. There will be a huge performance improvement if we allocate separate cache for each thread, and remove all sync technology. However unfortunately this is still relatively slower than single threaded version for some unknown reasons. The more threads are used, the worse the performane is.

Some research suggested that it might due to out of cache size since all threads are doing heave recursion, and thus turning to do memory R/W, which trashes the performance.

Mitigation

In the end, I will just discard my multithreading design, and sticks with the classic minecraft single threaded design.

However if I did manage to find a proper solution for that, I will turn back to MT in the future :)