Doom GPU Flame Graphs • Hacker News Board

Re: Doom GPU Flame Graphs

#11

Post by moralestapia » Thu, May 01, 2025, 3:00 PM UTC

brendangregg wrote: post #10

moralestapia wrote: post #8

Earlier quoted context omitted.

K See [1], and many others. 1: https://web.archive.org/web/20091124115438/https://graphics....

Nice tool. Looks like it uses what we now call a "flame chart" (not a flame graph). I don't know if it ever had an original name, but I've seen these in tools from at least the 1990's.

If I understand correctly, your plot is different because you aggregate all of the sampled data; which is in itself quite useful, btw.

While I was going through my B.Sc., I worked a lot with performance optimization, this was around 2008. I used many tools which were slight variations on the idea of visualizing stack traces. I don't recall if that specifically was a thing or not. I believed it was something that has been doing for decades perhaps, because I was touching gdb, perf, etc... I am now reading about it and turns out that the visualization side of it is relatively recent (not 80s but 00s).

Anyway, I apologize for my initial comment being that harsh, I still think you're cool! :D

Re: Doom GPU Flame Graphs

#12

Post by SleepyMyroslav » Thu, May 01, 2025, 4:51 PM UTC

moralestapia wrote: post #4

petermcneeley wrote: post #3

tbh I find magic trace to be more useful https://github.com/janestreet/magic-trace

No, this samples the GPU as well. That's the novelty.

While novel it also very far removed from hardware. In sense that aggregating what actually going on with work submitted from multiple queues is hard. Even gathering timing events for start stop of each can be confusing and not adequate when GPUs execute more than one shader at the same time. That's not to say its not useful I just dont really trust aggregates even on multithreaded CPU if I can't go check raw events.

Re: Doom GPU Flame Graphs

#13

Post by kammerdiener » Thu, May 01, 2025, 5:17 PM UTC

SleepyMyroslav wrote: post #12

moralestapia wrote: post #4

Earlier quoted context omitted.

No, this samples the GPU as well. That's the novelty.

While novel it also very far removed from hardware. In sense that aggregating what actually going on with work submitted from multiple queues is hard. Even gathering timing events for start stop of each can be confusing and not adequate when GPUs execute more than one shader at the same time. That's not to say its not useful I just dont really trust aggregates even on multithreaded CPU if I can't go check raw events.

It's not using timing-based aggregation. The EU stall samples from hardware include the instruction pointer, which links them to the shaders mapped in the GPU's address space.