Track descriptor pool size, and fail if we smash them

[Keenuts]

When working on the 28_gltf sample, I loaded Sponza, which allocated 630+ descriptors of each type (limit was set to 512). Turns out some drivers are fine with that, other will fail, but then allow as soon as you bump the size of any descriptor type. (https://gitlab.freedesktop.org/mesa/mesa/-/issues/8411) Also, vulkan validation layers don't catch this one.

It might be useful for bigwheels to check the pool allocation limits, and fail when we try to allocate more than we asked for, so we don't end up with a changing behavior depending on the hardware/API.

[chaoticbob]

Yeah, this seems like an oversight. Most of our tests don't really ever go past a few descriptors.

[chaoticbob]

I checked the Vulkan and D3D12 code for this.

It looks like for Vulkan - the expectation was for the driver to fail if the allocation exceeded the pool capacity: https://github.com/google/bigwheels/blob/main/src/ppx/grfx/vk/vk_descriptor.cpp#L109-L116

D3D12 has some amount of checking for pool capacity for when a decriptor set is allocated - there may possibly be a bug: https://github.com/google/bigwheels/blob/main/src/ppx/grfx/dx12/dx12_descriptor.cpp#L74-L96

[Keenuts]

It looks like for Vulkan - the expectation was for the driver to fail if the allocation exceeded the pool capacity:

https://github.com/google/bigwheels/blob/main/src/ppx/grfx/vk/vk_descriptor.cpp#L109-L116

For Vulkan that's a bit tricky: The driver should fail when going over the maxCount limit. However the driver may fail if you go over 1 type capacity. Here the maxCount was 512*3, as we allocated 512 of each. But we allocated 600+ samplers. Meaning we didn't went above the maxCount, but above 512.

Thought soo too but apprently WAI because of the "may" in the spec. Don't understand the logic to have a pool with types and not enforce it but meh 🤷‍♂️ https://gitlab.freedesktop.org/mesa/mesa/-/issues/8411