DescriptorPool: O(1) recycled-descriptor accounting in available()

[nolankramer]

Description

available() walked the entire _recyclingList on every call to tally up the descriptors held in freed sets. Under high churn, scenes that stream in and evict a lot of geometry freed thousands of per-object descriptor sets. That list gets long, and since DescriptorPools::reserve() calls available() once per pool, compile time scales with the number of recycled sets. I saw it ramp past 10ms and stay there after a big spike.

This fix keeps a running per-type total of what's in the recycling list, updated as sets are freed and reused, so available() just reads it. O(number of descriptor types) instead of O(recycled sets).

Does not change behavior - strictly a performance improvement for scenes the churn descriptor sets rapidly.

Also added a quick doc string to compile() and compileTask() that they don't throw, and users should instead expect to read the returned CompileResult

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

In my own app - works as-expected.

Test Configuration:

• Firmware version: NA
• Hardware: AMD Radeon RX 6600 XT
• Toolchain: MSVC
• SDK: MSVC 18.4.2 + Vulkan 4.2

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules