Repository navigation
Sampling a D16 depth surface's memory as a half-width 32-bit texture (PPSA15657): "sampling the depth plane ... is not implemented" #2366
Description
Title: Disney Epic Mickey: Rebrushed (PPSA15657 v01.000.000, retail, UE4).
Build: the mickey/testing stack (see #2255, includes #425 and #2022) on main, Linux, RX 7600 (RADV).
Shortly after the title screen appears, a draw binds a texture whose base address is a D16 depth surface's, with a different format and width:
AGC graphics: sampling the depth plane of depth surface 0x204c5c0000 (240x135, vk format 124) as a 120x135 texture of guest format 36 (vk 122), tile mode 7, dimension 1, levels 0-0, slice 0 is not implemented
(T# 204c5c00 c2400000 0021801d 91b003ac 00000000 00700000 006b0000 00204dc1)
DepthSurface::Sampled only accepts a T# of the plane's own size, at R16 for D16 or R32F (or a matching depth-bits width). Here the texture is 120x135 of a 32-bit format, and the depth surface is 240x135 of D16. Rows are the same size (120 x 4 = 240 x 2 bytes) but the element sizes differ.
The two readings lead to different fixes:
- Memory reuse. Unreal's transient resources alias memory, so the texture may simply be a new resource in memory a depth target used earlier. Then the depth surface at that address is stale, and the texture should read the guest bytes (after any pending depth results reach memory) instead of being matched against the depth plane.
- Deliberate reinterpretation. The shader reads pairs of 16-bit depths as one 32-bit texel. That would need the depth plane's bytes, as stored, exposed through a 32-bit view.
The first frames at the title draw without this; it seems to start with the depth-only draws that #2022 lets through. I'll look at which shader samples it to tell the two apart, and post here.
Investigated and written by Claude (AI assistant) on a contributor's machine.
Activity
testing: a T# over a depth surface's memory in another layout is read…
oneandonlydean commentedon Oct 13, 2026
#425 and #4500 are on main now. Does PPSA15657 still stop at
sampling the depth plane of depth surface ... as a 120x135 textureon plain main?johnmaia commentedon Oct 13, 2026
@oneandonlydean PPSA15657 no longer stops at the 120x135 depth-plane sampling message. It stops earlier now, before the main menu, on the same depth surface:
The throw is
DepthSurface::Storage's refusal from 889e5d4 (a storage view of the depth plane that is not 2D). An older base without that check (main e7c70a2 plus PRs) gets past it and runs the level.Build: main ad653c9 + #3763 #4551 #4603 #4465 #4449 #5030, Linux, RX 7600 (RADV). Not plain
main: without #3763 it stops even earlier, on "mipmapped or DCC 3D color targets are unsupported", and #3763 has merged since.#5003 handles depth-plane storage views with dimension 2. We haven't tried it on this title yet; we'll report here.
AI-assisted: yes (Claude Code)
johnmaia commentedon Oct 13, 2026
Follow-up: with #5003 added to the build above, PPSA15657 gets past the depth storage stop, reaches the menu and plays the level with no throw. So on this title, the remaining depth-plane work for #2366 is #5003.
AI-assisted: yes (Claude Code)
johnmaia commentedon Oct 13, 2026
Update, correcting my last comment: on
main3faa9cb + #5097 #4551 #5030, PPSA15657 boots, reaches the menu and renders the level correctly without #5003. Neither the 120x135 depth-plane sampling stop nor thedimension=2depth storage stop happens there (Linux, RX 7600, RADV). So for this title,mainno longer needs anything for this issue.AI-assisted: yes (Claude Code)
oneandonlydean commentedon Oct 14, 2026
Closing: per your 10-13 run, PPSA15657 gets past both depth stops on main after #425 and #4500. If it comes back on current main, comment here.