I also use lsfg-vk v2

Settings used on Poe2:

Same hang here, with vkd3d-proton's own fault report attached — it points at a use-after-free of a texture by the game.

System: RX 6800 (RADV NAVI21), Mesa 26.2.4, kernel 7.2.9 (Nobara 44), amd-gpu-firmware 20260916, Proton Experimental experimental-11.0-20261001 (also reproduces on GE-Proton11-6), PoE2 build 25568465 (2026-09-28), DX12 renderer, VKD3D_CONFIG=fault.

Kernel: [gfxhub] page fault ... Process Main thread vkd3d_queue ... client TCP (0x8), PERMISSION_FAULTS: 0x3, RW: 0x0 → ring gfx_0.0.0 timeout → ring reset failed → MODE1 reset, VRAM lost. Every fault so far (8 hangs since 2026-10-02) is a read from the texture cache at an unmapped VA.

vkd3d-proton fault report (VKD3D_CONFIG=fault):

d3d12_device_poll_device_faults: Desc: A GPUVM fault has been detected
d3d12_device_poll_device_faults: Address [0]: [ffff800194185000, ffff800194185fff], type ReadInvalid
vkd3d_address_binding_tracker_check_va: Received fault in address ffff800194185000 @ 2076.378655 s.
  BIND   T: 1175.243995 s  VkDeviceMemory [memoryTypeIndex = 0]   VA [ffff800193e00000, ffff800194360000) size 0x560000
  BIND   T: 1175.244003 s  Cookie 51591  VkImage [2048 x 2048 x 1] [levels = 12] [layers = 1] [fmt = 146 (BC7_SRGB)] [type = 1] [usage = #7]
  UNBIND T: 1395.622268 s  VkImage      (same VA range)
  UNBIND T: 1395.622269 s  VkDeviceMemory
vkd3d_address_binding_tracker_check_va: Fault address is currently unmapped. This is very likely use-after-free.

So: a 2048² BC7 texture (dedicated allocation) was created at T=1175 s, destroyed by the game at T=1395 s, and sampled again ~680 s later at T=2076 s.

Correlation with the game's Client.txt: the texture was created on a hideout reload (which also logged [TEXTURE] Insufficient VRAM), destroyed exactly when a map ("Caldera") was being loaded, and the fault happened ~4 min after returning to the hideout. Looks like the game's texture streaming/budget logic frees textures whose descriptors stay live. The game also logs Set is running on steamdeck: 1 on this desktop PC, and Insufficient VRAM spam with 16 GB VRAM and ~4 GB in use — possibly a mis-sized texture budget making eviction aggressive.

Things that did not help: --descriptors-keep-alive (game flag), --test-disable-transfer-queue + VKD3D_CONFIG=single_queue (made it fault within minutes), SteamDeck=0, firmware/Mesa/kernel updates, the tight-alignment update (20261001 build). DX11 does not get in-game at all; Vulkan renderer never faults but performs badly since patch 0.5.

Full proton log and dmesg excerpt available on request. Happy to test a build with deferred memory release / any quirk you want to try.

Same issue on RX 6700 XT (Navi 22) - noticed full resets since June, reproduced across five Proton builds, three kernels and three Mesa/RADV configurations. amdgpu devcoredumps attached.

System: RX 6700 XT 12 GB (Navi 22, RDNA2 / GC 10.3.2), i5-12400F, Fedora 43 → 44, KDE Plasma Wayland, PoE2 DX12 renderer (Steam 2694490). No OC/undervolt. VRAM hardware ruled out with memtest_vulkan (~9.6 TB written / 14.5 TB checked, 0 errors).

Fingerprint — identical to OP. Most recent occurrence is today, on a fully stock current stack (kernel 7.2.8-200.fc44, stock Mesa 26.2.3, GE-Proton11-7, no workarounds active):

amdgpu 0000:03:00.0: [gfxhub] page fault (src_id:0 ring:24 vmid:4 pasid:549)
amdgpu 0000:03:00.0:  Process Main pid 36445 thread vkd3d_queue pid 36634
amdgpu 0000:03:00.0:   in page starting at address 0x0000800230f7b000 from client 0x1b (UTCL2)
amdgpu 0000:03:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x00401031
amdgpu 0000:03:00.0:          Faulty UTCL2 client ID: TCP (0x8)
amdgpu 0000:03:00.0:          PERMISSION_FAULTS: 0x3
amdgpu 0000:03:00.0:          RW: 0x0

It is always a read by TCP (texture fetch) at an unmapped address in RADV's high BO range. When the ring hangs, Ring gfx_0.0.0 reset failed → MODE1 → VRAM lost (the per-ring gfx reset has never succeeded here; in three of the hangs the first timed-out job was kwin_wayland's high-priority context on gfx_0.1.0/pipe1, which then takes the whole desktop down). Faults cluster 25–70 s after hideout/area transitions — right after texture-streaming churn — and frequency increased sharply with the 0.5.x patches, matching OP's timeline. The game's Client.txt logs Deadlock detected with timeout 15000ms; running graph nodes: Present at the same moment. The [TEXTURE] Insufficient VRAM spam fires on roughly every second area load regardless and does not correlate with the faults.

Ruled out over ~2 weeks of A/B testing (all of these still fault):

• Proton: GE-Proton10-34, 11-3, 11-6, 11-7 (vkd3d-proton c9c6bf2e → af89350c), proton-cachyos-11.0-20260703
• Mesa/RADV: 25.3.6; 26.2.3 as a per-game RADV via VK_DRIVER_FILES (verified loaded via /proc/<pid>/maps and the absence of the "Broken NULL PRT with SMEM detected" workaround print); and now stock Fedora 44 Mesa 26.2.3
• Kernels: 7.0.x, 7.1.13, 7.2.8
• VKD3D_CONFIG=single_queue (verified present in /proc/<pid>/environ): reduced frequency — 7 clean sessions — then faults returned with it still active, so cross-queue sync is ruled out
• RADV_DEBUG=nohiz active in all recent sessions
• amdgpu.noretry=0: faults become silent retry faults and the GPU stalls (~45 fps, sclk pinned at 500 MHz, ~1100 amdgpu irqs/s) — i.e. the game is constantly sampling non-resident pages; a hang still occurred and that devcoredump records no VM fault, with GRBM busy on TA/TCP (waves parked on texture fetches). Same disease, different face.
• RADV_QUEUE_DISABLE=sparse: the game's non-sparse fallback is unusable (huge shader recompile storm, ~40 fps) — the engine hard-depends on sparse/tiled resources (vkQueueBindSparse is present in the exe)

All of this is consistent with OP's VKD3D_CONFIG=fault finding: a streamed (sparse) texture freed by the game and sampled later.

Attached: six amdgpu devcoredumps (2026-09-28 → 2026-10-06), including one classic fault (VA 0x80017ec45000, status 0x601030, TCP, process Main/vkd3d_queue) and the retry-mode hang above (no fault recorded). Happy to run VKD3D_CONFIG=fault with the address-binding tracker or capture a RADV_DEBUG=hang dump if useful.

poe2-rx6700xt-devcoredumps.zip