Release Type: Official Release
Version: 4.3.0.2507
Platform(s): Linux/Vulkan (any Vulkan platform under VRAM pressure)
Describe the bug
Texture.CreateImage() and buffer creation in the Vulkan backend discard the VkResult of
vkAllocateMemory (visible in the IL as call + pop). When the allocation fails under
DEVICE_LOCAL exhaustion, the bind is skipped but the object is returned as if valid, and
InitializeData records vkCmdCopyBufferToImage into the never-bound image. The copy engine
resolves the destination to VA 0x0 and faults:
NVRM: Xid (PCI:0000:01:00): 31, ... MMU Fault: ENGINE CE0 HUBCLIENT_CE1
faulted @ 0x0_00000000. FAULT_PDE ACCESS_TYPE_VIRT_WRITE
This poisons the copy-engine channel machine-wide: after the fault, unrelated copy-engine
work (including backbuffer readbacks in other runs of the process) intermittently returns
zero-filled data until driver reset. We chased weeks of "random all-black screenshots" before
root-causing this.
To Reproduce
Standalone repro (~150 lines, we can attach the project): allocate device-local textures until
near VRAM exhaustion, then create one more Texture.New2D with initial data. Fires 5/5
within ~120 ms of the trigger call on RTX 4070 Ti / driver 595, with clean negative controls
(same allocation pattern without initial data never faults — allocation failure without a
recorded copy is inert).
Expected behavior
A failed vkAllocateMemory should surface as a catchable exception
(GraphicsException / out-of-memory), never as a recorded copy into an unbound resource.
Additional context
Fix shape: check the VkResult in the allocate/bind path of Texture.CreateImage /
buffer creation and throw. We shipped an app-side guard (create empty → verify the
NativeMemory bind via reflection → upload) and it eliminates the fault 2/2 under forced
exhaustion. Happy to PR the check and/or contribute the standalone repro project.
Release Type: Official Release
Version: 4.3.0.2507
Platform(s): Linux/Vulkan (any Vulkan platform under VRAM pressure)
Describe the bug
Texture.CreateImage()and buffer creation in the Vulkan backend discard theVkResultofvkAllocateMemory(visible in the IL ascall+pop). When the allocation fails underDEVICE_LOCAL exhaustion, the bind is skipped but the object is returned as if valid, and
InitializeDatarecordsvkCmdCopyBufferToImageinto the never-bound image. The copy engineresolves the destination to VA 0x0 and faults:
This poisons the copy-engine channel machine-wide: after the fault, unrelated copy-engine
work (including backbuffer readbacks in other runs of the process) intermittently returns
zero-filled data until driver reset. We chased weeks of "random all-black screenshots" before
root-causing this.
To Reproduce
Standalone repro (~150 lines, we can attach the project): allocate device-local textures until
near VRAM exhaustion, then create one more
Texture.New2Dwith initial data. Fires 5/5within ~120 ms of the trigger call on RTX 4070 Ti / driver 595, with clean negative controls
(same allocation pattern without initial data never faults — allocation failure without a
recorded copy is inert).
Expected behavior
A failed
vkAllocateMemoryshould surface as a catchable exception(
GraphicsException/ out-of-memory), never as a recorded copy into an unbound resource.Additional context
Fix shape: check the
VkResultin the allocate/bind path ofTexture.CreateImage/buffer creation and throw. We shipped an app-side guard (create empty → verify the
NativeMemorybind via reflection → upload) and it eliminates the fault 2/2 under forcedexhaustion. Happy to PR the check and/or contribute the standalone repro project.