Doom GPU Flame Graphs

I've lived trough the doom craze. My perspective:

It was a game that clearly advanced the state of the art. Even in the month before it came out, people were claiming it simply could not be done technically on the underpowered PC technology of that time. Even after it came out, it took others a year to catch up.

Expectations at release were sky high, and Doom still overdelivered. The tech, the gameplay, the esport aspect, the gritty graphics theming. It was all new and daring.

The BSP was an obscure thing nobody understood. It took the DEU people months to wrap their heads around the NODES datastructure.

When the modding tools were finally available, the whole world became 1 big modding community for the same game. That amount of focus on 1 game has never happened before or since. Modding continues to this day, 30 years later.

Then the source code was delivered, for free, to everyone. It was easily readable and told every secret. We all went crazy. It was studied by every programming student. Even today, no other codebase has the same amount of scrutinity, with every bug and detail documented.

Myhouse.wad was a great example of how far a doom mod can be pushed. But it is also a testament to the collective midlife crisis of the doomers from that age, all of us yearning for the good old days.

It’s not an obsession, it’s probably because Doom is easy to understand from a code perspective, and also addresses a lot of graphical/game code techniques, aka its a perfect hobby from a coding perspective to learn, adapt and tweak. It’s actually the perfect example of Hacking.

Also this hacking started early on, so there is probably tons and tons of documentation and data, again making it a great candidate to work with it from a hacking perspective.

Considering that I hate flamegraphs probably not

The origin problem for flame graphs was MySQL server performance involving dozens of threads: as a timeline view you need dozens of timelines, one for each thread, since if you render it on one (I know this is probably obvious) then you have samples from different threads from one moment to the next turning the visualization into hair. Flame graphs scale forever and always show the aggregate: any number of threads, servers, microservices, etc.

I think great UI should do both: have a toggle for switching between flame graphs (the summary) and timelines (aka "flame charts") for analyzing time-based patterns. I've encouraged this before and now some do provide that toggle, like Firefox's profiler (Flame Graphs and Stack Charts for timeline view).

As for 20ms, yes, we do want to take it down. A previous HN comment from years ago, when I first published FlameScope, was to put a game frame on the y-axis instead of 1 second, so now each column shows the rendering of a game frame, and you can see time-offset patterns across the frames (better than a time-series timeline). We started work on it and I was hoping to include it in this post. Maybe next one.

The difference between a flame graph and a trace visualization is that a flame graph is a aggregate/summary visualization. It helps visualize total runtime attributed to functions.

It is like the difference between seeing the mean of a distribution and seeing a plot of every datapoint in the distribution. They are useful for different purposes.

An example of how you might use it in conjunction with a trace visualizer is that you would select a time span in a trace and generate a flame graph for the selection. This would show you which functions and call stacks were responsible for most of the execution time in the selection. You would then use that to find one of those call stacks in the trace to examine how they execute to see if it makes sense.

> Ain’t no game using 20ms frames!

A frame every 20ms equates to 50 frames per second. Doesn't seem too unreasonable for a modern game.

60 frames per second would be one frame every ~16 ms.

Timelines are good when things happen once, but when you have repeated calls to functions from different places etc., a flame graph helps a lot.

Sandwich views supporting collapsing recursion are the secret sauce for flame graphs imo. See e.g,. https://pyroscope.io/blog/introducing-sandwich-view/

I think flame graphs are perfect for what they do, compressing multi dimensional data down into fewer dimensions.

It makes it a lot easier to visualise at a glance, and sometimes an issue is obvious from the flame graph.

But you're right, for complex issues I find I need to dig deeper than that and view everything linearly.

They're just nice for glaring issues, it's like a mini dashboard almost.

The game model might involve 20ms time slices. The frame rate is simply the best available visualisation of the "action" that the machine can manage.

So, you have your game model, input and output. Output needs to be good enough to convince you that you are in control and immersive enough to keep you engaged and input needs to be responsive enough to feel that you are in control. The model needs to keep track of and co-ordinate everything.

I'm old enough to still own a Commodore 64 and before that I played games and wrote some shit ones on ZX 80, 81 and Speccies. I typed in a lot of DATA statements back in the day (40 odd years ago)!

When you pare back a game to the bare basics - run it on a box with KB to deal with instead of GB - you quite quickly get to understand constraints.

Things are now way more complicated. You have to decide whether to use the CPU or the GPU for each task.

Flame graphs are definitely less sophisticated than Superluminal/Tracy/etc, but that's a part of the attraction - you can visualize the output of many profiling tools as a flamegraph without prior setup. I also think it's a pretty good UX for the "which function is the performance bottleneck" game.

Loads of older console games used 20ms fields in Europe.

Edit: also my laptop can, but I'm not into that sort of thing.