v_interp_mov P10/P20 of a FLAT_SHADE input without pass-through: deltas or raw vertices?

The recompiler reads v_interp_mov_f32 P10/P20 of an input with FLAT_SHADE set and OFFSET bit 5 clear as P1−P0 / P2−P0, the same as an interpolated input. Only pass-through inputs (FLAT_SHADE + OFFSET bit 5, e.g. 0x422/0x423) return raw vertices 1 and 2. This is the model from 6a33a3d, and agc_shader_memory (verifyPixelParameterSlots) and agc_driver_graphics assert it ("v_interp_mov p10/p20 of a flat input did not read differences to vertex 0").

A console-tested driver relies on the other behaviour. I'd like someone with PS5 or RDNA2 hardware access to confirm which one is right before anything changes.

Evidence for raw vertices

ps5-opengl (Mesa 26.2 on AGC, blackbearreloaded/ps5-opengl) passes provoking_vtx_last to ACO. Its shaders read plain flat inputs with explicit vertex loads. In Homebrew UI Lab (PPSA99050), the batched UI pixel shader has SPI_PS_INPUT_CNTL = 0x402–0x407 for its six flat GLSL inputs (shape half-size, colours, border, mode word) and reads them with v_interp_mov_f32 VSRC 0, i.e. P10. For example c8220f00 is v_interp_mov_f32 v8, p10, attr3.w.
In Mesa 26.2, ACO emits P10/P20 only for nir_intrinsic_load_input_vertex (aco_select_nir_intrinsics.cpp visit_load_fs_input, then aco_isel_helpers.cpp emit_interp_mov_instr: Operand::c32((vertex_id + 2) % 3)), and that is a raw-vertex read.
UI Lab is published as working on PS5. With the delta model every such read is v1 − v0, which is 0 for the per-instance constants the shader passes. Every UI shape gets alpha 0 and is discarded, so the screen shows only the backdrop. Reading raw vertices for these inputs makes the whole UI render (screenshot below).

Evidence for deltas

RADV (radv_cmd_buffer.c, offset_to_ps_input) programs explicit per-vertex inputs as FLAT_SHADE + OFFSET(1 << 5) ("Force parameter cache to be read in passthrough mode"). Plain flat inputs get FLAT_SHADE only, and ACO reads those through P0. Upstream Mesa therefore never reads P10/P20 of a non-pass-through flat input, and the current model matches everything RADV does.
The ISA documentation I could find does not say what P10/P20 hold for a flat input without pass-through.

What would settle it

A pixel shader with an input at SPI_PS_INPUT_CNTL = 0x402, three vertices exporting different values for that parameter, and v_interp_mov_f32 P10 and P20 reads, on gfx1013 or another gfx103x GPU. The hardware oracle runs compute only, so it can't reach the parameter cache. I don't have AMD hardware with a pixel pipeline I can drive this way.

Change ready if raw is right

The branch TheAggie/AnyPS5 fix/recompiler-flat-interp-mov skips the subtraction for flat inputs in EmitInterpolationParameterValue and adds agc_driver_pixel_flat_interp_mov. It does not yet update the two tests above; I'll do that, and record the behaviour in TechnicalDebt as unverified on hardware, only if this is confirmed.

Investigated with AI assistance.

🤖 Generated with Claude Code

Video of Homebrew UI Lab (PPSA99050) with flat inputs read as raw vertices: https://youtu.be/qNOqICDvd2c (same recording on Google Drive: https://drive.google.com/file/d/1EgaJG41cgFFPWb2iNGLhvM46YbZgWdSs/view?usp=sharing)

The full UI renders and navigates, including page switching with L1/R1. Recorded on Windows 11 with an RTX 5070 Ti, on a local branch that also carries #1412, #1196 and several other pending rendering fixes, so it shows what the change enables. It does not show this change in isolation. Without the raw-vertex read, the same build draws only the blurred backdrop.

The screenshots the issue mentions. Before: delta model, only the backdrop renders because every UI shape is discarded. After: flat inputs read as raw vertices, the full UI renders.

investigated with AI, SKIPPPPPPPPPPPPPPPPPPPPPPP.

This is an important question about shader interpolation behavior. Based on my review of recent PRs related to the shader recompiler (including #1524 for VOP3 F32 interpolation instructions and #1526 for BY2/BY4 image transfers), I can provide some context:

The evidence presented for raw vertices (from ps5-opengl/Mesa) is compelling, especially the fact that UI Lab works on PS5 with this behavior. The fact that RADV never reads P10/P20 of a non-pass-through flat input explains why the current delta model has worked so far - it's been tested against code that doesn't exercise this path.

The proposed change to skip subtraction for flat inputs in EmitInterpolationParameterValue seems reasonable if raw vertices is confirmed as correct. The fact that there's already a branch ready with tests suggests this issue has been well-investigated.

I'd suggest prioritizing getting hardware confirmation on this, as it could affect multiple titles that use flat shading with explicit vertex loads (like UI rendering).

Measured on RDNA2 (gfx1036, Radeon 610M). The compute oracle can't set SPI_PS_INPUT_CNTL, so I built Mesa 26.2.4 RADV with a small patch that rewrites the SPI_PS_INPUT_CNTL value RADV programs for an explicit per-vertex input (the shader binary is unchanged; ACO reads it with v_interp_mov_f32 P0, P10 and P20). One triangle, the input's three vertices hold 1000, 1200 and 1030:

`SPI_PS_INPUT_CNTL`	Provoking vertex	P0	P10	P20
0x401 (FLAT_SHADE, no pass-through)	first	1000	0	0
0x401	last	1030	0	0
0xc01 (FLAT_SHADE + ROTATE_PC_PTR)	first or last	1000	200	30
0xc21 (pass-through)	first or last	1000	1200	1030
0x001 (interpolated)	first or last	1000	200	30

So on gfx1036 a flat input without pass-through gives neither deltas nor raw vertices: P0 is the provoking vertex and P10/P20 read 0. The same pattern holds with -7.5 / 3.25 / 640, with attr2.w and four inputs, and after 64 earlier pass-through draws with other data in the same command buffer, so it isn't stale LDS. This was reproduced independently on the same GPU. gfx1013 is not measured, and this doesn't explain why UI Lab renders on a PS5.

I have a recompiler change with these rows as a draw test (P10/P20 of (cntl & 0xc20) == 0x400 inputs read 0, everything else unchanged) and will open it once it's reviewed.

Data from PS5 hardware on the part that is still open, i.e. why UI Lab renders on a PS5. ps5-opengl reads every flat input through v_interp_mov_f32 P10, and that driver passes the Khronos GL 4.6 CTS on a PS5.

The reads. At ps5-opengl 3b8c0ca0, the PSBC compiler rewrites every non-interpolated fragment input into load_input_vertex(vertex_id) in every PS5 fragment shader. That covers every flat varying, including all integer varyings: nir_intrinsic_load_input in lower_flat_input_vertex, toolchain/opengnm-psbc-ps5.patch:938-960, applied at :3540-3542. vertex_id is 1 unless GL's flatshade_first is set. With it set, the value is 2 for triangles, 1 for lines and 0 for points (ps5_last_provoking_vertex). ACO emits load_input_vertex(1) as v_interp_mov_f32 ..., p10. AnyPS5 sees the same: the showcase (PPSA99005) reads its flat inputs with VSRC 0, and their SPI_PS_INPUT_CNTL has FLAT_SHADE without OFFSET bit 5, like UI Lab's 0x402-0x407.

The hardware result. With that driver, the complete cts-runner --type=gl46 run of opengl-cts-4.6.8.1 on one PS5 gives 98,590 Pass, 24,205 NotSupported, 4 warnings and 0 failures (validation/2026-10-01-gl46-conformance, whose run.json records source commit 3b8c0ca0). GLSL requires flat on every integer varying, so many of these cases see their flat inputs only through P10. If P10 of a FLAT_SHADE input without pass-through read 0 on the PS5, as it does on gfx1036 above, those cases could not pass. So gfx1013 differs from gfx1036 here, and both the delta model and a "P10/P20 read 0" model would break the ps5-opengl titles.

Which vertex each lane holds is less settled. The lane table above was tuned on hardware on 2026-09-18:

796ac5c1 "Probe indexed flat-shading lanes" logs the lanes for six probes.
c22f03b3 "Map PS5 flat-input lanes explicitly" sets the table.
The hardware gate at 0f127f0 reports first- and last-provoking-vertex flat shading passing (docs/gl46-development-validation.md).

However, at 0f127f0 the driver set PA_SU_SC_MODE_CNTL bit 19 (PROVOKING_VTX_LAST) when flatshade_first was set. At 3b8c0ca0 it sets the bit when flatshade_first is clear. The lane choice is the same in both. So either these lanes don't depend on PROVOKING_VTX_LAST for such inputs, or one of the two runs had no case with different flat values per vertex. The raw output of the 796ac5c1 probe would settle that. @blackbearreloaded, do you still have it?

Until then, the case these titles use is: P10 of a FLAT_SHADE input without pass-through, with PROVOKING_VTX_LAST set. For that case the evidence supports "P10 holds vertex data" and does not support 0. I can prepare a recompiler change that returns the provoking vertex's value there and keeps throwing for every other lane and mode, if that direction is acceptable.

AI-assisted: yes (Claude Code).

Follow-up with a result: I implemented the narrow case from my comment above, and on Windows both Homebrew UI Lab (PPSA99050) and VITA5 (PPSA39410) now draw their complete UI. UI Lab shows its full home screen (text, game cards, buttons, blurred backdrop); VITA5 shows its "Dock your PS Vita" screen. Before the change both stopped at last provoking vertex with explicit per-vertex flat interpolation is unsupported. With the change they run for 30 s without an error. This was on my Windows test branch, which is main plus the titles' import PRs and my other fixes.

Change: AlxcBTW/AnyPS5#12 (c18298c3, on main 034dd75).

A FLAT_SHADE input without pass-through that is read through v_interp_mov_f32 P10 and not P20 returns the provoking vertex's value, like P0. A P20 read still keeps the input per vertex, so the existing P0/P10/P20 delta tests are unchanged.
FragmentParameter::flatP10 records the lane. With the first provoking vertex, such a shader throws v_interp_mov p10 of a flat input with the first provoking vertex is not measured, because only the last-vertex case has evidence.
The TechnicalDebt entry for PROVOKING_VTX_LAST notes the assumption and links here.
In full CI, Linux and macOS pass. The only Windows failure is agc_driver_prepared_shaders_deferred_undecodable, which currently fails on every main run (CI: windows job fails on main since e5b32bb4 (agc_driver_prepared_shaders_deferred_undecodable doesn't skip without Vulkan) #2606).

The PS5 showcase (PPSA99005) gets past this check too. It then ends when its own 2 s retirement wait for the next submission expires, which I haven't analysed yet.

AI-assisted: yes (Claude Code).

Quake II v0.2.0-alpha.1 is another native Windows reproduction, but its captured shader reads P20, so AlxcBTW#12 does not cover this case.

Windows 11, RX 5600 XT, WinLibs GCC 15.2 r7, main a11c8f7 plus #3886 and #3783. The stop repeats with #3777 and #3840 included; the seven focused integration tests pass. The game executable and assets were unchanged.

[videoout] presentation failed: AGC graphics: last provoking vertex with explicit per-vertex flat interpolation is unsupported

The cached 2178-word wave32 fragment shader has input controls [0, 1, 2, 0x403]. Instruction c8520c01 at dword offset 60 is v_interp_mov_f32 v20, p20, attr3.x. Parameter 3 is flat, perVertex, non-custom. Exit is 0xc0000409.

Quake II's release and current dependencies.json pin ps5-opengl 32ca4d4e16c0f29d75b4ae82b74c2df6e1e067bf. At that revision, the compiler patch selects vertex_id 2 for triangle flat loads, while the rasterizer sets bit 19 when flatshade_first is false. That matches the older P20/last-provoking case in our capture, before the September 18 lane mapping change.

Does anyone have console output for plain FLAT_SHADE P20 with bit 19 set and distinct vertex values, or the original indexed flat-probe output together with its exact compiler/raster state? Compiler intent and a host emulation screenshot do not settle the console value, so I have kept the guard and have not submitted a guessed P20 implementation.

AI-assisted: yes (Codex).

@PrintOrb

@PrintOrb right, #12 covers only P10 on purpose: that's the case where ps5-opengl's current lowering gives PS5-side evidence. I have no console output for P20 either. We have no PS5 homebrew here, so I can't produce it.

There is one place the same kind of evidence could come from for P20. #12's argument is that ps5-opengl reads every flat input through P10 and passes the GL 4.6 CTS flat-shading cases on a PS5. If ps5-opengl at 32ca4d4e, the vertex_id 2 / bit 19 revision Quake II pins, also has a recorded CTS run on hardware covering flat with last-vertex provoking, that run is console evidence for P20 under bit 19 in exactly the state Quake II uses. Its CTS results or CI logs at that revision would be worth checking before anyone writes a P20 path. Keeping the guard until then is the right call.

AI-assisted: yes (Claude Code)

@PrintOrb

Quake II (PPSA99007, catalog v0.2.0-alpha.1) gets into a map with the P20 case handled the way #4030 handles P10.

Setup: Windows 11, MinGW-w64 GCC 15.2.0, NVIDIA GeForce MX450 (Vulkan), main d146ec1 plus two local changes: 119.88 Hz output accepted (what #3886 does properly), and a FLAT_SHADE input without pass-through read through P10/P20 returning vertex 1/2 instead of the difference to vertex 0, with the ValidateProvokingVertex flat throw removed. The shader is the one @PrintOrb captured: input 3 at 0x403, read only through v_interp_mov_f32 P20 and used as an integer bit field. Under the last provoking vertex on a triangle list, vertex 2 is the provoking vertex, so for this shader the change returns the provoking vertex's value, the same rule as #4030 for P10. Strips were left throwing.

Result: the menu, then "New game" → demo1 (Outer Base). The game ran for 1140+ frames at about 30 FPS (33 ms per frame at the default 3840x2160, most of it in swap_us), with no AnyPS5 error. I didn't check the image against a console; the level looked lit as expected, but a wrong vertex choice would be hard to see when a surface's vertices share the same flags.

On the "submission retirement" stop mentioned in #3886: here it happened only with an empty shader cache. ps5-opengl's runtime_require_retirement gives a batch at most 2000 waits of sceKernelUsleep(1000) (ps5_agc_native_runtime.c), roughly 2 to 4 s. The first frame of demo1 compiles its pipelines inside that window and exceeded it. Run again with the cache from the failed run (27 entries, 130 KiB of Vulkan pipelines), the same map loaded and ran. Any title with a short GPU completion timeout could hit this on a cold cache.

This doesn't answer the hardware question here; CouchRiv's gfx1036 table still says P20 reads 0. It only shows that Quake II needs P20 to return the provoking vertex's value to get in game, as the UI titles need for P10.

AI-assisted: yes (Claude Code)

fix(recompiler): read P10 of a flat input as the provoking vertex

Upstream sync 6: shader recompiler to upstream/main (slice B) (#448)

@PrintOrb

Yamagi Quake II (PPSA99007, catalog 0.2.0-alpha.1) stops here on plain main 31bfc4e, now that #3886 is in. Windows 11, RTX 4080, WinLibs GCC 15.2.0 Release, --trap-sdk-syscall-stubs, original eboot.bin in app0. The main menu runs at 120 FPS. Controller pulses through APS5_PAD_INPUT_FILE open Game and pick the first entry, and the run ends 48 s in (exit 0xC0000409) with:

[videoout] presentation failed: AGC graphics: last provoking vertex with explicit per-vertex flat interpolation is unsupported

That is the same refusal as in @PrintOrb's capture above, so it is the title's first stop on main.

AI-assisted: yes (Claude Code Opus 5.5)

data: Yamagi Quake II reaches Menus on main; #4399 never stopped it (#80

Another title stops on the first-mode half of this: Sahin PPSA99404 (catalog 01.002.000, added today). macOS 26, Apple M2, MoltenVK, main 35fa2bd plus the macOS port series. About 8 s in, after its store UI starts ([STORE] inventory complete), it aborts with AGC graphics: v_interp_mov p10 of a flat input with the first provoking vertex is not measured from ValidateProvokingVertex in Pipeline.cpp, so a pixel shader with a flat P10 input is drawn with PA_SU_SC_MODE_CNTL.PROVOKING_VTX_LAST clear.

No measurement from me: this machine has no console either, and I have not changed the throw. It is one more title for whoever can read P10/P20 of a flat input in first mode on a PS5.

AI-assisted: yes

Another title on the P20 side of this: SuperTuxKart (PPSA69421), first provoking vertex. Its deferred point lights read all their flat inputs through v_interp_mov_f32 P20, which is ps5-opengl's flatshade_first lowering: lower_flat_input_vertex takes ps5_last_provoking_vertex(), vertex 2 for triangles. main returned vertex 2 minus vertex 0, which is 0. The light's attenuation became NaN and blacked out the scene around the starting-line referee (#8364).

#8538 reads a P20-only read of a flat input as the provoking vertex, mirroring #4030, and throws for P20 under the last provoking vertex, which isn't measured. Still no console measurement from me; the evidence is ps5-opengl's lowering, the same as for #4030, plus SuperTuxKart rendering correctly with the change.

A title that reads P20 under the last provoking vertex: Yamagi Quake II (PPSA99007 0.2.0-alpha.1, built against ps5-opengl pinned at 32ca4d4e16c0 per its THIRD_PARTY_NOTICES.md). Taken alone it doesn't settle this question, but it is a reproducible case.

What happens. Radeon 860M, Windows 11, main aa1b1bf. The menu runs. Pressing cross three times (Game, skill) loads base1 from the bundled demo pak, and the first gameplay draw stops with:

on main: last provoking vertex with explicit per-vertex flat interpolation is unsupported
with fix(recompiler): read P20 of a flat input as the provoking vertex #8538, which tells P10 and P20 reads apart: v_interp_mov p20 of a flat input with the last provoking vertex is not measured

So it is a P20-only read of a flat input with PROVOKING_VTX_LAST set.

Which input. Yamagi's GL3 shaders have one flat input, flat in uint passLightFlags, in the world and lightmap shaders (gl3_shaders.c). The bundled GL driver's log (download0/pss-opengl.log) shows the gameplay fragment variants compiled with primitive=4/5 provoking-last=1.

Why it is lane 2 here and lane 1 elsewhere. In ps5-opengl 1.0.2 (src/gallium/ps5/ps5_screen.c), the hardware bit is PROVOKING_VTX_LAST = !flatshade_first. The shader option named provoking_vtx_last is set from flatshade_first, and lower_flat_input_vertex notes that "the Gallium flag carries GL's flatshade_first state despite its legacy name". With that version:

an app on GL's default convention gets lane 1 (P10) under the last vertex (fix(recompiler): read P10 of a flat input as the provoking vertex #4030's case);
a flatshade_first app gets lane 2 (P20) under the first vertex (SuperTuxKart, fix(recompiler): read P20 of a flat input as the provoking vertex #8538).

Quake II never calls glProvokingVertex, yet its build compiles lane 2 under the last vertex. That fits an older lowering in which the flag still meant "last". I can't check that against the pinned commit, because the blackbearreloaded repository isn't reachable from here.

What it does and doesn't tell us. passLightFlags is per surface: every vertex of a primitive carries the same value. On a console, any lane gives this title the right result. So this case shows that P20 under the last vertex occurs in shipped homebrew. It says nothing about which vertex the hardware returns there, and that is still the open part of this issue. Until someone measures it, the throw stays the honest answer.

To reproduce, run the title with APS5_PAD_INPUT_FILE set. After the menu appears (about 45 s on a cold cache), send tools/pad_input.py <file> cross --hold-ms 300 three times, 2 s apart. The stop comes about 10 s later.

AI-assisted: yes (Claude Code)

The evidence now points to this depending on the exact control bits and provoking mode rather than a single rule for every FLAT_SHADE input: gfx1036 reports P0=provoking value and P10/P20=0 for 0x401, but P10/P20 are deltas for 0xc01 and raw vertex values for pass-through 0xc21; PS5 reports from ps5-opengl and title runs show additional non-pass-through P10/P20 cases. The open P20/last-provoking case remains unresolved, and I agree the guard should stay until it is measured. A useful next probe would record the full SPI_PS_INPUT_CNTL, PROVOKING_VTX_LAST, primitive type, and lane outputs for P10 and P20 on gfx1013/PS5, then map each supported combination separately. I also noticed #8538 implements P20 with first-provoking mode and intentionally throws on last-provoking mode; that appears to be a narrower, test-backed improvement while this issue’s remaining hardware case stays open.

@CouchRiv

Measured on RDNA1 (gfx1010, AMD Radeon RX 5700 XT), the PS5's gfx10.1 family, on Windows 11 with AMD's driver (26.8.1, Vulkan driver 2.0.353). It gives the same table as @CouchRiv's gfx1036 run: a FLAT_SHADE input without pass-through reads the provoking vertex through P0 and 0 through P10 and P20.

Method. The compute oracle can't reach the parameter cache, and RADV doesn't run on Windows, so I used VK_KHR_pipeline_binary. A pipeline with one triangle and a pixel shader that reads one input with InterpolateAtVertexAMD (VK_AMD_shader_explicit_vertex_parameter) compiles to v_interp_mov_f32 P0, P10 and P20 of attr0.x, which VK_AMD_shader_info disassembles. The driver captures it as an ELF whose PAL metadata note describes SPI_PS_INPUT_CNTL_n as fields (.offset, .flat_shade, .default_val). I edited those fields in place, recreated the pipeline from the edited binary, drew, and read the target back. The pixel code is unchanged; only the input control changes. The driver accepts the edited binary, and each edit changes the result as shown below. The provoking vertex comes from the pipeline's VK_EXT_provoking_vertex state, not from the binary.

The input's three vertices hold 1000, 1200 and 1030. The table shows P0, P10 and P20 in every pixel of an 8×8 target:

`SPI_PS_INPUT_CNTL`	Provoking vertex	P0	P10	P20
0x400 / 0x401 (`FLAT_SHADE`, no pass-through)	first	1000	0	0
0x400 / 0x401	last	1030	0	0
0x420 / 0x421 (pass-through)	first or last	1000	1200	1030
0x000 / 0x001 (interpolated)	first or last	1000	200	30
0x020 (offset bit 5 without `FLAT_SHADE`)	first or last	0	0	0

The same pattern holds with the values -7.5, 3.25 and 640, and for parameter 1 as well as parameter 0 (0x401 vs 0x400), with a second flat input read through P0 in the same shader.
DEFAULT_VAL 1, 2 and 3 don't change the 0 that P10 and P20 return for 0x401.
The pixel shader runs as wave64. I also set the PS stage's .wavefront_size to 32 in the metadata, and the results were the same. I couldn't confirm that the driver ran it as wave32, so I'm leaving that row out.
PAL's metadata has no ROTATE_PC_PTR field, so I couldn't reproduce the 0xc01 row.

So gfx10.1 and gfx10.3 agree. Two generations, measured through two different drivers (RADV on gfx1036, PAL on gfx1010), read 0 through P10 and P20 for a non-pass-through flat input. A difference between RDNA1 and RDNA2 can't explain why ps5-opengl's P10 reads work on a PS5. The remaining candidates are state the console driver programs and these drivers don't (SPI_INTERP_CONTROL_0, which PAL's metadata only exposes for point sprites, is one), or gfx1013 itself. I'd keep the guard until one of those is measured. I can rerun this with other register fields, if PAL's metadata exposes them.

The probe (probe.cpp, the PAL metadata reader and the matrix script) is in this gist. It runs on any AMD GPU whose Windows driver exposes VK_KHR_pipeline_binary.

AI-assisted: yes (Claude Code). I ran the probe on my machine.

@SirDarky

A scope note on @SirDarky's probe, for anyone with RDNA 3 or later: it builds and runs there, but it doesn't measure v_interp_mov_f32. gfx11 has no such instruction. On a Radeon 860M (gfx1152, AMD Windows driver 32.0.13058.8001), explicit.frag compiles to this:

lds_param_load v0, attr0.x wait_vdst:15
v_mov_b32_dpp v0, v0 quad_perm:[2,2,2,2] ...
v_mov_b32_dpp v1, v1 quad_perm:[0,0,0,0] ...
v_mov_b32_dpp v2, v2 quad_perm:[1,1,1,1] ...

The three vertices come from the LDS parameter load's quad lanes, not from the parameter cache path that P0/P10/P20 take on gfx10. Edited SPI_PS_INPUT_CNTL results from RDNA 3/3.5 (780M, 860M, RX 7000) therefore wouldn't say anything about gfx1013, so I'm not posting a table from this GPU. RDNA 1 and 2 hosts are the useful ones for this question.

Another title stops here: Blur5 (PPSA11016 1.0.0, added to the homebrew catalog today), at 15 s on AGC graphics: v_interp_mov p10 of a flat input with the first provoking vertex is not measured, the same throw as Sahin (PPSA99404). Run on an Apple M2 (macOS 26, MoltenVK, Rosetta) on current main, without the user's Blur PC files, so it stops before any game data is read; the shader is from the port's own front end.

Two more titles stop on the first-mode half of this: PS5NES (PPSA99204, v1.0.0.9) and PS5N64 (PPSA99206, v7), both by YAHBALLON on the same frontend. Both run fine with an empty library; as soon as a ROM is in their roms folder, the library view's next pipeline throws:

[Shaders/ShaderRegistry.cpp:1338 operator()] shader library prebuild skipped: AGC graphics: v_interp_mov p10 of a flat input with the first provoking vertex is not measured
[Shaders/ShaderRegistry.cpp:901 ReportPreparedAtUse] Shader 0x20e813000 stage 5 has no artifact prepared at registration for the state of this draw or dispatch; preparing it at use
terminate called after throwing an instance of 'std::runtime_error'
  what():  AGC graphics: v_interp_mov p10 of a flat input with the first provoking vertex is not measured

With no input, PS5NES stops 4 to 9 s after start and PS5N64 3 to 6 s after start (4 of 4 runs each). PS5NES stops the same way on main 7e2ba73, so it isn't new. Without a ROM, PS5NES ran its menus for 30 s and PS5N64 for 40 s.

Their graphics stack is ps5-opengl's Gallium/PSBC path, as for the other P10 cases above (the executables contain PSBC prepare failure: gallium-descriptors, nir_lower_flatshade and load_provoking_last). One caveat for weighing them as evidence: both build manifests say "console_tested": false, so they don't tell us what the console does.

ROMs used: 240pee.nes from pinobatch/240p-test-mini v0.23 (GPL-2.0) and PeterLemon/N64's CPUADD.N64 and HelloWorld*.N64 (Unlicense).

Windows 11, Ryzen 5 9600X, RTX 5070 Ti, WinLibs GCC 15.2.0, Release, main aeff26b.

AI-assisted: yes (Claude Code); results above were run on this machine.

Two more titles on the same front end stop on the first-mode half: FUTBOL13 (PPSA99405 01.000.002, by the author of Sahin) and GETSU-SAN (PPSA99604 v0.1.0-beta), both 2 s in, on main f3eb573e6f + #8346 (without #8346 both stop earlier, on sceAppInstUtilInitialize). Like Sahin, both ship ps5-opengl, Mesa (zink), Wine and DXVK under LICENSES/, so the shader comes from ps5-opengl's P10 lowering. Linux, RTX 4070 Ti, 615.71.09.

AI-assisted: yes (Claude Code)

Navigation Menu

Repository navigation

v_interp_mov P10/P20 of a FLAT_SHADE input without pass-through: deltas or raw vertices? #1413

Evidence for raw vertices

Evidence for deltas

What would settle it

Change ready if raw is right

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

v_interp_mov P10/P20 of a FLAT_SHADE input without pass-through: deltas or raw vertices? #1413

Description

Evidence for raw vertices

Evidence for deltas

What would settle it

Change ready if raw is right

Activity

TheAggie commented on Oct 8, 2026

TheAggie commented on Oct 8, 2026

jasoncannotbanme commented on Oct 8, 2026

klosixgaming-arch commented on Oct 8, 2026

CouchRiv commented on Oct 9, 2026

AlxcBTW commented on Oct 10, 2026

AlxcBTW commented on Oct 10, 2026

PrintOrb commented on Oct 11, 2026

AlxcBTW commented on Oct 11, 2026

codingreapermaps commented on Oct 12, 2026

orishamir commented on Oct 14, 2026

DavidSamir commented on Oct 20, 2026

LeandroLP23 commented on Oct 20, 2026

LeandroLP23 commented on Oct 20, 2026

MarcZX10 commented on Oct 20, 2026

SirDarky commented on Oct 21, 2026

LeandroLP23 commented on Oct 21, 2026

DavidSamir commented on Oct 21, 2026

wachi35676 commented on Oct 25, 2026

milescoviello commented on Oct 28, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions