I reproduced this on an RX 7800 XT with Mesa/RADV 26.1.6. single_queue,
disabling descriptor buffers, and an unmodified current VKD3D-Proton build do
not change the corruption. The traced mission path uses no reserved-resource
or tile-mapping calls, and the placed resources checked so far do not overlap.

The strongest lead is an invalid-copy pattern on the active terrain cache. The
game creates 164 placed 2048x2048 one-mip BC3 textures. A trace recorded 432
narrow uploads to this pool:

• 118 x 128x1
• 112 x 1x128
• 110 x 64x1
• 92 x 1x64

The offsets are block-aligned, but the one-texel dimension does not reach the
mip edge. VKD3D forwards it to VkBufferImageCopy2, where it violates Vulkan's
4x4 BC3 copy granularity. Strings in landscape.dll such as BakedTerrainCache
and stitchBorders support the interpretation that these are terrain-border
copies. This likely explains the magenta seams, but it does not yet explain the
missing pages or menu corruption.

An initial opt-in normalization test matched zero copies because its matcher
was too strict, so that visual result was inconclusive. A footprint-aware
revision is compiled but has not yet been tested. I am not proposing an app
override at this point.

I have a sanitized handoff bundle with the focused trace, analysis, logs,
hashes and diagnostic patches available. Guidance on whether VKD3D should
tolerate this invalid D3D12 copy pattern would be useful before proceeding
further.

The notes, scripts and sanitized bundle are public here:
https://github.com/silv3rshi3ld/il2-korea-proton-investigation

The terrain root cause is now isolated, and I opened draft PR #3202 with a
focused regression test.

IL-2 uploads terrain pages from 64x64 R32G32B32A32_UINT placed footprints to
BC3 textures. Both physical elements are 16 bytes, so this represents a
256x256 BC3 page. The old buffer-to-image path retained the source-format
dimensions and populated only one sixteenth of each page.

A gated run corrected 522/522 observed page and border copies with zero
rejects. A clean build of the general patch then restored continuous terrain
at 4,813 m, 2,427 m and 742 m. The focused test passes 22/22 assertions, and
the full native copy-test subset completed 6,429,713 checks with zero failures.

The menu aircraft blocks/shimmering and OpenMP/NUMA startup problem are
separate and remain unresolved.

Full investigation notes:
https://github.com/silv3rshi3ld/il2-korea-proton-investigation

Follow-up on the separate menu/cockpit/external/fire-lit blocks and flashing mentioned in the original report and my previous comment: the root cause is now isolated.

The game performs a 32-bit global atomic through an R16_UINT typed UAV. A literal typed-buffer translation cannot legally represent that access. In the affected frame, all 50 compute workgroups reused offsets 0–320 while the frame requested 12,126 light references. Between adjacent affected frames, 69–107 overwritten light IDs changed, explaining both the rectangular tile boundaries and the temporal flashing.

The minimal compatibility fix is to make only IL2Series.exe shader 7cefa1bc80bb4c70 lower this typed-UAV access as an SSBO and select VKD3D-Proton’s existing raw descriptor sibling. It retains the game’s original lighting and depth predicates; the earlier experimental depth-gate bypass is not required.

I validated a clean one-commit candidate (9b6e15be) against unmodified VKD3D-Proton master 84c87c83. Both isolated Proton tools use the same NUMA-capable Wine base and differ only in their four VKD3D DLLs. Steam launch options were empty, with no RenderDoc layer, shader override, or game modification.

Before — unmodified master 84c87c83

The static screenshot understates the severity: the blocks were relatively faint in this captured frame, but flashed repeatedly during normal runtime.

After — allocator-only candidate 9b6e15be

The blocks and broad flashing are absent while real lighting and shadows remain. The fine sandy or film-grain lighting is excluded because it is also present on native Windows.

Ideally the game would use a legal 32-bit UAV for this atomic. In practice, compatibility layers also need to reproduce Windows driver tolerance for shipped software. The proposed compromise is therefore one executable- and shader-hash-scoped quirk, not a broad relaxation.

This is separate from the terrain copy fix in #3202 and the startup/NUMA work in Wine MR !11604. I will follow up with a separate, small VKD3D-Proton PR.

Full evidence and build hashes:
https://github.com/silv3rshi3ld/il2-korea-proton-investigation/blob/main/docs/evidence-u01-upstream-candidate-ab.md