Repository navigation
device_memory_report: key resources by object type, emit object_type, clamp bindings - #44
Merged
Merged
Conversation
olehkuznetsov
approved these changes
Oct 15, 2026
…pe on allocation events VkBuffer and VkImage handles are only unique within their object type, but resources_ and resource_to_memory_map_ were keyed by bare handle. A buffer and an image sharing a handle value could overwrite each other's usage, size and binding, and a binding's DESTROY source was derived from whichever resource last claimed the handle. - Key resources_ by ObjectKey (std::pair<VkObjectType, uint64_t>, the same key as debug_object_names_) and store the object type on SubAllocation. - Fold resource_to_memory_map_ into Resource::bound_memory so the binding lives with the resource it describes. - OnRecordResourceSize and GetRecordedResourceSize take the object type. - Emit an object_type (VkObjectType) annotation on every VulkanMemoryAllocation event: VK_OBJECT_TYPE_DEVICE_MEMORY for memory blocks, VK_OBJECT_TYPE_BUFFER / VK_OBJECT_TYPE_IMAGE for bindings, and the driver-reported objectType for driver allocations, so consumers can key allocations and join debug names without inferring the type. - Add BufferAndImageWithCollidingHandlesAreTrackedIndependently test.
…nd counter UpdateAllocationUnboundCounter merged each binding's [offset, offset + size) interval without regard to the allocation's bounds, so a binding that extended past the end of its VkDeviceMemory counted bytes outside the allocation as bound, and unbound_memory under-reported. Clamp each interval to [0, total_size) when the counter is computed, so only the part of a binding inside the allocation counts as bound. Clamping at compute time rather than bind time keeps bindings recorded against a not-yet-reported allocation correct once its size arrives. bound_size can then no longer exceed total_size, so the unbound subtraction needs no guard. This matches the Sherlock snapshot, which clamps the same way. - Add BindingsAreClampedToTheirAllocation test.
jimblacklercorp
force-pushed
the
push-kkrqmvkompvk
branch
from
October 15, 2026 18:08
a459025 to
6e4fff9
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two commits:
device_memory_report: key resources by object type and emit object_type on allocation events
VkBuffer and VkImage handles are only unique within their object type,
but resources_ and resource_to_memory_map_ were keyed by bare handle. A
buffer and an image sharing a handle value could overwrite each other's
usage, size and binding, and a binding's DESTROY source was derived from
whichever resource last claimed the handle.
same key as debug_object_names_) and store the object type on
SubAllocation.
binding lives with the resource it describes.
VulkanMemoryAllocation event: VK_OBJECT_TYPE_DEVICE_MEMORY for memory
blocks, VK_OBJECT_TYPE_BUFFER / VK_OBJECT_TYPE_IMAGE for bindings, and
the driver-reported objectType for driver allocations, so consumers
can key allocations and join debug names without inferring the type.
device_memory_report: clamp bindings to their allocation in the unbound counter
UpdateAllocationUnboundCounter merged each binding's [offset,
offset + size) interval without regard to the allocation's bounds, so a
binding that extended past the end of its VkDeviceMemory counted bytes
outside the allocation as bound, and unbound_memory under-reported.
Clamp each interval to [0, total_size) when the counter is computed, so
only the part of a binding inside the allocation counts as bound.
Clamping at compute time rather than bind time keeps bindings recorded
against a not-yet-reported allocation correct once its size arrives.
bound_size can then no longer exceed total_size, so the unbound
subtraction needs no guard. This matches the Sherlock snapshot, which
clamps the same way.