Game Engines 2021W Lecture 6

From Soma-notes
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