Repository navigation
feat(agc): draw the last provoking vertex through the barycentric tessellation stages - #7426
Conversation
…entric tessellation stages
…sellation stages The generated evaluation stage writes the provoking vertex's flat values at every corner of the patch, so the host's provoking vertex no longer changes what the pixel shader reads and VK_EXT_provoking_vertex is not needed for these draws.
… through tessellation
…ic-tessellation-last-vertex # Conflicts: # docs/dev/debt/libSceAgcDriver.md
|
Cross-vendor check on NVIDIA, head Setup: Windows 11 Pro 26300, NVIDIA GeForce RTX 3070 (
So on NVIDIA the tessellation route gives the same pixels as the geometry route, including the flat inputs from the last provoking vertex. AI-assisted: yes |
|
Other open pull requests touch the same code. Merging one will break the other, or both implement the same thing. If this one builds on them, list them in Depends on.
Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.
|
…ic-tessellation-last-vertex # Conflicts: # core/shader/recompiler/SpirvBackend/src/BarycentricGeometryShader.cpp
|
Rebase handoff — rebased onto current Verified on Linux (CachyOS, kernel 7.2.9, GCC 16.2.1, Ninja, Release, To pick it up: Head is |
github-actions
Bot
added
needs rebase
…ic-tessellation-last-vertex # Conflicts: # core/libs/prx/libSceAgcDriver/Graphics/src/Pipeline.cpp # core/shader/recompiler/SpirvBackend/src/BarycentricGeometryShader.cpp # docs/dev/debt/libSceAgcDriver.md # docs/dev/debt/shader.md
|
Intel and AMD Windows data: with this PR the 19 tests built from Windows 11 Pro 26300, WinLibs GCC 15.2.0 r7, Release, every execution test built,
The test files don't build on I also ran full CTest with this PR and the 13 other open AGC and shader PRs I tested in the same batch merged together (#7668, #7659, #7504, #7432, #7413, #7480, #7465, #7466, #7464, #7449, #7489, #7673, #7560). Neither GPU showed a failure beyond AI-assisted: yes (Claude Code) |
…hrough the barycentric tessellation stages (@DavidSamir) Apple GPUs under MoltenVK have neither geometry shaders nor VK_EXT_provoking_vertex, so a last-provoking-vertex draw that needs the barycentric emulation stopped on macOS; DavidSamir's PR draws it through the generated tessellation stages instead. In Pipeline.cpp its early return for those draws sits before this branch's early return for draws no pixel input sees (boykopovar#6741), and both stay. The barycentric emulation test takes the PR's flat and provoking parameters and keeps this branch's built-in switch after them. The debt files take the PR's entries and keep this branch's short MoltenVK ones. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… no pixel input sees without the extension (@DavidSamir) This branch already carried an earlier head of this PR; DavidSamir has pushed newer commits since, and this merge brings the branch up to them. The only conflict is the provoking vertex debt entry, where the branch already holds boykopovar#7426's entry and its own short entry for the draws no pixel input sees; both are kept as they are. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ic-tessellation-last-vertex # Conflicts: # docs/dev/debt/shader.md
|
First AMD-on-Linux (RADV) run of this PR. Merged onto AMD Radeon RX 7900 XT (RADV NAVI31, gfx1100), Mesa 25.2.8, Linux Mint 22.3 (Ubuntu 24.04 base), kernel 7.0.0-38, GCC 13.3, Release. Full suite ( Comparing the JUnit output with This checks correctness only; I did not measure performance. GPUs tested: AMD Radeon RX 7900 XT (RADV NAVI31, gfx1100), Mesa 25.2.8, Linux Mint 22.3 / kernel 7.0.0-38 AI-assisted: yes |
|
Title evidence for #6741 and #7426 together, from a macOS catalog sweep: Apple M2, MoltenVK 1.4.x (no On that base, 12 catalog titles stop at
So on a device without the extension these titles need both changes: #6741 for their last-vertex draws whose pixel shader cannot see which vertex provokes, and #7426 for the ones whose pixel shader reads emulated barycentrics through the generated tessellation stages. Either alone still stops at the same check. Nothing past 30 s is tested; MoltenVK-specific limits (#6235, #6528) are not in the way of these 11. The two PRs touch the same function ( AI-assisted: yes (Claude Code) |
|
Validation-layer comparison, as AGENTS.md now asks for AGC changes. Apple M2, MoltenVK 1.4.x (Vulkan SDK 1.4.363), macOS 26, x86-64 under Rosetta 2, same machine and build directory, on
No new validation errors with the two changes. The title results for the pair are in the comment above (11 catalog titles run past the provoking-vertex stop with both). AI-assisted: yes (Claude Code) |
…ic-tessellation-last-vertex
|
Validation-layer comparison as AGENTS.md describes:
Not covered: an NVIDIA run with the validation layer. This machine's RTX 3070 has no Khronos layer installed. AI-assisted: yes |
|
No-regression run on a GPU with The nine titles listed for the Mac all run the full 60 s on both builds: SymphonyStation5 (PPSA17641), VITA5 (PPSA39410), Signal Companion (PPSA69426), PokeMMO (PPSA98001), ProsperoLight (PPSA99002), PS5LM (PPSA99575), Cloud Play (PPSA99600), PShare (PPSA99773) and Pulse (PPSA99993). None stops early. This device takes the extension's native path, so this run checks only that nothing regresses. The emulated path is covered by the Mac runs in the description. AI-assisted: yes |
|
Re-checked against current |
…ellation Upstream's boykopovar#7426 gave BuildBarycentricTessellationShaders a provoking vertex argument. The macOS mesh-emulation draw still called it with four arguments, so VulkanDevice.cpp no longer compiled after merging feat/macos-port. It now passes the draw's provoking vertex mode the same way the regular vertex path in Draw.cpp does (0 for first, 2 for last). macOS only; the Linux and Windows views are unchanged. The 16 mesh, barycentric and provoking-vertex tests pass or skip as before.
5 participants
What
With #7308, a device without geometry shaders draws the barycentric emulation through generated tessellation stages. In last provoking vertex mode (
PA_SU_SC_MODE_CNTL.PROVOKING_VTX_LAST) those draws still stopped withlast provoking vertex requires VK_EXT_provoking_vertex with provokingVertexLast enabled. Apple GPUs under MoltenVK have neither geometry shaders nor that extension, so after #7308 this became the next stop for several catalog titles on macOS.The generated stages don't need the extension. The evaluation stage already writes each flat parameter as one vertex's value at every corner of the patch, so the host's choice of provoking vertex for the tessellated triangle cannot change what the pixel shader reads. This PR picks that vertex from the draw's mode, the same way #7251 handles rect lists:
BuildBarycentricTessellationShaderstakes the provoking vertex, 0 or 2 (anything else throws), and the evaluation stage writes the flat parameters from it.ValidateProvokingVertex: for these generated stages, last mode no longer requiresVK_EXT_provoking_vertex. A flat per-vertex parameter (flat && perVertex) still throws, as it does for every pipeline in last mode.shader.mdandlibSceAgcDriver.mdnow describe the exception.Commits: shader stages, driver wiring, tests, docs, then a merge of current
main.Tested
Apple M2, macOS 26.7.1, MoltenVK 1.4.2 (no
geometryShader, noVK_EXT_provoking_vertex), x86-64 under Rosetta, on the community macOS stack with #7308. The changed files also compile on this Mac against currentmain, and the conventions check passes.agc_driver_pixel_barycentric_emulation(extended) passes on the M2. A new pixel shader reads the raw I/J (which turns the emulation on) and a FLAT_SHADE input throughv_interp_mov_f32P0. Inside the triangle the weights match, and the flat value is exactly vertex 0's clip x (-0.8) in first mode and vertex 2's (-0.25) in last mode. The geometry route still runs first mode only, where the device has geometry shaders.agc_driver_graphics_testspasses. New cases:Titles (homebrew catalog, checksum-checked, 60 s each, relinked for macOS):
mutex lock failedmessage appears only when the run is stopped at the end)viewport depth outside [0, 1] requires VK_EXT_depth_range_unrestricted, which the M2 lacksRégie5 (PPSA99520) also gets past this stop, then hangs the GPU about 2 s in. The hang stays when every draw of this PR's stages is skipped (
APS5_SKIP_SHADERon their pixel shader), so it is unrelated.Device limits of the M2 that stop titles here, not tested past them: no
geometryShader,shaderFloat64,VK_EXT_provoking_vertexorVK_EXT_depth_range_unrestricted.Not tested: Windows and Linux, where devices with geometry shaders keep the unchanged geometry route.
Overlap: our #6741 changes the same function, letting a last-mode draw with no flat or per-vertex pixel input use the first-vertex mode. The two only add separate exemptions, so the code merges as both together. Whichever lands second gets a small merge of
Pipeline.cppand the provoking-vertex debt line from me.Checklist
main; no other open PR implements the same functionsNotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file.mdfiles or images added to the repository (attach them to this PR)