Skip to content

Fix Device::availableMemory crash on Vulkan 1.0 instances#1712

Open
mbait wants to merge 1 commit into
vsg-dev:masterfrom
mbait:fix/availableMemory-vulkan-1.0-fallback
Open

Fix Device::availableMemory crash on Vulkan 1.0 instances#1712
mbait wants to merge 1 commit into
vsg-dev:masterfrom
mbait:fix/availableMemory-vulkan-1.0-fallback

Conversation

@mbait
Copy link
Copy Markdown

@mbait mbait commented May 16, 2026

Description

Device::availableMemory() unconditionally calls vkGetPhysicalDeviceMemoryProperties2 with a chained VkPhysicalDeviceMemoryBudgetPropertiesEXT. Both have preconditions that are never checked:

  • vkGetPhysicalDeviceMemoryProperties2 requires Vulkan 1.1 (or VK_KHR_get_physical_device_properties2, promoted to core in 1.1).
  • VkPhysicalDeviceMemoryBudgetPropertiesEXT requires the VK_EXT_memory_budget device extension.

When a VSG application creates a vsg::Instance with VK_API_VERSION_1_0 (still the default of vsg::Instance::create), this function dispatches an unresolved entry point and feeds the driver a struct it never advertised support for. Behaviour is undefined. On Mesa Lavapipe it segfaults inside a driver worker thread during normal scene compilation (MemoryBufferPools::reserveBuffer -> Device::availableMemory). The Khronos validation layer flags it as:

vkGetPhysicalDeviceMemoryProperties2(): Attempted to call with an effective API version of 1.0.0 … but this API was not promoted until version 1.1.0.

Fix

Gate the 1.1 path on both supportsApiVersion(VK_API_VERSION_1_1) and supportsDeviceExtension(VK_EXT_MEMORY_BUDGET_EXTENSION_NAME). When either is missing, fall back to the Vulkan 1.0 vkGetPhysicalDeviceMemoryProperties and treat memoryHeaps[i].size as the budget with zero live usage. The fallback returns a conservative upper bound — buffer pool sizing degrades gracefully instead of crashing.

No public API changes. The 1.1 + extension code path is unchanged for users who request it.

Type of change

  • Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Reproduced and verified on Mesa 25.2.8 Lavapipe (lvp_icd.json) in a GPU-less Linux container with a minimal headless VSG application (vsg::Instance::create(..., VK_API_VERSION_1_0), offscreen framebuffer, one Builder::createSphere frame).

  • Before the patch: SIGSEGV inside libvulkan_lvp.so during viewer->compile(), validation layer reports the API-version violation above.
  • After the patch: clean run, no validation errors, expected image written.

Test Configuration:

  • OS: Ubuntu 24.04 (LXC container, no GPU)
  • Vulkan loader: 1.3.275
  • Driver: Mesa 25.2.8 Lavapipe (LLVM 20.1.2)
  • Compiler: GCC 13.3.0

Checklist

  • My code follows the style guidelines of this project (clang-format clean)
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • My changes generate no new warnings

vkGetPhysicalDeviceMemoryProperties2 and VkPhysicalDeviceMemoryBudgetPropertiesEXT
were called unconditionally, but the former requires Vulkan 1.1 and the latter
requires VK_EXT_memory_budget. On a 1.0 instance this triggered undefined
behaviour and crashed Lavapipe during scene compilation. Gate the 1.1 path on
both preconditions and fall back to vkGetPhysicalDeviceMemoryProperties with
heap sizes when either is missing.
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.

1 participant