RadeonSI Driver Integrates Perfetto Support

[phoronix]

Phoronix: RadeonSI Driver Integrates Perfetto Support

AMD driver engineer Saroj Kumar has contributed Perfetto integration for the RadeonSI Gallium3D driver as the latest means of allowing tracing/profiling for this open-source OpenGL driver...

https://www.phoronix.com/news/RadeonSI-Integrates-Perfetto

[geearf]

Why is this radeonsi work and not just plain Gallium3D/mesa? Can this not be generic?

[schmidtbag]

Why is this radeonsi work and not just plain Gallium3D/mesa? Can this not be generic?

I was wondering the same thing. 400 lines seems like a lot for a specific driver.
I also don't get what exactly was done here. I don't know Perfetto very well but I can't imagine it really needs to do much with GPUs beyond maybe tracking processes and their resource utilization.

[coder]

I was wondering the same thing. 400 lines seems like a lot for a specific driver.
I also don't get what exactly was done here. I don't know Perfetto very well but I can't imagine it really needs to do much with GPUs beyond maybe tracking processes and their resource utilization.

I took a quick glance at the patch and one thing I noted was an entire file where the only changes seem to be line-wrapping. Maybe there's a non-whitespace change hiding in and amongst those, but it always bugs me to see formatting changes mixed in with functional changes or bugfixes.

As an aside, the standard which appears to be enforced is about 80 columns, which I consider pretty ridiculous these days. At my job, we settled on 112 columns, because that's what some developers claimed you could comfortably side-by-side diff on a 1920-wide monitor, using github's web GUI and the default font. There are enough contexts where people are still using such screens, such as some of our laptops and conference room projectors.

As for the other changes, it seems just to add support for tracing a handful of events. To answer geearf 's question about why it can't be Mesa-generic, these instrumentation points are all in the middle of functions, seemingly designed to exclude other work those functions are doing. So, it's at a finer granularity than you could do at the Mesa level. That's not to say you couldn't also do generic instrumentation at a coarser granularity, or of things which Mesa has enough visibility into, but it's expected that there will be some driver internals you'll want to measure beyond what Mesa can see.

[geearf]

coder schmidtbag Appreciate the answers guys!

[guglovich]

This seems to be the first mention of Saroj Kumar on the site.

[gunwalefancy]

I took a quick glance at the patch and one thing I noted was an entire file where the only changes seem to be line-wrapping. Maybe there's a non-whitespace change hiding in and amongst those, but it always bugs me to see formatting changes mixed in with functional changes or bugfixes. gorilla tag

As an aside, the standard which appears to be enforced is about 80 columns, which I consider pretty ridiculous these days. At my job, we settled on 112 columns, because that's what some developers claimed you could comfortably side-by-side diff on a 1920-wide monitor, using github's web GUI and the default font. There are enough contexts where people are still using such screens, such as some of our laptops and conference room projectors.

As for the other changes, it seems just to add support for tracing a handful of events. To answer geearf 's question about why it can't be Mesa-generic, these instrumentation points are all in the middle of functions, seemingly designed to exclude other work those functions are doing. So, it's at a finer granularity than you could do at the Mesa level. That's not to say you couldn't also do generic instrumentation at a coarser granularity, or of things which Mesa has enough visibility into, but it's expected that there will be some driver internals you'll want to measure beyond what Mesa can see.

Niiiiiiiice! You did a great job. We appreciate the information you have given