Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Graphs for system/context FPS #188

Open
eero-t opened this issue Apr 27, 2018 · 2 comments
Open

Graphs for system/context FPS #188

eero-t opened this issue Apr 27, 2018 · 2 comments

Comments

@eero-t
Copy link

eero-t commented Apr 27, 2018

After there's support for graphing tracepoints (#180), whole system and per-context FPS can be graphed by adding ftrace uprobe tracepoints to suitable functions in user space libraries.

I can provide (Python) code for adding these trace points. It checks from /proc/*/maps which of the currently running processes link relevant (EGL/GLX/Vulkan) libraries, uses readelf to find out buffer swap/present functions offsets in these libraries, and then adds uprobe tracepoints for all of them.

@djdeath
Copy link
Collaborator

djdeath commented Apr 27, 2018

Please, give a link for this :) 👍

@eero-t
Copy link
Author

eero-t commented May 2, 2018

Provided python & shell code by email.

Because gputop knows which processes have contexts, it doesn't need to scan whole /proc/, it can dig the paths to relevant libraries from maps files of just those processes.

Easiest way to get symbol offsets for the libraries, is using readelf binary (or objdump) like the scripts, but it should be doable with libreadlef functions too.

In case of Vulkan, Vulkan driver internal present function need to be tracked (many programs don't go through Vulkan loader, but use address gotten by vkGet*ProcAddress), whereas with EGL/GLX it's enough to track egl/glXSwapBuffers calls.

Easiest way for graphing FPS would be for gputop server to provide it as a counter value.

At least in case of FPS, I would like this to something that is available also for gputop-wrapper. That way I can normalize all the other counter values (other than percentages or Mhz) by the FPS, to convert them to average per-frame values. Such "per-frame" counter values would be directly comparable between different driver versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants