Blackwell (RTX 5050 Laptop, sm_120) Vulkan driver crashes in cooperative-matrix property queries

Gaming and Visualization Technologies APIs Vulkan
1

Summary

On a Blackwell laptop GPU (RTX 5050 Laptop, sm_120), NVIDIA’s Vulkan driver (nvoglv64.dll) access-violates inside cooperative-matrix property queries. Both extensions are affected:

  1. vkGetPhysicalDeviceCooperativeMatrixPropertiesKHR (VK_KHR_cooperative_matrix)
  2. vkGetPhysicalDeviceCooperativeMatrixFlexibleDimensionsPropertiesNV (VK_NV_cooperative_matrix2)

Both extensions and all relevant feature flags are advertised on this device, so consumers (e.g. ggml-org/llama.cpp ggml-vulkan backend) proceed to call the property queries. The driver then crashes the host process.

Environment

  • Hardware: NVIDIA GeForce RTX 5050 Laptop GPU (Blackwell, sm_120). Hybrid laptop, also has an AMD Radeon 860M iGPU.
  • OS: Windows 11 Home Single Language 10.0.26200.
  • Driver: driverInfo: 591.74, driverVersion: 591.74.0.0. ICD reports as VK_DRIVER_ID_NVIDIA_PROPRIETARY (driverID = 4).
  • Device: vendorID 0x10de, deviceID 0x2dd8, deviceType PHYSICAL_DEVICE_TYPE_DISCRETE_GPU.
  • Vulkan SDK: 1.4.341.1 (LunarG).
  • Device API: 1.4.325. Conformance: 1.4.3.0.

Crash 1: KHR cooperative matrix

Stack (resolved against RelWithDebInfo symbols of ggml-org/llama.cpp tag b9016):

nvoglv64.dll!0x00007ffc4f753aa9                                        ← crash site (no public symbols)
ggml-vulkan.dll!ggml_vk_get_device(unsigned __int64 idx) Line 5476
ggml-vulkan.dll!ggml_backend_vk_host_buffer_type() Line 13909
... (consumer code)

Exception: 0xC0000005 Access violation writing location 0x00007FFD2FBE79C0 (address inside vulkan-1.dll’s mapped region).

Behaviour: the count-only call (pProperties=nullptr) returns successfully with cm_props_num=4. The access violation surfaces immediately after.

Crash 2: NV cooperative matrix 2 flexible dimensions

Stack (same build, different code path):

nvoglv64.dll!0x00007ffc4f7538a5                                        ← crash site (no public symbols)
ggml-vulkan.dll!ggml_vk_get_device(unsigned __int64 idx) Line 5392
ggml-vulkan.dll!ggml_backend_vk_buffer_type(unsigned __int64 dev_num) Line 13849
... (consumer code)

Exception: same shape — access violation writing into vulkan-1.dll’s region.

Behaviour: the count-only call to vkGetPhysicalDeviceCooperativeMatrixFlexibleDimensionsPropertiesNV (with pProperties=nullptr) faults; the count never returns to the caller.

Reproducer

// Vulkan 1.4 instance, NVIDIA Blackwell physical device.
// Device advertises VK_KHR_cooperative_matrix and VK_NV_cooperative_matrix2 in extensions;
// vkGetPhysicalDeviceFeatures2 reports cooperativeMatrix == VK_TRUE and the seven NV
// coopmat2 feature flags == VK_TRUE.

// Crash 1
PFN_vkGetPhysicalDeviceCooperativeMatrixPropertiesKHR fn1 = ...;
uint32_t count = 0;
fn1(physicalDevice, &count, nullptr);                          // returns count=4
std::vector<VkCooperativeMatrixPropertiesKHR> props(count);    // crash here or just before

// Crash 2
PFN_vkGetPhysicalDeviceCooperativeMatrixFlexibleDimensionsPropertiesNV fn2 = ...;
uint32_t count2 = 0;
fn2(physicalDevice, &count2, nullptr);                         // crash inside the call

A self-contained reproducer can be built from the source above plus minimal Vulkan setup; the b9016 build of ggml-org/llama.cpp exhibits both crashes through ggml_vk_get_device. Crash dumps (full memory) for both crash paths are available on request.

Triage notes

  • The driver advertises support for both extensions and all relevant feature flags. Either the advertisement is wrong (these features are not implemented for Blackwell yet), or the implementation has a memory bug. From a consumer’s standpoint, the spec contract is broken: a property query that succeeds at the count step should not access-violate when the caller follows the standard two-call pattern.
  • This affects any Vulkan workload that probes cooperative-matrix support on Blackwell. ggml-org/llama.cpp’s ggml-vulkan backend hits this on every model load. Workaround for that project is documented separately, but the underlying driver bug remains.
  • Setting GGML_VK_DISABLE_COOPMAT=1 and GGML_VK_DISABLE_COOPMAT2=1 (env vars consumed by ggml-vulkan to skip these paths) avoids the crash and lets Vulkan inference run successfully on the same device — confirming the rest of the Vulkan stack on Blackwell is functional and only the cooperative-matrix property queries are broken.
2

Welcome @hidden.hand.apps to the NVIDIA Developer Forums.

Thank you for the thorough error description!
I can’t guarantee how quickly someone from the engineering team will look at this, but I’ll try to bring it to their attention.

Thanks!