Doom Eternal does not have a main or render thread | Hacker News Reader

Doom Eternal does not have a main or render thread

twitter.com

39 pointsvaland6 comments

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...

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.

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.

Somewhere in the thread he mentions that they on Windows have a thread that is somewhat "special" but that it does as little as possible and that this isn't needed on the consoles.

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.

You mean after a decade or so

Reply on news.ycombinator.com