
Doom Eternal does not have a main or render thread - valand
https://twitter.com/axelgneiting/status/1241487918046347264
======
crocodiletears
I've long been fascinated by watching the translation over the last generation
of consoles to jobified systems. The folks at Guerilla Games (Killzone,
Horizon: Zero Dawn) hasve a great document on how they jobified their gameplay
loop for the last Killzone title [0]. The transition to multithreading systems
which greedily take in jobs has enabled exceptionally complex and dynamic
worlds, but depending on the implementation can easily come at the cost of
determinism - which is honestly a pretty niche requirement for modern single-
player titles.

Game engines are like supercars, and occupy a rare space in software outside
of academia where individual developers are continuously innovating on an
architectural level, integrating knowledge from multiple fields, and
enthusiastically sharing their work with their peers.

That kind of development is often too 'in the weeds' to be economic for most
development houses, but I think there's a lot of transferable knowledge
waiting to be picked up on by other developers willing to keep an eye on the
space.

[0] [https://www.guerrilla-games.com/read/killzone-shadow-fall-
th...](https://www.guerrilla-games.com/read/killzone-shadow-fall-threading-
the-entityupdate-on-ps4)

------
rs23296008n1
Interesting since Windows used to have GUI events only going to the main
thread. Window graphics contexts / rendering contexts generally a main thread
thing as well.

Has that changed?

Asserting "no main thread" implies any thread can post and receive events
to/from the OS with no proxies. Sounds good.

~~~
flohofwoe
A game engine only needs very little interaction with the underlying OS
windowing/event APIs, usually just open a window and handle a minimal number
of input- or change-events. That code can easily be isolated into a very small
module doing a minimal amount of "per frame work". My guess is they do window
creation and window system event handling on "some" thread, maybe the same
where main() lives, maybe a different one, but the amount of work this thread
does each frame is so minimal (compared to all the other stuff) that it
doesn't "deserve" a special designation.

I think what the tweet actually implies is that they don't have a main thread
in a sense of a "main system controller thread" which invokes several systems
in sequence (e.g. AI, physics, rendering), and those systems are parallelizing
their work internally, but instead define the "per frame work" as one big
dependency graph of small jobs/tasks without high-level syncpoints between
systems. Speculation on my part though.

PS: I wonder how well traditional _debugging_ works in such a highly granular
system.

------
jsjddbbwj
Wouldn't it be cool if they released the source code like they've always done?
Of course, with Carmack no longer there, I'm just kidding.

~~~
noobermin
You mean after a decade or so

