Tested with Proton Experimental — vkd3d-proton 3.1.0, build 238f157e1d64f90, a different build than the two in the original report (3dfc6f07d0953b1 and 731c4aae5991b33). The hang still reproduces, same vr -4 cascade, same Xid 109 CTX SWITCH TIMEOUT.

One caveat: the prefix was originally created by proton-cachyos, and Experimental logs Proton: Upgrading prefix from CachyOS-11.0-100 to 11.0-100 / Prefix has an invalid version?! on startup. I doubt that explains a GPU hang, but I'm happy to redo the test with a fresh prefix if you'd like to rule it out.

Driver here is 610.57.04 with the open kernel modules. Attaching the new log.

witcher3.log

Reproduced on effectively identical hardware (RTX 4070, 610.57.04 open modules, GE-Proton11-5),
and I think I have the mechanism. The Xid 109 CTX SWITCH TIMEOUT is a downstream symptom,
not the fault. Running with VKD3D_CONFIG=fault changes the reported error entirely:

NVRM: Xid (PCI:0000:0b:00): 31, name=witcher3.exe, MMU Fault: ENGINE GRAPHICS GPC1
  GPCCLIENT_T1_2 faulted @ 0xe1_4a8bc000. Fault is of type FAULT_PDE ACCESS_TYPE_VIRT_READ

d3d12_device_report_fault: Address [0]: 000000e14a8bc000 (granularity 1), type N/A
vkd3d_address_binding_tracker_check_va: Found no candidate VA entries. Page fault was likely
  caused by accessing never used memory or out of bounds access.

It is a page fault into unmapped memory. The context-switch timeout is just what the driver
reports once the faulted context can no longer be switched out.

The signature

Across runs, the shader PC is always the same region (~0xdf3e761xxx) while the faulting
data address is different every time (0xe14a8bc000, 0xb36f1e7a000, 0xbe2f373e000,
0x741f4fd0000). One specific shader, reading a pointer that is garbage. A race would move the
PC as well; this doesn't. That points at the data being structurally corrupt rather than late.

What it isn't

• Not a missing barrier. VKD3D_CONFIG=breadcrumbs_sync (full barrier + sync after every
  command) still faults. extra_rtas_sync and single_queue also make no difference.
• Not an out-of-bounds descriptor read. I built vkd3d-proton with
  -Denable_descriptor_qa=true and ran VKD3D_CONFIG=instruction_qa_checks: zero
  violations, no RESOURCE_HEAP_OOB, no ROOT_CBV_OOB. (Worth noting neither QA mode is
  compiled into any shipped Proton, so descriptor_qa_checks is silently inert on stock builds.)
• Not driver version or Proton version. proton-cachyos, Proton Experimental and GE-Proton11-5
  all fail identically, as does forcing every RT sub-feature on or off.

What it is

Every load logs ~1750 of these inside a ~175 ms window:

d3d12_command_list_register_rtas_scratch_range: Application bug detected.
  Attempting to use scratch which is currently in flight on GPU. Flushing batch.

The game reuses one scratch buffer across all its BLAS builds. #3191 handled the aliasing, but
the allocation also appears to be too small — the game already under-queries RTAS sizes,
which is why its profile carries RTAS_ALLOW_BLAS_REBUILD_SIZES. Builds overrun their scratch,
corrupt neighbouring memory, and traversal then walks a malformed BVH into unmapped addresses.

Over-reporting the sizes in d3d12_device_GetRaytracingAccelerationStructurePrebuildInfo fixes
it completely:

info->ResultDataMaxSizeInBytes     *= rtas_size_scale;
info->ScratchDataSizeInBytes       *= rtas_size_scale;
info->UpdateScratchDataSizeInBytes *= rtas_size_scale;

• scale 4 — stable for ~1.5 hours with the RT master toggle on, sub-features off.
• scale 8 — stable with all RT features on (shadows, RTAO, RTXGI) at 3440x1440.
• scale 1 (stock) — faults within ~40 s, every time.

Open question

I can't tell from outside whether the shortfall originates in the game's size queries or in
vkGetAccelerationStructureBuildSizesKHR under-reporting on NVIDIA. A blunt multiplier is
obviously not a fix worth upstreaming as-is, but the fact that scaling it works at all should
narrow down where the real gap is.

Debugging note

VKD3D_DEBUG=info does not include warnings in this build — 117 info lines, 155 err lines,
0 warn. The register_rtas_scratch_range warnings above are invisible unless you use
VKD3D_DEBUG=warn. That cost me several hours, and may be why this looked like a bare timeout.

Fwiw, any workaround for this game is probably going to be obsolete next month with the next next gen update anyways (or it will require some new ones :p)

Doesn't mean we shouldn't fix it now

Another data point, different angle.

Hardware: RTX PRO 6000 Blackwell Workstation (GB202), driver 610.57.04 open modules. Got the same Xid 109 CTX SWITCH TIMEOUT on witcher3.exe three times (Aug 25, Sep 1 x2) on GE-Proton11-6, vkd3d-proton 3.1.0. Same signature as the original report: freeze ~40s after RT content, vr -4 cascade, no individual RT sub-feature required.

Built vkd3d-proton at the GE commit (c9c6bf2e9) with the prebuild info sizes scaled by 8 and wrapped it as a custom Proton. The patched d3d12.dll was verifiably loaded into the prefix, but the game now black-screens in DX12 before ever reaching the RT path, on both the patched build and stock GE-Proton11-6. Same black screen on stock GE with RT on or off.

Switched to Valve Proton 11.0-2 (vkd3d-1.1-5517-gc9c6bf2e9 per its version file) and the game runs DX12 with RT master toggle, RTGI and RTAO enabled, 5+ minutes so far with zero Xid events. Same kernel, same driver, same game version. So whatever Valve's build does differently (build flags, config defaults, app profile handling) avoids the scratch overrun that GE's build hits.

Might help narrow down why the same vkd3d-proton version line behaves differently between the two Protons.

I have the same problem, attaching log : launch.log

I tried multiple things, and none worked. RT is broken as far as I can tell.

Tried patching multiple Proton versions.

I also get crashes/hangs with the same errors on an AMD system (9070xt). Hoping that the remastered update fixes it

I can reproduce this on an RTX 5090 as well, and did some additional A/B testing.

System:

• GPU: NVIDIA GeForce RTX 5090
• Driver: 615.71.09, open kernel module
• The Witcher 3 next-gen, DX12, 2560x1440
• Proton-CachyOS 11.0-20260703-slr-x86_64_v3
• Hyprland / Wayland
• DLSS enabled
• Frame Generation disabled

The failure is very consistent: enabling ray tracing and loading the same save eventually produces:

NVRM: Xid (PCI:0000:01:00): 109, pid=, name=witcher3.exe, channel=<...>, errorString CTX SWITCH TIMEOUT

DX12 without RT is stable.

I tested three different vkd3d-proton versions while keeping the Proton build otherwise the same:

1. vkd3d-proton 3.1 (the version shipped with this Proton-CachyOS build)

   • Hangs while loading the save.
   • Xid 109 / CTX SWITCH TIMEOUT.

2. vkd3d-proton 3.0

   • I replaced only the x64 d3d12.dll and d3d12core.dll in a copy of the same Proton-CachyOS build and verified the DLL hashes in the game prefix.
   • This got slightly further: the world rendered and the fade-in started before freezing.
   • Still Xid 109 / CTX SWITCH TIMEOUT.
   • Example:
     Info 0x2c023

3. Current vkd3d-proton master

   • Built locally from commit:
     2a38e799 ("vkd3d: Use correct per-plane byte size for emulated copies.")
   • Verified that the locally built d3d12.dll/d3d12core.dll were actually installed into the Witcher 3 prefix by comparing SHA256 hashes.
   • This includes the recent Witcher 3 RTAS workarounds, including commits 84c87c83 and 4232071c.
   • The game again rendered part of the world during loading, then froze.
   • Kernel:
     NVRM: Xid (PCI:0000:01:00): 109, pid=1461278, name=witcher3.exe, channel 0x0000001a, errorString CTX SWITCH TIMEOUT, Info 0x2c02d

I also tested whether the Wine Wayland path was involved.

Native Wine Wayland:

• PROTON_ENABLE_WAYLAND=1
• HDR works correctly.
• DX12 without RT works.
• RT -> Xid 109.

XWayland:

