Repository navigation
fix(shader): hand a geometry program strip and fan triangles in the order of its provoking vertex mode - #7893
Open
thuanquang wants to merge 3 commits into
Open
thuanquang wants to merge 3 commits into
thuanquang wants to merge 3 commits into
Conversation
|
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.
|
Contributor
|
Intel and AMD Windows data: with this PR's test changes, the last-provoking-vertex geometry draws fail on Windows 11 Pro 26300, WinLibs GCC 15.2.0 r7, Release, every execution test built,
AI-assisted: yes (Claude Code) |
Contributor
|
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 ( 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 |
Merged
12 tasks done
thuanquang
force-pushed
the
fix/strip-first-provoking-order
branch
from
October 20, 2026 08:24
6063218 to
40bd67b
Compare
12 tasks done
Collaborator
|
@thuanquang a heads-up for the rebase:
A last-mode strip case through a geometry program that would have hit |
…rder of its provoking vertex mode The translator handed a geometry program odd strip triangle i as (i+1, i, i+2) and fan triangle i as (i+1, i+2, 0) in both provoking vertex modes. An RX 6700 XT hands a geometry shader odd strip triangles as (i, i+2, i+1) in first mode and fan triangles as (0, i+1, i+2) in last mode, so with the first provoking vertex the flat inputs of odd strip triangles came from vertex i+1 instead of i. Take the mode from the mesh configuration's provoking vertex, which is already part of every pipeline and shader cache key, and drop the last-mode refusal of fans assembled for a geometry program. Co-Authored-By: Claude <noreply@anthropic.com>
thuanquang
force-pushed
the
fix/strip-first-provoking-order
branch
from
October 21, 2026 15:03
40bd67b to
d054ce3
Compare
Contributor
Author
|
@oneandonlydean thanks for the heads-up. The rebase to d054ce3 handles it, and since #7883 has merged, this PR's diff against
The test runs are in the description. |
12 tasks done
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Follow-up to #7883, built on it. #7883 measured on an RX 6700 XT (probe source and output) the order in which AMD's geometry engine hands a geometry program its input triangles:
The translator's mesh entry gives odd strip triangles as (i+1, i, i+2) in both modes, so in first mode a geometry program's flat values for odd strip triangles come from v[i+1] instead of v[i]. It also gives fans as (i+1, i+2, 0) in both modes, which is why #7883 kept refusing last-mode fans.
This change makes the order follow the mode (
mesh.provokingVertex, which is 0 in first mode and the output's last slot in last mode):The refusal of last-mode fans assembled for a geometry program goes away. For strips and for fans, the two orders are rotations of each other, so each triangle keeps its winding and culling does not change. Restart handling and the parity reset are untouched.
mesh.provokingVertexis already part of every key that holds a translated module (pipeline, draw and register keys, pipeline journal and request serializer), and translated modules are keyed by the recompiler's source hash. So no key or format version changes.The console's order is not measured, and the debt entry says so. The entry is also cut to 999 characters, since this change closes the strip and fan part of the gap.
Tested
Windows 11 26200, AMD Radeon RX 6700 XT (gfx1031), driver 32.0.21045.5002, WinLibs GCC 15.2.0 r7, Release,
BUILD_TESTING=ON,ANYPS5_NO_SHADER_CACHE=1.This head (
d054ce3afb) is one commit on #7883's new head0bd8f6188a, which is rebased over #7426 ontomain2c4b116da9. #7883 has since been merged (merge commitd27d05ec14, whose second parent is0bd8f6188a), so this PR's diff againstmainis now this one commit. InValidateProvokingVertexthis change still removes the fan refusal and keepsmain's generated-primitiveRequire. ThePROVOKING_VTX_LASTdebt entry keeps this PR's version plus #7426's statement that the generated barycentric tessellation stages give each corner the last vertex's flat values (972 characters; the opengnm link is now named rather than linked, to stay under 1000). On this head:agc_driver_graphics,agc_driver_mesh,agc_driver_mesh_provoking_vertex,agc_driver_mesh_provoking_layer,agc_driver_provoking_vertexand feat(agc): draw the last provoking vertex through the barycentric tessellation stages #7426'sagc_driver_pixel_barycentric_emulationpass 3 of 3.main2c4b116da9) and B (this head), the same six tests: six of six pass on both, with noVUID-line and nowas not found but was requested; the only layer output on both isWARNING-VkImageSubresourceRange-layerCount-compatibility.The results below were measured on the previous head
40bd67bef.agc_driver_mesh_provoking_vertex:agc_driver_graphics: last-mode fans through a geometry program now validate.triangle strip, first provoking vertex, triangle 1 (the color of vertex 1): pixel (26, 48) channel 1 is 0, expected 255.triangle fan, last provoking vertex, triangle 0 (the color of vertex 2): pixel (12, 32) channel 1 is 255, expected 0.last provoking vertex is unsupported for triangle fans assembled for a geometry program.agc_driver_graphics,agc_driver_mesh,agc_driver_mesh_provoking_layer,agc_driver_mesh_provoking_vertexandagc_driver_provoking_vertexpass 3 of 3.VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation,ANYPS5_NO_SHADER_CACHE=1,ANYPS5_REQUIRE_VULKAN=1,ctest -V, same RX 6700 XT, onmain38de0a470(other test files modified locally; none of these tests' sources), on fix(agc): draw triangle strips through a geometry program with the last provoking vertex #788359cabc57band on fix(shader): hand a geometry program strip and fan triangles in the order of its provoking vertex mode #7893606321886:agc_driver_graphics,agc_driver_mesh,agc_driver_mesh_provoking_vertex,agc_driver_mesh_provoking_layerandagc_driver_provoking_vertexpass on all three. No log reportswas not found but was requestedor anyVUID-error. The layer's only output is the sameWARNING-VkImageSubresourceRange-layerCount-compatibilitywarning inagc_driver_mesh_provoking_layeron all three trees.python tools/check_conventions.py --base origin/mainpasses.mainas the red side, the last-provoking-vertex geometry draws fail onmainand pass here. The UHD 770 has no mesh shaders, so the mesh test skips there.main.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)🤖 Generated with Claude Code