Game Engines 2021W Lecture 6
Jump to navigation
Jump to search
Notes
Lecture 6 --------- comments on journal Show & Tell concurrency in game engines & godot using gdb with godot (to debug the engine) Journal comments - many of you are making good progress - but many of you seem to be very undecided in terms of project directions - many seem a bit ambitious It is important to really understand what you want to do, but you need to have reasonable goals Strategy: work on a piece of a grand vision - key differentiation - technically interesting May not be too fun on its own Concurrency - notice we saw that godot has lots of threads running - we need them to use multiple cores - but threads make life very difficult, because concurrency with lots of transistors, we get many cores can be general purpose (CPU) or special purpose (GPU, tensor cores, etc) most of the special computational units are SIMD-ish - single instruction, multiple data - so, inherently parallel Some tasks are more straighforward to parallelize - rasterization of 3D graphics Other tasks aren't - game AI, game logic So, what do we do with all the cores? - how do we coordinate activity? well, why not just have different threads work on shared data? - race conditions will lead to non-deterministic bugs We can solve race conditions with locks - when a thread accesses a data structure, it "locks" it, and only unlocks it when done - this is mutexes, semaphores, etc - you can't just use regular variables to do synchronization & locking - BUT YOU DON'T WANT TO DO THIS You want a mutithreaded-friendly architecture, not mechanisms - otherwise, uncontrolled parallelism actually leads to slower code - or it will be buggy Godot is very smart about multithreading https://godotengine.org/article/why-does-godot-use-servers-and-rids Basically, servers are how you run a thread - a server has a particular set of functionality Servers interact via messages Shared data is possible, but it has a clear thread (server) owner, and is shared via special references (RIDs), where, I think, access is by default read only Note that you don't have to think about multithreaded code in Godot most of the time, but you should be aware - don't expect variables to be instantly shared across nodes - instead, use messages (signals) to communicate changes in state