• No PROTON_ENABLE_WAYLAND.
• Confirmed with hyprctl clients that witcher3.exe had xwayland: 1.
• HDR was not involved in this test.
• RT still hangs while loading and produces the same Xid 109:
  NVRM: Xid (PCI:0000:01:00): 109, pid=1541468, name=witcher3.exe, channel 0x00000015, errorString CTX SWITCH TIMEOUT, Info 0x2c025

So in my case the issue reproduces:

• on RTX 5090 / Blackwell
• with driver 615.71.09
• with both native Wine Wayland and XWayland
• without HDR
• with vkd3d-proton 3.0
• with the Proton-CachyOS vkd3d build
• with current master @ 2a38e799 including the recent Witcher 3 RTAS workarounds

Changing vkd3d-proton versions changes how far the loading process gets before the GPU hangs, but all tested versions ultimately produce Xid 109 / CTX SWITCH TIMEOUT.

I can collect a PROTON_LOG/VKD3D_DEBUG log or any additional diagnostics on the master build if useful.

Also hitting this. RTX 5070 Ti, nvidia-open 615.71.09, Proton-CachyOS,
vkd3d-proton master. Any ray tracing setting hangs the GPU within about
35 seconds — including RT AO on its own with shadows and GI turned off.
extra_rtas_sync and single_queue didn't help. RT off is completely
stable.

Before the usual Xid 109 timeouts, I get an MMU fault reading address
zero. Same thing on three separate runs:

NVRM: Xid (PCI:0000:01:00): 31, name=witcher3.exe,
MMU Fault: ENGINE GRAPHICS GPC5 GPCCLIENT_GCC faulted @ 0x0_00000000.
Fault is of type FAULT_PDE ACCESS_TYPE_VIRT_READ

A breadcrumbs build points at trace_rays as the last command before
the hang. The shaders bound in that dispatch are different each run.

Follow-up: I tried patching vkd3d locally to test the "missing barriers"
theory. On every RTAS build where the destination VA already held the
other kind of acceleration structure (TLAS <-> non-TLAS), I flushed the
RTAS batch and emitted a full ALL_COMMANDS -> ALL_COMMANDS memory barrier
before the build.

It fired 309 times across 8 distinct addresses in one run and made no
difference — same Xid 109, same ~30s survival time.

Possibly useful detail: the game reuses a single VA very aggressively.
One address went TLAS -> non-TLAS and then repeated non-TLAS rebuilds
about ten times within 200ms.

So at least within a command buffer, this doesn't look like it's fixable
with barriers at the reuse points.

I got Aftermath working on this and the dumps point somewhere different from what this issue assumes. Posting in case
it's useful.

Setup: RTX 5070 Ti, driver 615.71.09, vkd3d-proton master (3400291), Proton-CachyOS.
Witcher 3 with RT enabled, hangs within seconds to a minute.

What the dumps say

13 crashes captured. Every one is Error_DMA_PageFault with SM Error, not a
timeout waiting on work. Most resolve to a specific shader and instruction:

Device state:   Error_DMA_PageFault
Shader type:    Ray Tracing
Faulted warp:   ray_tracing_01 @ 0x480 - rahit.10000.spv:296
Fault:          SM Error accessing address 0x000000008656049c

The same any-hit shader and instruction came up in three separate crashes with the
same crash fingerprint (0x866598728251a6c8).

Looking at the dumped SPIR-V for the any-hit shaders, they load a 64-bit address
out of the shader record, add an offset, cast it to PhysicalStorageBuffer and
dereference it:

%138 = OpAccessChain %_ptr_ShaderRecordBufferKHR_v2uint %SBT %uint_1
%139 = OpLoad %v2uint %138
%144 = OpIAddCarry %AddCarry %142 %137
%148 = OpCompositeConstruct %v2uint %145 %147
%149 = OpBitcast %_ptr_PhysicalStorageBuffer_PhysicalPointerUintNonWrite %148
%152 = OpLoad %uint %151 Aligned 4

All 44 any-hit shaders in the dump do this.

Patching the shaders moves the fault

I used VKD3D_SHADER_OVERRIDE to replace every RT shader's raw
PhysicalStorageBuffer loads with OpConstantNull, so the dereference can't
happen. Rendering is wrong, obviously, but the shader faults stop.

