First of all it would probably be good to try with latest vkd3d-proton and not with some old build from proton-ge 10. Mesa 26.1.7 is also old and is not what is shipped by Arch currently. Also you could just include the full proton log compressed as .zip instead of letting some AI generate questions.

steam-2054970.zip

I have updated to Mesa 26.2.1 and GE-Proton 11-6, and retested. Here is the Proton log from the crash. The issue persists.

Full environment info:

Mesa 26.2.1
Linux 7.1.9
linux-firmware-amdgpu 20260810-2
RX 6700 XT
GE-Proton 11-6
vkd3d-proton build c9c6bf2e9c18252 (the crash log reports application version 3.1.0; build information is on lines 8052-8053)

One additional piece of relevant information: I experienced this same crash behavior in Monster Hunter Wilds in 2025. MHWilds also uses RE Engine, and is likely on a similar version of the engine to what Dragon's Dogma 2 has just updated to.

Also, my system is running Omarchy rather than stock Arch, so its package versions do not necessarily track the latest Arch packages.

The crash is also rather time-intensive to reproduce, as it seems to only occur after at least an hour of playtime.

Adding this here. Hitting very similar issues. After some random amount of time (usually less than 2 hours) the game will lock up and produce this journal output. Sometimes this will result in the whole desktop locking up sometimes alt-tabbing and force closing the game is enough.

Mesa 26.2.2-2
linux-cachyos 7.2.3-1
linux-firmware-amdgpu 20260810-2
RX 6900xt
KDE Wayland
Happens with both proton-cachyos-11.0-20260703 and the current proton experimental

[Mon Sep 14 15:54:37 2026] amdgpu 0000:03:00.0: [gfxhub] page fault (src_id:0 ring:24 vmid:5 pasid:1198)
[Mon Sep 14 15:54:37 2026] amdgpu 0000:03:00.0:  Process DD2.exe pid 101684 thread vkd3d_queue pid 102057
[Mon Sep 14 15:54:37 2026] amdgpu 0000:03:00.0:   in page starting at address 0x0000800064402000 from client 0x1b (UTCL2)
[Mon Sep 14 15:54:37 2026] amdgpu 0000:03:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x00501430
[Mon Sep 14 15:54:37 2026] amdgpu 0000:03:00.0:          Faulty UTCL2 client ID: SQC (data) (0xa)
[Mon Sep 14 15:54:37 2026] amdgpu 0000:03:00.0:          MORE_FAULTS: 0x0
[Mon Sep 14 15:54:37 2026] amdgpu 0000:03:00.0:          WALKER_ERROR: 0x0
[Mon Sep 14 15:54:37 2026] amdgpu 0000:03:00.0:          PERMISSION_FAULTS: 0x3
[Mon Sep 14 15:54:37 2026] amdgpu 0000:03:00.0:          MAPPING_ERROR: 0x0
[Mon Sep 14 15:54:37 2026] amdgpu 0000:03:00.0:          RW: 0x0
[Mon Sep 14 15:54:39 2026] amdgpu 0000:03:00.0: Dumping IP State
[Mon Sep 14 15:54:39 2026] amdgpu 0000:03:00.0: Dumping IP State Completed
[Mon Sep 14 15:54:39 2026] amdgpu 0000:03:00.0: [drm] AMDGPU device coredump file has been created
[Mon Sep 14 15:54:39 2026] amdgpu 0000:03:00.0: [drm] Check your /sys/class/drm/card1/device/devcoredump/data
[Mon Sep 14 15:54:39 2026] amdgpu 0000:03:00.0: ring gfx_0.0.0 timeout, signaled seq=10095878, emitted seq=10095881
[Mon Sep 14 15:54:39 2026] amdgpu 0000:03:00.0:  Process DD2.exe pid 101684 thread vkd3d_queue pid 102051
[Mon Sep 14 15:54:39 2026] amdgpu 0000:03:00.0: Starting gfx_0.0.0 ring reset
[Mon Sep 14 15:54:39 2026] amdgpu 0000:03:00.0: Ring gfx_0.0.0 reset succeeded
[Mon Sep 14 15:54:39 2026] amdgpu 0000:03:00.0: [drm] device wedged, but no recovery needed

Another RX 6900 XT data point (Mesa 26.2.2, kernel 7.2.5, Proton Experimental 11.0 and GE-Proton11-7, both crash). Longer write-ups with Descriptor QA and breadcrumbs are in ValveSoftware/Proton#7595 (1, 2). Posting here because of one pattern in the fault addresses that might be useful.

All 12 faults I captured are SQC (data), PERMISSION_FAULTS 0x3, MAPPING_ERROR 0, read, and every address is inside 0x8000_0000_0000–0x8000_ffff_ffff, which looks like the 4 GiB window RADV uses for 32-bit addressable BOs:

0x800073733000  0x80007891e000  0x80007e5a3000  0x800096200000
0x8000bf7f3000  0x8000c0400000  0x8000d891e000  0x8000e0400000 (x2)
0x8000e4200000 (x3)

The comment above from the other 6900 XT user (0x800064402000) is in the same window.

In my last crash I had RADV_DEBUG=bo_history running for the whole 42 minute session (23,290 ranges). Inside that window the process only ever used up to 0x8000_09a4_1000, about 154 MiB. The fault (0x8000e0400000) is about 3.5 GiB in, and nothing was ever allocated anywhere between 0x8000_8000_0000 and 0x8001_0000_0000. So I don't think this is a use-after-free. It looks more like a shader doing a scalar load through a 32-bit pointer whose low 32 bits are garbage. The exact same bad values show up again on different days (e4200000 three times, e0400000 twice), so I doubt it's random memory corruption or unstable hardware.

The two unsynced breadcrumb regions I got both fall inside runs of ExecuteIndirect (one had 9 EIs all using the same argument buffer cookie), with no printed shader hash in common. I know unsynced breadcrumbs only give a range. breadcrumbs_sync and syncshaders make it unplayable and haven't reproduced the fault so far.

Things that did not help: single_queue, no_upload_hvv, disabling VK_EXT_device_generated_commands, FSR off, a fresh boot, and a targeted DESCRIPTOR_HEAP_ROBUSTNESS quirk on the shader Descriptor QA flagged (6cb9f216457421cf, HEAP_OUT_OF_RANGE).

Next I'm going to try other RADV versions (mesa-git and a 25.x release) on stock Experimental to see whether this is driver-side. If there's a specific capture that would be more useful than that (a Fossilize dump, particular VKD3D/RADV debug options, or a build with extra instrumentation), tell me and I'll run it. I have full Proton logs, BO history and an amdgpu devcoredump from these crashes and can attach them.

Edit: after posting I noticed the Monster Hunter Wilds entries in device_workarounds.c. MHWilds gets SKIP_NULL_SPARSE_TILES (only active when RADV < 26.2 since 497357c0) plus global heap_robustness_quirks, because a bogus bindless index was being loaded from a sparse page that should have been NULL. DD2 only gets re_engine_quirks. Two things make me think DD2 may be on the same path since the 3.2 update, which reportedly moved it to a newer engine version (the RX 6700 XT reporter above also saw this in MHWilds):

• DD2 creates a lot of sparse memory. The last session's BO history has 6,362 is_virtual=1 records.
• The Descriptor QA hit I got was HEAP_OUT_OF_RANGE with Failed heap index: 1038174126, which is a garbage index, similar to what the MHWilds comment describes.

My single-hash robustness quirk didn't prevent the fault, but that isn't the same as the global MHWilds treatment. Would it make sense to test DD2 with the MHWilds quirk set (global heap robustness, and null sparse tiles skipped regardless of Mesa version)? I can build and soak-test that.

Follow-up to my comment above: global descriptor heap robustness on DD2.exe fixes the fault for me.

I built vkd3d-proton master 7f0c30ad with DD2.exe moved from re_engine_quirks to a profile that keeps the two RE Engine culling entries and sets VKD3D_SHADER_QUIRK_DESCRIPTOR_HEAP_ROBUSTNESS as the default for every shader, which is the same heap treatment MonsterHunterWilds.exe gets. I did not add SKIP_NULL_SPARSE_TILES, since with RADV 26.2 it wouldn't be active anyway (497357c0). Everything else stayed the same: Proton Experimental experimental-11.0-20260917b with only d3d12/d3d12core swapped, Mesa 26.2.2, RX 6900 XT, kernel 7.2.5.

Results:

• Before the change: about 12 SQC (data) GPUVM faults across GE-Proton11-7 and Experimental, roughly one per 40 minutes (anywhere from 26 s to 3+ h).
• With the change: about 7h15 of play over 4 days and 7 launches (I finished the game), with no GPUVM fault, no ring timeout, no DEVICE_LOST and no noticeable FPS cost.

With that baseline, going 7 h without a fault by chance would be very unlikely (well under 1% even if the real fault rate were half what I measured). This shows the robustness quirk avoids the fault. It doesn't prove where the garbage index comes from, but it fits the MHWilds explanation.

The change (minus a local log line I used to confirm it was active):

+static const struct vkd3d_shader_quirk_hash dd2_hashes[] = {
+    {
+        "PersistentClusterCulling", 0,
+        VKD3D_SHADER_QUIRK_CLAMP_WAVE_SIZE_TO_THREAD_GROUP32 | VKD3D_SHADER_QUIRK_ENABLE_FAIR_SCHEDULING |
+        VKD3D_SHADER_QUIRK_DESCRIPTOR_HEAP_ROBUSTNESS
+    },
+    {
+        "PersistentShadowClusterCulling", 0,
+        VKD3D_SHADER_QUIRK_CLAMP_WAVE_SIZE_TO_THREAD_GROUP32 | VKD3D_SHADER_QUIRK_ENABLE_FAIR_SCHEDULING |
+        VKD3D_SHADER_QUIRK_DESCRIPTOR_HEAP_ROBUSTNESS
+    },
+};
+
+static const struct vkd3d_shader_quirk_info dd2_quirks = {
+    dd2_hashes, ARRAY_SIZE(dd2_hashes), VKD3D_SHADER_QUIRK_DESCRIPTOR_HEAP_ROBUSTNESS,
+};
...
     /* Dragon's Dogma 2 (2054970) */
-    { VKD3D_STRING_COMPARE_EXACT, "DD2.exe", &re_engine_quirks },
+    { VKD3D_STRING_COMPARE_EXACT, "DD2.exe", &dd2_quirks },

If you'd prefer something narrower than global robustness, or want me to test a specific build or variant, I can run it with the same multi-hour criterion.

linking my comment from the main proton issue here too; to summarise this fix doesn't seem to be working for my system
https://github.com/ValveSoftware/Proton/issues/7595#issuecomment-6106881054