[VK_EXT_device_memory_report] How to handle the relationship between vkCreateDescriptorPool and vkAllocateDescriptorSets?

[ShenghuaLinINTEL]

[VK_EXT_device_memory_report] @zhangyiwei

when vkCreateDescriptorPool is called driver will report the allocation event with pool's memory object id and the pool's size. when app call vkAllocateDescriptorSets to allocate descriptor sets from the same pool, driver will report another allocation event with the the descriptor sets' memory object id and the sets' size.

Since the Sets comes from the pool, so Sets' memory object id is the same with the pool's memory object Id, but it's size is set's size, not the pool's size. since memory object is the same, app will not account it.

if so, driver would rather don't report allocation event for vkAllocateDescriptorSets, instead, only report vkCreateDescriptorPool is enough, am I misunderstanding something? same with other pools like command buffer pools, query pools.

[zhangyiwei]

if so, driver would rather don't report allocation event for vkAllocateDescriptorSets, instead, only report vkCreateDescriptorPool is enough

Your understanding is correct. This is the preferred reporting behavior. Any sort of driver side pool/caching is only reported once when reserved (not necessarily allocated out since drivers may choose to actually get the pages upon pinning during submission).

[ShenghuaLinINTEL]

is there a memory profiling tool on linux/android that already use VK_EXT_device_memory_report so that I can test my implementation?

[zhangyiwei]

ANGLE layering has it adopted in its Vulkan backend long ago. For other tooling, some are WIP, and unfortunately I haven't heard any released adoption yet.