The fault then moves into the fixed function path, with a different fingerprint:

Shader hash: N/A
Ray Tracing Internal Function Type: AS Build or Refit
GPU virtual address: 0xfffffff08d543000
Fault Type: Failed to translate the virtual address

Override off -> always a hit shader. Override on -> always the AS build. Looks like
one corruption being read from two places.

AS build fault addresses across runs: 0x0, 0xfffffff08d543000,
0x000000dcfc654000, 0x6d6ee8add0a58802, 0xfffffff867ff3000,
0x00000001da84e000. Several have a plausible low word and a garbage high word.
The ones that are well formed are outside every range vkd3d ever mapped.

Things I checked that came back clean

I added local instrumentation for each of these:

• SBT table addresses at every DispatchRays: all resolve, aligned, in bounds
• raw VA root descriptors: never null
• RTAS build addresses (index, vertex, transform, instance): all resolve
• instance descriptor contents, read host side (1532 and 1814 entries): every
  AccelerationStructure address resolves
• each instance's target checked against vkd3d's own rtas_kind tracking: all
  correctly tracked as non-TLAS, no TLAS/BLAS mixups
• VKD3D_CONFIG=descriptor_qa_checks: zero faults over a 27MB log
• VKD3D_CONFIG=damage_not_zeroed_allocations: fault stayed at 0x0 rather than
  becoming the 0xae/0xff poison, so it isn't reading unzeroed memory

Sync things that made no difference

• a full ALL_COMMANDS -> ALL_COMMANDS barrier at every RTAS VA kind change
  (fired 309 times in one run)
• an ALL_COMMANDS write -> ACCELERATION_STRUCTURE_BUILD read barrier before
  every build, which flush_rtas_barrier doesn't cover since its srcStageMask is
  ACCELERATION_STRUCTURE_BUILD with no shader stage
• promoting every PERFORM_UPDATE to a full rebuild, so no refits at all
• VKD3D_CONFIG=single_queue
• extra_rtas_sync (already on for witcher3.exe)

One detail that might matter: of 485 changing kind events in a run, only 4 were
real TLAS<->BLAS transitions. The other 481 were a handful of already-MUTATED
addresses re-triggering, since that state is sticky.

Where I got stuck

Everything vkd3d hands the driver checks out, and the fault is inside driver built
BVH. I don't know whether this is a vkd3d bug or a driver one yet.

I think I hit this aswell

System

• GPU: RTX 5080
• Driver: nvidia-open 615.71.09
• Distro: CachyOS
• Desktop: KDE Plasma 6.7.5, Wayland
• Kernel: 7.2.5-1-cachyos
• Launcher: Heroic (GOG install, next-gen/DX12)

Enabling the ray tracing master toggle crashes the GPU within a few minutes of play, every time.

• With ray tracing off, hours of stable play, no issues.
• Cyberpunk 2077 with full path tracing enabled runs fine.

dmesg output at crash time

NVRM: Xid (PCI:0000:01:00): 109, pid=6940, name=witcher3.exe, channel 0x0000001a, errorString CTX SWITCH TIMEOUT, Info 0xbc026
NVRM: Xid (PCI:0000:01:00): 109, pid=8570, name=witcher3.exe, channel 0x0000001b, errorString CTX SWITCH TIMEOUT, Info 0xbc028
NVRM: Xid (PCI:0000:01:00): 109, pid=11065, name=witcher3.exe, channel 0x0000001a, errorString CTX SWITCH TIMEOUT, Info 0xbc026
NVRM: Xid (PCI:0000:01:00): 109, pid=12298, name=witcher3.exe, channel 0x00000016, errorString CTX SWITCH TIMEOUT, Info 0xbc01e

What I've tried

• GE-Proton11-7— crashes
• GE-Proton10-34 — crashes
• GE-Proton10-21— crashes
• proton-cachyos-11.0-20260703-slr-x86_64
• PROTON_ENABLE_NVAPI=1 VKD3D_CONFIG=extra_rtas_sync — no change
• Disabling esync/fsync (PROTON_NO_ESYNC=1 PROTON_NO_FSYNC=1) — no change

Heroic game logs at crash (GE-Proton10-34 run)

13683.340:00e8:00ec:info:vkd3d-proton:vkd3d_get_vk_version: vkd3d-proton - applicationVersion: 3.0.0.
13683.340:00e8:00ec:info:vkd3d-proton:vkd3d_instance_init: vkd3d-proton - build: f92d8c6e283d613.
13683.900:00e8:00ec:info:vkd3d-proton:dxgi_vk_swap_chain_init: Creating swapchain (3840 x 2160), BufferCount = 3.
13700.647:00e8:02a8:fixme:vkd3d-proton:d3d12_root_signature_init_global: Ignoring root signature flags 0x80000000.
err:winevulkan:signaller_worker wait timed out with non-empty poll list.
err:winevulkan:signaller_worker wait timed out with non-empty poll list.
err:winevulkan:signaller_worker wait timed out with non-empty poll list.
(repeats continuously until game is force-killed)

Other Heroic game logs at crash
witcher3_error.log

I can collect more logs if needed.

Data point from The Witcher 3 5.0 ("Remastered", released today): same hang; ×8 prebuild sizes plus a larger game-side scratch buffer make it stable here.

Setup: RTX 4090, driver 615.71.09 (open), kernel 7.2.7, GE-Proton11-7 (vkd3d-proton af89350c), DX12, 3440x1440, DLSS + DLSS-G on. Note that 5.0 under Wine hides the RT options entirely, because it detects Wine and forces its RT capability off (details in ValveSoftware/Proton#607). To reach RT I had to bypass that check in a local copy of the exe.

Stock af89350c: hangs 4 out of 4 times, within about a minute of loading into gameplay, with RT only, with RT plus path tracing, with VKD3D_CONFIG=extra_rtas_sync, and with extra_rtas_sync,single_queue. The kernel logs Xid 109 CTX SWITCH TIMEOUT. Every run shows the same pattern:

• about 2600 register_rtas_scratch_range: Application bug detected. Attempting to use scratch which is currently in flight on GPU. Flushing batch., all within about 150 ms on one thread;
• VK_ERROR_DEVICE_LOST about 6 s after that burst.

af89350c + @austin-wojo's patch (ResultDataMaxSizeInBytes, ScratchDataSizeInBytes and UpdateScratchDataSizeInBytes ×8 in d3d12_device_GetRaytracingAccelerationStructurePrebuildInfo, with the multiplier read from an env var): much better but not fully fixed. One session ran 8 minutes with RT and path tracing and zero register_rtas_scratch_range warnings. The next one still hung (Xid 109) after about 40 s of gameplay.

×8 plus a larger scratch buffer on the game side: stable. I also raised the game's BLAS scratch buffer from 32 MiB to 256 MiB, by changing the built-in default of RTConfigMaxShaderScratchSizeMB in my test exe. Result: 20+ minutes of gameplay with RT, path tracing, DLSS and DLSS-G, with no Xid, no DEVICE_LOST and zero register_rtas_scratch_range warnings.

Disclosure: OptiScaler (my DLSS-NR fork) was loaded as dxgi.dll in all these runs, running DLSS Neural Rendering on the game's DLSS output. The stock hang reproduced with it both active and idle (NR never ran before the hang in two of the runs), and other reporters here hit it without OptiScaler, so it does not look involved.

Possibly relevant from static analysis of the 5.0 exe (not proven to be the mechanism):

• The BLAS batch builder carves per-BLAS scratch slices out of one 32 MiB buffer (RTConfigMaxShaderScratchSizeMB). The slice sizes come from the game's cached prebuild sizes, and it flushes when the buffer is full or after 0x401 builds.
• A single BLAS larger than the buffer is still built at offset 0. With ×8 sizes that becomes likely, which would explain why ×8 alone still hung once and ×8 plus a 256 MiB buffer did not.
• Prebuild and build use identical flags. So if the build-time scratch or result footprint on 590+ exceeds the reported prebuild size, slices overlap in flight, which matches the warning burst.

Other 5.0 log noise, which looks benign:

• 13 Conflicting local root signatures ... using NULL local root signature: all on ray-gen and miss exports in state objects with two local root signatures.
• 6 to 27 GetShaderIdentifier: Could not find entry point: from the game's async material hit-group refresh racing its AddToStateObject.

The vkd3d-proton patch I used (env-tunable multiplier, VKD3D_RTAS_SIZE_MULT) is in https://gist.github.com/gabrielmaialva33/33ebb2542f0513d55100b22aa2149ff5

Found the cause of the NVIDIA hang: the Witcher 3 workaround RTAS_ALLOW_BLAS_REBUILD_SIZES
queries BLAS sizes with ALLOW_UPDATE forced on, but on NVIDIA that reports up to ~5x less
build scratch and ~10% less RTAS memory for BLAS that are built without ALLOW_UPDATE.
Those builds then overflow into neighbouring memory. This matches the x4/x8 scaling results above.

Fix and driver measurements: #3332. Tested on 4.04 with an RTX 4070 (615.71.09), stable with
RT on. I haven't tested the 5.0 update yet.

@nanomatters independently arrived at the same fix in nanomatters/vkd3d-proton-salkim@6b803e8,
so proton-cachyos users may get it that way first.

Data point: the patch from ThomasEricB's proton-cachyos fork fixes the hang here, including with path tracing, on The Witcher 3 5.0 ("Remastered").

System

• GPU: RTX 5080, driver 615.71.09 (open kernel modules)
• Kernel: 7.2.8-1-cachyos, KDE Plasma 6.7.5 (Wayland)
• Game: The Witcher 3 5.00 (Steam, build 25575366), DX12, 3440x1440, DLSS + DLSS-G on

What was tested

• Base: GE-Proton11-7, with only the x64 d3d12.dll / d3d12core.dll replaced by a vkd3d-proton build of 9c108b4 (nanomatters/vkd3d-proton-salkim, already includes #3308) + the RTAS patch from https://github.com/ThomasEricB/proton-cachyos/commit/a7b8b365ff (rtas_internal_scratch + rtas_pad_result_size, enabled by the witcher3.exe profile: log shows Detected game witcher3.exe, adding 4 configs). No VKD3D_CONFIG set.
• HideWineExports=Y in the prefix (HKCU\Software\Wine), otherwise 5.0 hides RT/DLSS under Wine (see ValveSoftware/Proton#607).

Results

• Same vkd3d build without the RTAS patch: RT options available, not enabled (hang expected per this issue).
• With the patch: RT, then path tracing, loading a save and playing outdoors: ~18 min session (10 min with path tracing), no Xid in the kernel log, no VK_ERROR_DEVICE_LOST, zero register_rtas_scratch_range warnings, zero internal-scratch fallbacks (Failed to allocate ... internal RTAS scratch).

Side note: with Wine hidden, stock GE-Proton11-7 vkd3d (af89350c) crashes the game at startup (Invalid alignment 256 for buffer resource, then an access violation in witcher3.exe), consistent with #3308 being required.

@Stanni97 nice find, that explains the ×8 results perfectly.

Tested #3332 on 5.0 (build 25575366), RTX 4090, driver 615.71.09: vkd3d-proton master 4d06d745 (already has #3308) + #3332, nothing else. No ×8, no VKD3D_CONFIG, and the game's own scratch buffer back at the stock 32 MiB. The exe only has the Wine check bypassed, so RT is exposed.

About 29 minutes of gameplay: ~17 min with RT, then ~12 min with path tracing, DLSS RR and DLSS-G on. No Xid, no DEVICE_LOST, and zero register_rtas_scratch_range warnings with VKD3D_DEBUG=warn. Before, on stock vkd3d, RT hung within about a minute every time (my comment above).

So #3332 alone fixes it on 5.0 too. I'll point my gist to it and drop the ×8 and scratch-size workarounds. (OptiScaler was loaded like in my earlier runs.)

Thanks @gabrielmaialva33 for testing #3332 on 5.0, and @tybautf for the additional data point.

For anyone landing here: the fix (0894a2d5, follow-up 44cf7c20) is in Proton Experimental
experimental-11.0-20261001 (vkd3d-proton build 44cf7c2042168f3). Tested here on an RTX 4070,
615.71.09, game version [4.04 / 5.0], RT Ultra Settings.

Closing since the fix is merged and available. @hamburg3rz the AMD hang isn't covered by this change. If it persists on 5.0, #3347 (RX 6800 XT) may be related.