-
Notifications
You must be signed in to change notification settings - Fork 907
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
Add infrastructure for counting and reporting internal resources #5708
Conversation
b15dc6f
to
2f7fa47
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bunch of nits, but looking good to me overall. I also see the need for doing the counting at the hal level, but I'm concerned on how to reconciliate this stuff with the existing HubReport
.
What's happening in InternalCounters
and HubReport
is strongly overlapping from a users point of view even though the source of the information is quite different. Either we introduce clear distinction for what is what or (better imho) we merge these new counters into the existing hub report. Another interesting course of action would be to deprecate the hub report, but as long as we have hubs they are quite useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Wumpf's blockage is a superset of anything I could think of blocking on, so approving here.
This comment was marked as resolved.
This comment was marked as resolved.
Added the API at the
I think that they should stay separate. They are two different ways to get different information. It looks like the information is similar but it's different important ways. Having two APIs is fine, and I'm about to a third for allocator reports. If they really have to be unified, then hub reports could be put into |
... for debugging purposes
Fixes #5546
The PR is a first step, let's discuss the approach before I add more on top of it.
This adds an
InternalCounter
type which is internally a relaxed atomic isize when thecounters
feature is enabled and compiles to nothing otherwise.These internal counters can be modified from anywhere with an
&self
reference. The idea is that a user of wgpu-core (and wgpu?) could query these internal counters and log them or display them using some custom overlay mechanism.My primary motivation for this is to help with investigating resource lifetime/leak issues in wgpu, but I think that it would also be useful for users of wgpu.
The third commit might look a bit intimidating: I'm counting all textures, buffers, views, etc. in all hal backends. That's a fair amount of repetition, but I ended taking this route because wgpu-core internally creates some resources that aren't exposed to the API (like staging buffers), that would have to be tracked manually and generally I have more confidence in these counters staying up to date if they are in hal.
That said I expect to add more counters in both core and hal for whatever information will aid debugging.
Next steps:
gpu-alloc
crate that the vulkan backend uses.