[HN Gopher] Doom GPU Flame Graphs
___________________________________________________________________
Doom GPU Flame Graphs
Author : zdw
Score : 29 points
Date : 2025-05-01 14:30 UTC (1 days ago)
(HTM) web link (www.brendangregg.com)
(TXT) w3m dump (www.brendangregg.com)
| forrestthewoods wrote:
| Neat.
|
| I'll be honest, I kinda don't get flame graphs. I mean I
| understand what they are. I have just always strictly preferred a
| proper timeline view ala Superluminal or Tracy.
|
| Using 20ms chunks for a game is fine but also super weird. Ain't
| no game using 20ms frames! So if you were using this for real
| you'd get all kinds of oddities. Just give me a timeline and call
| it a day plz.
| tibbar wrote:
| 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.
| Veserv wrote:
| 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 then 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.
| rawling wrote:
| A few comments, 2 days ago
|
| https://news.ycombinator.com/item?id=43846283
___________________________________________________________________
(page generated 2025-05-02 23:00 UTC)