Skip to content

Vulkan Memory Report layer: Vulkan Memory by Usage Type - #28

Merged
olehkuznetsov merged 17 commits into
android-graphics:mainfrom
jimblacklercorp:vulkan-memory-report
Sep 1, 2026
Merged

Vulkan Memory Report layer: Vulkan Memory by Usage Type#28
olehkuznetsov merged 17 commits into
android-graphics:mainfrom
jimblacklercorp:vulkan-memory-report

Conversation

@jimblacklercorp

Copy link
Copy Markdown

Implements VK_LAYER_GOOGLE_DeviceMemoryReport layer providing memory tracking by Usage Type. Exposes VK_EXT_device_memory_report and classifies allocations by Vulkan usage types (surface, texture, buffer, other). Emits Perfetto counters starting with vulkan.mem.app.usage.* and vulkan.mem.driver.usage.*.

Implements VK_LAYER_GOOGLE_DeviceMemoryReport layer providing memory tracking by Usage Type.
Exposes VK_EXT_device_memory_report and classifies allocations by Vulkan usage types (surface, texture, buffer, other).
Emits Perfetto counters starting with vulkan.mem.app.usage.* and vulkan.mem.driver.usage.*.
Comment thread layersvt/device_memory_report/device_memory_report_perfetto.cpp Outdated

@olehkuznetsov olehkuznetsov left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In Vulkan, applications often allocate a single large block of VkDeviceMemory and bind different sections (ranges) of it to multiple virtual resources (like buffers and images) using offsets. This is done to stay within the driver's maximum allocation count limit.

The current implementation of the memory report layer does not track partial memory bindings (sub-allocations). Instead, it attributes the entire size of the physical allocation to the category of the most recently bound resource.

@jimblacklercorp

Copy link
Copy Markdown
Author

In Vulkan, applications often allocate a single large block of VkDeviceMemory and bind different sections (ranges) of it to multiple virtual resources (like buffers and images) using offsets. This is done to stay within the driver's maximum allocation count limit.

The current implementation of the memory report layer does not track partial memory bindings (sub-allocations). Instead, it attributes the entire size of the physical allocation to the category of the most recently bound resource.

Done.

@emrekultursay emrekultursay left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First quick pass.

Comment thread CMakeLists.txt Outdated
Comment thread layersvt/device_memory_report/device_memory_report_handwritten_functions.h Outdated
Comment thread layersvt/device_memory_report/device_memory_report_handwritten_functions.h Outdated

@olehkuznetsov olehkuznetsov left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also ensure the Vulkan layers would be built if only the memory report was enabled.
Populate physical device to instance mapping during vkCreateInstance
to ensure logical device creation succeeds even if the application
creates a device without explicitly calling vkEnumeratePhysicalDevices.
Query extension properties via instance_dispatch_table(physicalDevice)
directly rather than relying on instance singleton map lookup.
Move std::call_once inside InitializeDeviceMemoryReportPerfetto to ensure thread-safe Perfetto initialization and remove the static once_flag from the header.
…ocation

Pre-define static CounterTrack instances for known Vulkan memory report categories to eliminate heap allocation overhead in GetCounterTrack during tracing hot paths.
Remove the handwritten implementation and export of vkEnumerateDeviceExtensionProperties
from the DeviceMemoryReport layer, allowing extension enumeration to be handled
natively via the loader dispatch table and layer manifest.
Introduce helper functions to classify Vulkan buffer and image usage flags
and physical memory property flags into refined memory usage clusters
(staging_transfer, ray_tracing, indirect_gpu_driven, compute_storage,
uniform_constants, geometry_mesh, transient_memoryless, etc.) with
unit tests covering classification precedence.
…esource tracking

Capture and cache VkPhysicalDeviceMemoryProperties on vkCreateDevice, resolve
memory property flags via memoryTypeIndex in vkAllocateMemory, and refactor
Resource metadata to resolve usage clusters dynamically during memory binding
and unbound headroom updates.
@jimblacklercorp

Copy link
Copy Markdown
Author

@emrekultursay emrekultursay left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Please wait for Oleh's approval to merge.

Comment thread layersvt/device_memory_report/device_memory_report_perfetto.h Outdated
Comment thread layersvt/device_memory_report/device_memory_report.cpp Outdated
Comment thread layersvt/device_memory_report/device_memory_report.cpp
Comment thread layersvt/device_memory_report/device_memory_report.cpp
@olehkuznetsov
olehkuznetsov merged commit 23629ec into android-graphics:main Sep 1, 2026
15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants