Track object usage

[almarklein]

Closes #356

The idea is quite simple, bump a counter when an object gets created, decrease it when it's destroyed. We have wgpuGenerateReport that produces a similar list, composed by wgpu-core. We can perhaps combine these. At least report both. Then when leaks occur, it'd be easier to see where this happens.

I got enthusiastic about adding more diagnostic data. I added a base class that can be subclassed to produce diagnostic data in the form of a dict. Diagnistics subclasses can be created for e.g. system info, object counts, wgpu-native info, wgu-native object counts, etc. There's a function that can produce a textual report (table) from the produced dicts.

• Do bookkeeping of creation and destruction.
• Combine with wgpu-core results?
• Track mem usage for textures and buffers.
• Clean up the old GPU.print_report().
• Tests.
• Docs.

Next up: use this to create extensive tests against memory leaks.

---

To print a full diagnostic report:

    wgpu.diagnostics.print_report()

To inspect (for example) the total buffer usage:

    >>> counts = wgpu.diagnostics.object_counts.get_dict()
    >>> print(counts["Buffer"])
    {'count': 3, 'resource_mem': 784}

---

Running cube.py and then wgpu.diagnostics.print_report():

██ system:

             platform:  macOS-14.0-arm64-arm-64bit
python_implementation:  CPython
               python:  3.9.9

██ native_info:

expected_version:  0.17.2.1
     lib_version:  0.17.2.1
        lib_path:  ./resources/libwgpu_native-release.dylib

██ versions:

 wgpu:  0.11.0
 cffi:  1.16.0
 glfw:  2.5.0
numpy:  1.22.4

██ object_counts:

                      count  resource_mem

            Adapter:      1
          BindGroup:      1
    BindGroupLayout:      1
             Buffer:      3           784
      CanvasContext:      1
      CommandBuffer:      0
     CommandEncoder:      0
 ComputePassEncoder:      0
    ComputePipeline:      0
             Device:      1
     PipelineLayout:      1
           QuerySet:      0
              Queue:      1
       RenderBundle:      0
RenderBundleEncoder:      0
  RenderPassEncoder:      0
     RenderPipeline:      1
            Sampler:      1
       ShaderModule:      1
            Texture:      1         65.5K
        TextureView:      1

              total:     15         66.3K

██ rs_counts:

                  count    mem  backend   o  v  e  el_size

        Adapter:      1    264    metal:  1  0  0      264
BindGroupLayout:      1    152    metal:  1  0  0      152
      BindGroup:      1    344    metal:  1  0  0      344
         Buffer:      4    704    metal:  4  0  0      176
  CommandBuffer:      0      0    metal:  0  0  0    1.56K
ComputePipeline:      0      0    metal:  0  0  0      352
         Device:      1  2.74K    metal:  1  0  0    2.74K
 PipelineLayout:      1    608    metal:  1  0  0      608
       QuerySet:      0      0    metal:  0  0  0       56
   RenderBundle:      0      0    metal:  0  0  0      904
 RenderPipeline:      1    672    metal:  1  0  0      672
        Sampler:      1     48    metal:  1  0  0       48
   ShaderModule:      1    640    metal:  1  0  0      640
  CanvasContext:      2    688            2  0  0      344
    TextureView:      2    304    metal:  2  0  0      152
        Texture:      1    640    metal:  1  0  0      640

          total:     17  7.80K

    * The o, v, e are occupied, vacant and error, respecitively.
    * Reported memory does not include buffer/texture data.

[almarklein]

I left out the idea to measure buffer and texture memory consumption. For buffers this is straightforward, but for textures we'd have to deduce the bits-per-pixel from the texture format, and then its still an estimate for compressed textures.

I think we can come a long way, probably the easiest is to create a big dict that maps texture formats to bbp. Maybe for another pr?

[almarklein]

Updated top post to show an example of the produced diagnostics.

[Korijn]

Nice work! I'm curious to see how valuable this will be when investigating our memory usage patterns.

[almarklein]

I'm curious to see how valuable this will be when investigating our memory usage patterns.

Working on that now.

And found a little annoyance that I fixed, pushed to this branch.