You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Dedicated blocks get thrown into the blockCount, but I'm trying to see that increase/decrease and want that to correspond with the 64MB allocations that represent heap growth. Would be good to split these counts and memory totals out per heap/memory type.
These could be added without changing the existing stats. Then just subtract them from the existing stats to get a better sense of block allocation growth.
The text was updated successfully, but these errors were encountered:
I'm sorry, but I don't want to add this feature to avoid feature creep.
Why do you need this information?
In what cases are allocations created as dedicated in your code outside of your control (without using VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT flag)? Is it due to their size, or some other reason?
You can emulate desired behavior by having a separate custom pool with non-zero VmaPoolCreateInfo::blockSize (which does not accept dedicated allocations), another one where you would create all the allocations with VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT flag, and fetch their statistics.
Doesn't seem like feature creep, since the default pools have a set of dedicated and non-dedicated allocation. The default pools just don't track or report stats on the count or size of the dedicated allocations (f.e. in the json dump or in getting detailed stats).
I can track which elements I send down for dedicated allocation and approximate sizes, but don't know their exact sizes, memory type, heap used etc. Feels like this is 2 extra numbers per stat. This is mostly our images vs. rtt. All our rtt set dedicated bit. Just that then the blockCount corresponds with our 64MB allocations instead of included 1K to 30MB dedicated RTT allocations.
Dedicated blocks get thrown into the blockCount, but I'm trying to see that increase/decrease and want that to correspond with the 64MB allocations that represent heap growth. Would be good to split these counts and memory totals out per heap/memory type.
These could be added without changing the existing stats. Then just subtract them from the existing stats to get a better sense of block allocation growth.
The text was updated successfully, but these errors were encountered: