re9_vkd3d_issue_draft.md

Title: Resident Evil Requiem / RE9 on Adreno 840 + Turnip triggers repeatable GPU page faults and missing mesh surfaces

Hi,

I would like to report a Resident Evil Requiem / RE9 rendering issue on Android running through a Winlator/GameHub style stack.

Environment:

• Game: Resident Evil Requiem / re9.exe
• Translation layer: VKD3D-Proton
• GPU: Adreno 840
• Vulkan driver: Turnip (multiple versions tested)
• Android device model reported by app logs: NX809J
• Android version from device: 16

Observed symptom:

• The game runs and is playable.
• Parts of vehicle body meshes disappear in-scene.
• Wheels, lights, some interior parts, wet road reflections, and many other materials still render.
• Changing in-game mesh quality changes which parts disappear.

This suggests a resource / descriptor / mesh-related path issue rather than a generic texture decode problem.

Most important low-level symptom:

The Android kernel driver reports repeated GPU virtual address faults:

F kgsl-3d0: GPU PAGE FAULT
F kgsl-3d0: context=gfx3d_user ... (read translation fault)
F kgsl-3d0: FAULTING BLOCK: UCHE: Unknown
F kgsl-3d0: <- fault @ ...
F kgsl-3d0: **EMPTY**

**EMPTY** strongly suggests the GPU is reading unmapped / invalid VA.

What I tested

1. Updated to a freshly built latest upstream VKD3D-Proton master build.
2. Tested multiple Turnip driver versions.
3. Tested:
   • VKD3D_CONFIG=single_queue
   • VKD3D_CONFIG=single_queue,no_upload_hvv
4. Built several custom VKD3D-Proton variants with app-specific workarounds for re9.exe.

Issue behavior summary

• Updating VKD3D-Proton changes the fault address pattern, but does not eliminate the fault.
• Changing Turnip driver version also changes the fault address pattern, but does not eliminate the fault.
• single_queue did not resolve the issue.
• no_upload_hvv also did not resolve the issue.
• Adding increasingly conservative app-specific workarounds reduced or changed the fault address set, but did not remove the problem.

This makes it look like a boundary problem between VKD3D resource management and the Vulkan driver's VA mapping behavior on this platform.

Interesting clue

Changing in-game mesh quality changes the location / objects of missing surfaces.
That strongly points to:

• mesh / LOD dependent resource usage
• descriptor/resource binding
• streaming / heap layout / aliasing

more than a fixed broken asset.

Relevant fault address patterns observed

Different VKD3D / Turnip combinations produced different but stable fault clusters, such as:

0x4FBFD55800
0x4FCF302800
0x5037AD3000
0x5047080000
0x5067AD3000
0x5077080000

and with another tested combination:

0x4FBECD5800
0x4FCE882800
0x5036A53000
0x5046600000
0x5066A53000
0x5076600000

and with another patched combination:

0x4FBFFF5800
0x4FCF3EE800
0x5037D73000
0x504716C000
0x507716C000

The fact that the set changes with both driver version and VKD3D changes suggests the fault is sensitive to resource allocation / binding layout.

Custom VKD3D tests already tried

I tested app-specific VKD3D workarounds for re9.exe including combinations of:

• NO_UPLOAD_HVV
• NO_STAGGERED_SUBMIT
• AVOID_IMAGE_BUFFER_ALIASING
• FORCE_INITIAL_TRANSITION
• DEFER_RESOURCE_DESTRUCTION
• RETAIN_PSOS
• FORCE_DEDICATED_IMAGE_ALLOCATION

These changed the fault pattern but did not fully fix it.

Questions / suspected directions

My best guess is that this is related to one or more of:

• descriptor / resource heap path
• image/buffer aliasing
• placed resource behavior
• upload heap visibility / lifetime
• destruction / in-flight resource lifetime
• some RE Engine-specific mesh/material/streaming path

Since RE9 already has other known VKD3D issues on desktop Linux/Proton, it may also be hitting a D3D12 path that becomes more severe on Adreno/Turnip.

If useful, I can provide:

• screenshots showing which vehicle surfaces disappear
• more kernel logs
• exact tested VKD3D builds and workaround combinations