Tracy GPU profiling #1134
Tracy GPU profiling #1134
Conversation
cmeissl
force-pushed
the
feature/tracy_gpu_profiling
branch
from
7f8314e
to
c2cdc09
Compare
cmeissl
force-pushed
the
feature/tracy_gpu_profiling
branch
from
c2cdc09
to
f8476b4
Compare
Codecov ReportPatch coverage has no change and project coverage change:
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
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
cmeissl
force-pushed
the
feature/tracy_gpu_profiling
branch
from
f8476b4
to
9bf018c
Compare
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 |
|
|
||
| let context = client | ||
| .new_gpu_context( | ||
| Some("GlesRenderer"), |
There was a problem hiding this comment.
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()); |
There was a problem hiding this comment.
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.
cmeissl
force-pushed
the
feature/tracy_gpu_profiling
branch
from
9bf018c
to
2228b12
Compare
PR for showcasing tracy gpu profiling
TODO
wait for release of profiling (bump tracy-client to 0.16.2 aclysma/profiling#56)profiling1.0.11has been released which includes tracy-client1.16.2Example:
