Repository navigation
AGC: Vulkan device creation fails on the NVIDIA proprietary driver since #943 (dma-buf import probe) #1289
Description
Summary
Since #943, no Vulkan device can be created on the NVIDIA proprietary driver on Linux. Every VulkanDevice construction fails with:
AGC graphics: vkAllocateDescriptorSets color transfer: Vulkan result -2
git bisect between cea1ef1 (good) and 539cbd8 (bad) points at 00e6d07 ("keep dma-buf imports write-watched when they leave write protection intact"). It adds ProbeDmaBufImportWriteProtection (GuestBufferMemory.cpp#L1208), which decideImportWatch runs while each device is set up (L316). The probe imports a memfd through /dev/udmabuf (createDmaBufImport, L231). On this driver that vkAllocateMemory fails with VK_ERROR_OUT_OF_DEVICE_MEMORY; the probe reports it and goes on, but every later allocation on the device then fails with the same error, starting with the color transfer's descriptor sets.
dma-buf import is enabled whenever the device lists VK_KHR_external_memory_fd and VK_EXT_external_memory_dma_buf (VulkanDevice.cpp#L837). This driver lists both, and vkGetPhysicalDeviceExternalBufferProperties reports dma-buf buffers with the import's usage as importable, without a dedicated allocation.
In the test suite every GPU test then returns 77 and ctest counts it as skipped, so a run still ends with 100% tests passed (about 160 skipped here). CI runs on lavapipe and does not see it.
Found while rebasing #1239. This issue was investigated and written by Claude Code (AI), and posted by me after review.
Evidence
Arch Linux, kernel 7.2.8, GeForce GTX 1050 Ti Max-Q, NVIDIA 580.178.04, main at 539cbd8:
[write-watch] host imports resolve write protection: no (0 of 4 scratch pages written after a GPU read, 4 after the import); imported ranges stay watched
[write-watch] dma-buf imports keep write protection: unknown (probe failed at vkAllocateMemory, -2); imported ranges are compared
skipped, no usable Vulkan device: AGC graphics: vkAllocateDescriptorSets color transfer: Vulkan result -2
- The probe's import:
vkGetMemoryFdPropertiesKHRgives memory types 0x27f, the buffer allows 0x381, andbindImporttakes type 0 (system heap, no host flags). Importing into type 9 (host visible, coherent, cached) instead fails the same way. - The validation layer (1.4.363.0, core validation) reports nothing before the failure.
APS5_WRITE_WATCH_IMPORTS=watchorunwatchskips both probes, and the suite then passes with no test skipped (407/407 on 539cbd8 plus fix(agc): release host imports before the device is destroyed #1239).- cea1ef1 creates devices and passes on the same machine.
Only the probe's import was observed failing; whether the dma-buf imports of shared direct memory from 815d274 break a device the same way on this driver was not tested.
Possible fixes
- Do not use dma-buf import on
VK_DRIVER_ID_NVIDIA_PROPRIETARYuntil an import is known to work there (VkPhysicalDeviceDriverProperties), so neither the probe nor 815d274's imports run on it. - Or probe dma-buf import on a separate, short-lived
VkDevice, and turn it off for the real device when the import fails.
Activity
Dextroid17 commentedon Oct 7, 2026
Reproduced first-hand on a different NVIDIA stack — RTX 3080 Ti, driver 615.71.09,
mainat df16c4c. Full git bisect not needed: the probe is the trigger, exactly as described.Baseline (
build/tests/agc_driver_*via ctest, 16 jobs):The first failure carries your diagnostics verbatim:
One difference from your box: the device is created here (
Vulkan device ready device=…), and the poisoning shows up later atvkCreateComputePipelines(-13) rather than atvkAllocateDescriptorSets. Same probe line, same root.Control —
APS5_WRITE_WATCH_IMPORTS=watch, which skips both probes:So the differential is clean: 84 failures → 0 by skipping the probe alone.
Worth noting for the fix choice: in that control
context.dmaBufImportis still true, so 815d274's real imports do run, and the suite is green — which suggests the probe's import is what corrupts the device here, not the shared-memory imports. Since you flagged those as untested on this driver, I am going with your option 1 (do not enable dma-buf import onVK_DRIVER_ID_NVIDIA_PROPRIETARY) rather than option 2, so neither the probe nor the real imports run there.Implemented as #1329 (option 1: dma-buf import off on
VK_DRIVER_ID_NVIDIA_PROPRIETARY, including theRecordertest device). Shout if you are already on a fix and I will drop it rather than cost you a review.Measured and written with AI assistance.
hashaam1217 commentedon Oct 8, 2026
A machine where this does not reproduce, and the reason. Ubuntu 24.04.5, RTX 3060 Laptop, NVIDIA 595.91.07, main at df16c4c: the full suite passes 408/408 with nothing skipped, because the probe never gets as far as an import:
On Ubuntu,
/dev/udmabufisroot:kvmwith mode 0660, and this user is not inkvm. So the failure only shows up for users who can open/dev/udmabuf(throughkvmmembership or a udev rule), presumably the case on both machines above. This result does not tell whether driver 595 is affected.What I could check is the two fixes, each merged onto df16c4c:
dma-buf importsprobe line is goneBoth read the driver ID correctly on the proprietary driver and leave Mesa drivers alone. Whether they fix the failure itself cannot be checked here.
oneandonlydean commentedon Oct 8, 2026
Fixed by #1329 (
051d17dd5): dma-buf import, and with it the probe, is now off on the NVIDIA proprietary driver. If device creation still fails on current main, please comment here with the log and it can be reopened.