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

Tracy GPU profiling #1134

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

cmeissl
Copy link
Collaborator

@cmeissl cmeissl commented Sep 17, 2023

PR for showcasing tracy gpu profiling

TODO

Example:
image

@cmeissl cmeissl changed the title wip Tracy GPU profiling Sep 17, 2023
@codecov-commenter
Copy link

codecov-commenter commented Sep 17, 2023

Codecov Report

Patch coverage has no change and project coverage change: -0.02% ⚠️

Comparison is base (d8600f2) 22.88% compared to head (9bf018c) 22.87%.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1134      +/-   ##
==========================================
- Coverage   22.88%   22.87%   -0.02%     
==========================================
  Files         143      143              
  Lines       23050    23051       +1     
==========================================
- Hits         5275     5272       -3     
- Misses      17775    17779       +4     
Flag Coverage Δ
wlcs-buffer 20.00% <0.00%> (-0.01%) ⬇️
wlcs-core 19.65% <0.00%> (-0.01%) ⬇️
wlcs-output 8.10% <0.00%> (-0.01%) ⬇️
wlcs-pointer-input 21.59% <0.00%> (-0.08%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed Coverage Δ
build.rs 79.76% <0.00%> (-0.97%) ⬇️

... and 1 file with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@ids1024
Copy link
Member

ids1024 commented Oct 30, 2023

maybe abstract gpu profiling and only depend on tracy in anvil?

Are there any other profilers one might use with similar GPU profiling instrumentation? If so, a trait abstracting them makes sense. If not, just having an optional tracy dependency might make sense.

Would it be reasonable to have a trait method of Renderer that calls profiler.scope? (And could also be implemented by a Vulkan renderer, when that exists.) I guess handling span_location! and also being agnostic to different profilers is awkward here.


let context = client
.new_gpu_context(
Some("GlesRenderer"),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When the compositor is used with multiple GPUs, this should probably have different names. Maybe the drm node, though vendor and driver can also be queried through EGL.


impl Drop for EnteredGpuTracepoint {
fn drop(&mut self) {
debug_assert!(self.span.is_none());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doing things this way clashes with the use of ? for error handling; it will panic if ? prevents it from getting to the exit call.

Not sure what to do about this.

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

Successfully merging this pull request may close these issues.

3 participants