Render assets diagnostics

[hukasu]

Objective

There have been problems with MeshAllocator and MaterialBindGroupAllocator losing track of asset changes, then it would be nice to have an automated way of checking if the number of allocations is growing uncontrollably.

Solution

Create diagnostics that collect measurements of allocations from MeshAllocator and MaterialBindGroupAllocator, and number of render assets present

[mockersf]

Suggested change

	env:
	RUSTFLAGS: "-C debuginfo=0 -D warnings"

not needed

[mockersf]

Suggested change

	env:
	RUSTFLAGS: "-C debuginfo=0 -D warnings"

same here

[hukasu]

this one existed before this change, are you sure this is no longer needed?

[hukasu]

and what about the ones on weekly.yml? they are just ctrl+c ctrl+v from this one

[mockersf]

Suggested change

	env:
	RUSTFLAGS: "-C debuginfo=0 -D warnings"

same

[tychedelia]

Having tests to make sure we don't break things in the future would be nice. I think we should wait for wgpu 25 to see if we can use the noop backend as it's ideal for this kind of thing.

[hukasu]

François commented about the NOOP backend, so i though it was already available, but it is still not?

[tychedelia]

François commented about the NOOP backend, so i though it was already available, but it is still not?

Pretty sure it's just in 25, which I'm hoping to land next week. It would be awesome to have a footprint for allocating buffers in non-e2e tests.

[JMS55]

Wgpu 25 has landed!

[hukasu]

@JMS55

Unable to find a GPU! Make sure you have installed required drivers! For extra information, see: https://github.com/bevyengine/bevy/blob/latest/docs/linux_dependencies.md: NotFound { active_backends: Backends(0x0), requested_backends: Backends(NOOP), supported_backends: Backends(VULKAN | GL), no_fallback_backends: Backends(0x0), no_adapter_backends: Backends(0x0), incompatible_surface_backends: Backends(0x0) }

.set(RenderPlugin {
    render_creation: RenderCreation::Automatic(WgpuSettings {
        backends: Some(Backends::NOOP),
        ..default()
    }),
    ..default()
})

[IceSentry]

I think this PR could be split in 2 parts. One PR to add the diagnostics then one for the tests. The diagnostic one could be merged ASAP. The main reason I suggest this is that adding diagnostics doesn't have to touch any of the CI stuff. So if CI breaks because of this PR we don't have to revert everything and only the part that needs to touch CI.

[IceSentry]

LGTM!

We should definitely keep that kind of metrics in mind in the future and add this for anything that uses memory.

[hukasu]

What broke was the PR for dynamic materials, should i make a solution that already allows the diagnostics of dynamic materials? or just fix for struct-backed materials for now?

[alice-i-cecile]

should i make a solution that already allows the diagnostics of dynamic materials? or just fix for struct-backed materials for now?

Former please :)