I’m thinking about best practises when designing a game engine with a Vulkan renderer.
Adam Sawicki (creator of Vulkan memory allocator library) pointed out that it’s good practise to design a game engine with a thread pool and a generic task system to make use of all cpu cores efficiently.
A good code example can be found on stackoverflow: “C++17 thread pool”.
So far I can’t find any disadvantages of this approach. What are your opinions on this?
I know that the answer to this question very much depends on the project’s goals, code structure and synchronisation. But is there any general downside of using a threadpool when dealing with Vulkan if we assume I can get all synchronisation done correctly? Is there a common alternative?
But… that is the most common downside. The most common problem with threading anything is messing up synchronization. Such failures are often extremely difficult to test, manifesting primarily as random, spurious behavior. And the situations that might lead to deadlocks are often exceedingly complicated, based on a myriad of assumptions scattered throughout dozens of systems in your codebase.
So yeah, threading your game system is great, assuming you’ve solved the biggest problem with threading your game system.
That doesn’t mean you shouldn’t do it; if you need the performance, do what you’ve got to do. Just don’t go thinking that it’ll be easy.
Another problem to look out for when rolling your own threading, besides synchronization, is load balancing. Making sure threads are all equally busy isn’t that easy either.
Toolkits like Intel’s TBB make both issues easier to deal with, but that might not be an option if your game engine must run on non-intel hardware.
Despite the problems, my feeling is that threading is an absolute must for today’s hardware.
Not using multiple threads is basically ignoring a large chunk of the hardware.