There are literally hundreds of possible architectures. I tried to implement a multithreaded engine and here's what I almost achieved (Almost because I had to stop it for working):
What I tried:
- Client creates render queues
- The engine compile renderqueus (read as: optimized sequence of GL commands)
- The render thread execute GL commands without any locking at all (it just need to lock when swapping the pointers to renderqueues.)
- Compiling commands has little overhead, I have pretty low level abstraction, maybe a higher level abstraction allow to generate
already optimized commands, but I can grant you that I had tons of troubles to get something simple like that correctly syncrhonized anyway
- Renderthread do not block main thread
- Mainthread do not block renderthread
- Reduced lag between input and visualization (seems counterintuitive, but yes using only 2 threads gives better responsiveness even if in theory you have to wait for the queue to be processed, in reality a queue is created almost always before the last queue has finished rendering)
I think a fully real multithreaded engine is possible but would require so much work to squize only few % performance improvement (And note most low-end machines just have 2 cores anyway) that is not worth, achieve something like my solution (3 years of trial and errors and preparation to just create a proof of concept) is already too much effort, and since everyone want to make his engine there's literally no more interest in custom engines anyway.
Wait I search for my thesis slides to give you idea:
here it is:
This is a really simple solution, not really multithreaded, but gives a nice boost in performance and is already much more complex than a single threaded engine.