[milescoviello]

What

This PR's first two commits reached main through #8115 as identical patches: LinkPipelineFromLibraries copies a linked pipeline's attachment sample counts and chains them to the link's and relink's create info. What is left is the follow-up from @MarcZX10's review:

• Pipeline.cpp gives a depth-only merged-coverage pipeline a VkAttachmentSampleCountInfo with colorAttachmentCount 0 and a null pColorAttachmentSamples, which Vulkan allows.
• Copying the counts built a vector from the range [null, null). The range constructor passes that null source to memmove, which requires non-null pointers even for 0 bytes.
• The color counts are now copied only when there are color attachments. The struct then carries an empty vector, and attachmentSamples already chains a null pColorAttachmentSamples for it.

Tested

Current head 5d1e214ce3 (the one commit, rebased onto main 52c09d567d without conflicts; git range-diff shows it unchanged), Ubuntu 26.04.1, GCC 15.2, RTX 4070 Ti, NVIDIA 615.71.09:

• Focused tests: 85 of the 86 tests matching the regex below pass in each of 3 runs. agc_driver_pipeline_journal fails on main too, as described below.
• Validation layer, over the same 86, on main 52c09d567d and at this head: 85 of 86 on both, with the same journal failure. Neither log has a missing-layer line, the layer checked 104 devices on each side, and neither has a VUID- message.

Previous head e6d81fbe9b (on main 3a2b919816), same machine:

• Focused tests: of the 86 tests matching pipeline_library|^agc_driver_prepared|^agc_driver_graphics$|sample_coverage|msaa|multisample|pipeline_cache|journal, 85 pass in each of 3 runs. agc_driver_pipeline_journal fails the same way on main 3a2b919816. On this machine its 11th Vulkan device can't load the NVIDIA driver (libnvidia-tls.so.615.71.09: cannot allocate memory in static TLS block, with VK_LOADER_DEBUG=error) and falls back to llvmpipe. It passes with GLIBC_TUNABLES=glibc.rtld.optional_static_tls=8192, so it isn't this change.
• Validation layer: VK_LAYER_PATH=<LunarG SDK 1.4.363>/layers VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation ANYPS5_NO_SHADER_CACHE=1 ANYPS5_REQUIRE_VULKAN=1 ctest -V over the same 86, on main 3a2b919816 and on this head.
  • Both give 85 of 86, with the same journal failure.
  • Neither log contains was not found but was requested by env var VK_INSTANCE_LAYERS.
  • The layer checked 104 devices on each side, with no VUID- messages on either.

Previous head 6346c5f2fe (on main cf528e7): on Ubuntu 26.04.1, GCC 15.2, RTX 4070 Ti, 615.71.09, the 71 tests matching pipeline_library|^agc_driver_prepared|^agc_driver_graphics$|sample_coverage|msaa|multisample|pipeline_cache|journal pass 3 of 3. Khronos validation 1.4.363 over the same 71 (VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation ANYPS5_REQUIRE_VULKAN=1 ANYPS5_NO_SHADER_CACHE=1 ctest -V) gives 71 of 71 on main and on this head. Neither log has a layer-missing line. Both sides report the same pre-existing 14 VUID-VkPipelineColorBlendStateCreateInfo-pAttachments-00605, and nothing is new in the head.

Windows, on the current head e6d81fbe9b and on main 3a2b919816: Windows 11 VM, GeForce GT 1030 (NVIDIA R580), WinLibs GCC 15.2, Release, ANYPS5_REQUIRE_VULKAN=1. The 88 tests matching the same regex there pass 3 of 3 on both, agc_driver_pipeline_journal included. (On the earlier head ff61956e21 and its merge base eb8dcfe, the 68 tests the regex selected then passed 3 of 3 on both.)

@ycbuzi ran the previous head on AMD (comment): 6346c5f2fe merged onto main 1da5d1a, Windows 11 Home, WinLibs GCC 15.2.0, Release, AMD Radeon RDNA2 iGPU (driver 32.0.21030.2001), with ANYPS5_REQUIRE_VULKAN=1 ANYPS5_NO_SHADER_CACHE=1. The same regex selects 72 tests there, and they pass 72 of 72 on main and 72 of 72 with this PR. The validation layer was not run on that device.

Earlier results, on the three-commit heads named in them:

Ubuntu 24.04, GCC 13.3, NVIDIA RTX 4070 Ti (595.99.02).

• Khronos validation, as CONTRIBUTING.md asks, with the LunarG SDK's 1.4.363 layer loaded through VK_LAYER_PATH: VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation ANYPS5_NO_SHADER_CACHE=1 ANYPS5_REQUIRE_VULKAN=1 ctest -V -R sample_coverage. main 1126abb reports VUID-vkCmdDraw-multisampledRenderToSingleSampled-07285 ×2. With this change it reports nothing, and neither log reports the layer missing. That holds both for 6bf4a39, which chained the counts under VkPipelineLibraryCreateInfoKHR (outside its allowed pNext chain, as @ebosido444-ai pointed out), and for c46005c, which chains them to the create info.

• With APS5_NO_GPL=1, main already reports nothing, so only the library path was affected.

• The 58 tests matching pipeline_library|^agc_driver_prepared|^agc_driver_graphics$|sample_coverage|msaa|multisample|pipeline_cache|journal pass with this change, as on main.

• e9c9857, after @MarcZX10's review: the color sample counts are copied only when colorAttachmentCount is non-zero. A depth-only pipeline's VkAttachmentSampleCountInfoNV (zero colors, and a null array, as Pipeline.cpp builds it) then never reads pColorAttachmentSamples. On Ubuntu 26.04.1 (GCC 15.2, NVIDIA 615.71.09), the same 58-test set passes 2 of 2 on this head. Khronos validation 1.4.363 over sample_coverage: the merge base 1126abb reports VUID-vkCmdDraw-multisampledRenderToSingleSampled-07285 ×2. This head reports no VUID, and neither run reports the layer missing.

Overlaps (checked 10-28 against the current heads): neither still edits the lines this PR changes.

• perf(agc): GPU descriptor heap on VK_EXT_descriptor_heap (APS5_GPU_HEAP) #9508's head 6275369b6c merges with this PR without a conflict.
• perf(agc): build the pipelines of a submission ahead on a compile pool #5925's head 3339ddd3af predates the sample-count copy this guard sits in (7c63ee6970, which reached main with feat(agc): draw one-sample color targets beside a multisampled depth target with sample 0's coverage #8115). It doesn't edit these three lines. It conflicts with main itself in PipelineLibrary.cpp and other files, so its rebase meets this code either way.

So there's no order to agree, and Depends on stays none.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none
• Fixes: none
• Unblocks: none
• GPUs tested: NVIDIA GeForce RTX 4070 Ti, driver 595.99.02, Ubuntu 24.04; AMD Radeon RDNA2 iGPU, driver 32.0.21030.2001, Windows 11 (tests, by @ycbuzi)
• AI-assisted: yes (Claude Code)

🤖 Generated with Claude Code

[github-actions]

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.

Pull request	Shared files not compared
PR 5925	core/libs/prx/libSceAgcDriver/Graphics/src/PipelineLibrary.cpp
PR 7642	core/libs/prx/libSceAgcDriver/Graphics/src/PipelineLibrary.cpp
PR 10193	core/libs/prx/libSceAgcDriver/Graphics/src/PipelineLibrary.cpp
PR 11914	core/libs/prx/libSceAgcDriver/Graphics/src/PipelineLibrary.cpp
PR 12323	core/libs/prx/libSceAgcDriver/Graphics/src/PipelineLibrary.cpp
PR 13928	core/libs/prx/libSceAgcDriver/Graphics/src/PipelineLibrary.cpp
PR 13929	core/libs/prx/libSceAgcDriver/Graphics/src/PipelineLibrary.cpp

[ebosido444-ai]

VkAttachmentSampleCountInfoNV may only extend VkGraphicsPipelineCreateInfo and VkCommandBufferInheritanceInfo, so chaining it off VkPipelineLibraryCreateInfoKHR::pNext (both at the link and in the deferred relink) is outside the allowed chain even though the validation layer stayed quiet — layers walk nested pNext chains transitively and do not reject a struct under a parent it is not allowed to extend.

Put the counts on the graphics create info instead: counts.pNext = create.pNext; create.pNext = &counts; (counts first, then the library list where it belongs), in both the link and the relink, and re-run the sample_coverage validation command. If 07285 stays gone with the struct on the create info, that is the conformant form of the same fix.

The copy-out and the by-value capture that keeps the array alive across the deferred relink are right — only the chain placement needs to move.

AI-assisted: yes.

[milescoviello]

@ebosido444-ai thanks, you're right. VkAttachmentSampleCountInfoNV extends only VkGraphicsPipelineCreateInfo and VkCommandBufferInheritanceInfo, and the layer didn't flag it under VkPipelineLibraryCreateInfoKHR. c46005c chains the counts to the create info in both the link and the relink (counts.pNext = create.pNext; create.pNext = &counts), and the library list stays where it was. Reran VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation ANYPS5_NO_SHADER_CACHE=1 ANYPS5_REQUIRE_VULKAN=1 ctest -V -R sample_coverage with the 1.4.363 layer: main 1126abb still reports 07285 ×2, and c46005c reports nothing, with the layer loaded on both. The description says this now.

AI-assisted: yes (Claude Code)

[MarcZX10]

Two issues block approval:

1. Please handle a zero-color-attachment pipeline safely. Vulkan permits dynamic rendering with colorAttachmentCount == 0; a depth-only pipeline may still carry VkAttachmentSampleCountInfoNV, with no color-sample array. The current sampleCounts.emplace evaluates counts.pColorAttachmentSamples + counts.colorAttachmentCount and constructs a vector from that range. If the valid zero-count pointer is null, this forms a null-pointer range. Guard the copy on colorAttachmentCount != 0 and cover or otherwise verify the zero-color case. The struct is also valid in the VkGraphicsPipelineCreateInfo chain: https://docs.vulkan.org/refpages/latest/refpages/source/VkAttachmentSampleCountInfoAMD.html

2. Please coordinate the Depends on order with the authors of open #9508 and #5925. The current overlap scan reports direct same-line edits with #9508 in PipelineLibrary.cpp (link creation and the deferred relink capture). Manual comparison also shows #5925 changes the same link-creation setup and relink lambda. #7642's edits in this file are confined to the split-layout handling and appear disjoint. The checklist currently says Depends on: none; after the authors agree which changes land first, update it to match the integration order. This follows the repository's overlap rule in CONTRIBUTING.md.

The current hosted eligibility, conventions, labels, and report checks pass. The focused validation results are author-reported; I did not run a local build or GPU test.

[milescoviello]

@Raghav314 @adriadam10, @MarcZX10 pointed out that this PR edits the same lines in PipelineLibrary.cpp as #9508 and #5925: the link-time create info in LinkPipelineFromLibraries and the deferred relink lambda. git merge-tree confirms both conflict with this head.

This change is small. It finds the VkAttachmentSampleCountInfoNV in the rendering info's chain, keeps a copy, and chains it in front of the link's and the relink's VkPipelineLibraryCreateInfoKHR. The relink lambda also captures the copy. So whichever lands second only has to re-add those few lines.

I'm happy to go either way:

• If this lands first, your rebase keeps sampleCounts / attachmentSamples and the pNext chaining in both places.
• If either of yours lands first, I'll rebase this onto it and list it under Depends on.

Is there an order you'd prefer?

AI-assisted: yes (Claude Code)

[milescoviello]

Thanks @MarcZX10.

1. Done in e9c9857: the color sample array is copied only when colorAttachmentCount != 0. The struct then carries an empty vector, and attachmentSamples already chains a null pColorAttachmentSamples for it. Our only producer, Pipeline.cpp, passes count 0 with a null pointer for a depth-only merged-coverage pipeline, so that's the case this covers. The PR's 58-test set passes 2 of 2 on this head. A validation-layer comparison of the sample_coverage tests is queued, and I'll add it when it's done.

   I left the scan on the rendering info's chain on purpose. The driver only ever puts the struct there, and these create infos never come from a title.

2. I've asked @Raghav314 and @adriadam10 about the order above, and the body now lists both overlaps. I'll set Depends on once there's an answer.

AI-assisted: yes (Claude Code)

[oneandonlydean]

@milescoviello your first two commits here (6bf4a39f25, c46005c996) reached main through #8115 as identical patches. That's why GitHub now shows a conflict in PipelineLibrary.cpp.

Only e9c9857eae (copy the colour sample counts only when there are colour attachments) is new. It applies cleanly onto current main. Could you rebase so the PR is just that commit? If you'd rather we do it, say so and I'll push the rebase to your branch.

[milescoviello]

@oneandonlydean thanks, done: the branch is now just that commit, ff61956 on current main d3efe3a. Its focused tests (pipeline_library|^agc_driver_prepared|^agc_driver_graphics$|sample_coverage|msaa|multisample|pipeline_cache|journal) and the layer comparison are queued behind a title run on this machine. I'll push once they pass and update Tested to the single commit.

AI-assisted: yes (Claude Code)

[milescoviello]

@oneandonlydean pushed: the branch is now just ff61956 on main d3efe3a. The 67 focused tests pass 3 of 3, and the 1.4.363 layer comparison matches main: the same pre-existing 00605 x14 on both sides, nothing new. I retitled the PR and rewrote What and Tested for the single commit.

AI-assisted: yes (Claude Code)

[milescoviello]

@MarcZX10 rebased onto current main cf528e7; head 6346c5f2fe. It's still the one commit, the colorAttachmentCount != 0 guard (3 lines in PipelineLibrary.cpp). The two earlier commits reached main through #8115, so they're gone from this branch.

• Linux (Ubuntu 26.04.1, GCC 15.2, Release, RTX 4070 Ti, 615.71.09): the 71 tests matching pipeline_library|^agc_driver_prepared|^agc_driver_graphics$|sample_coverage|msaa|multisample|pipeline_cache|journal pass 3 of 3.
• Khronos validation 1.4.363 over the same 71 (VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation ANYPS5_REQUIRE_VULKAN=1 ANYPS5_NO_SHADER_CACHE=1 ctest -V): 71 of 71 on main and on this head, no layer-missing line, and the same pre-existing 14 VUID-VkPipelineColorBlendStateCreateInfo-pAttachments-00605 on both sides. Nothing is new in the head.
• Your second point (order with perf(agc): GPU descriptor heap on VK_EXT_descriptor_heap (APS5_GPU_HEAP) #9508 and perf(agc): build the pipelines of a submission ahead on a compile pool #5925): the same-line edits it flagged were in the two commits that landed through feat(agc): draw one-sample color targets beside a multisampled depth target with sample 0's coverage #8115. On this head tools/pr_overlap.py no longer reports perf(agc): GPU descriptor heap on VK_EXT_descriptor_heap (APS5_GPU_HEAP) #9508. perf(agc): build the pipelines of a submission ahead on a compile pool #5925, fix(runtime): isolate host worker MXCSR #7622, feat(agc): look up table images at run time through a device image table on the GPU heap (APS5_GPU_PATH) #7642 and feat(agc): serve lane-keyed, pointer and runtime image-table columns #10193 share PipelineLibrary.cpp but conflict with main already, so the tool couldn't compare them. This commit only changes how the colour sample array is copied when the count is zero, so whichever lands first, the other resolves it by keeping the guard. I've left Depends on: none.

AI-assisted: yes (Claude Code)

[ycbuzi]

AMD coverage for the focused set. 6346c5f2fe merged onto main 1da5d1a757 (d4d175faf8), Windows 11 Home 10.0.26200, WinLibs MinGW-w64 GCC 15.2.0 (ucrt-posix-seh r7), Release, on the AMD Radeon(TM) Graphics RDNA2 iGPU (0x164e, driver 32.0.21030.2001), ANYPS5_GPU=Radeon ANYPS5_REQUIRE_VULKAN=1 ANYPS5_NO_SHADER_CACHE=1.

ctest -R 'pipeline_library|^agc_driver_prepared|^agc_driver_graphics$|sample_coverage|msaa|multisample|pipeline_cache|journal' selects 72 tests on this main: 72 of 72 pass on main 1da5d1a757 and 72 of 72 pass with this PR. Both sides were freshly built (build exit 0, 27 test executables each). Not run: the Khronos validation layer on this device. AI-assisted: yes (Claude Code)

[milescoviello]

@ycbuzi thank you for the RDNA2 run, the first AMD coverage this PR has. I've added it to Tested and the GPU to the checklist.

AI-assisted: yes (Claude Code)

[MarcZX10]

The zero-color guard addresses the null-range issue, and the current one-commit diff is limited to copying color sample counts only when colorAttachmentCount is nonzero. The author reports Linux NVIDIA validation tests and Windows AMD focused tests passing against corresponding main baselines; no new validation IDs were introduced. Hosted policy checks pass, while product jobs are skipped. I did not run a local GPU test.

The current thread still describes overlap with open #5925 and #9508 in PipelineLibrary.cpp; the checklist says Depends on: none, and I found no agreed landing order from their authors. Please confirm whether the exact current heads still overlap this guard. If they do, coordinate which change lands first and record the order in the relevant checklists; if they no longer overlap, update the description/overlap record. I cannot complete approval until the repository's overlap-order rule is resolved.

[milescoviello]

@MarcZX10 I checked the exact current heads:

• perf(agc): GPU descriptor heap on VK_EXT_descriptor_heap (APS5_GPU_HEAP) #9508 (6275369b6c) merges with this PR without a conflict.
• perf(agc): build the pipelines of a submission ahead on a compile pool #5925 (3339ddd3af) is based on a main from before 7c63ee6970 (feat(agc): draw one-sample color targets beside a multisampled depth target with sample 0's coverage #8115), the commit that added the sample-count copy this PR guards. Its diff never touches these lines.
• Applied onto perf(agc): build the pipelines of a submission ahead on a compile pool #5925's head, this PR's hunk conflicts only because that base doesn't have the line yet.
• perf(agc): build the pipelines of a submission ahead on a compile pool #5925 conflicts with main itself in PipelineLibrary.cpp and a dozen other files, so its rebase will meet this code whichever lands first.

Neither PR overlaps these lines now, so I've updated the overlap note in the description and left Depends on: none. @adriadam10 @Raghav314, for the record: this is three lines in LinkPipelineFromLibraries, the colorAttachmentCount != 0 guard.

AI-assisted: yes (Claude Code)

[MarcZX10]

Re-checked — changes requested for current-main rerun

Your exact-head comparisons resolve the earlier overlap question: #9508 merges cleanly, and #5925's changes are separate from this guard. The remaining blocker is that this branch is still based on cf528e78c6, while current main is 3a2b91981651569163768854a1fcdc7193b6667b.

What I ran

• Reviewed exact head 6346c5f2fefef8eed6745f5cf4399d868876d50f and inspected the overlap update.
• Compared #7985 with current #9508 and #5925 heads, checked the merge preview onto current main, and inspected changes to PipelineLibrary.cpp since the branch base.
• Ran git diff --check and the current conventions checker against this head.

Results

Check	Result
Current-main merge preview	Raw output merge-tree-exit=0; tree e48d0cae9d46132348bbb808db1538f2a48553fa
Overlap update	Raw status #9508 merges cleanly; #5925's link-creation/relink changes are separate from the three-line sample-count guard, though #5925 itself needs a main rebase.
Whitespace check	Raw output git diff --check upstream/main...refs/review/pr-7985 — no output; exit status 0
Conventions	Raw output All conventions checks passed.
Author-reported GPU validation	Reported result The PR body reports the focused pipeline/sample-count tests on NVIDIA and AMD with validation on the prior base cf528e78c6; these were not independently rerun here.
Branch freshness	Raw values Merge base cf528e78c6c8fd30696ccfca6c097f9828be2cf6; current main is 4,703 commits ahead. Current main also changes the optimization key and pipeline flags in PipelineLibrary.cpp.

Negative control

The author reports that a depth-only pipeline with a null color-sample pointer previously triggered the invalid range construction, and that the guard fixes it. I did not independently run the depth-only Vulkan case on this head.

Findings

Blocking

• CONTRIBUTING.md requires keeping the branch up to date with main. Because current main has since changed PipelineLibrary.cpp, the earlier focused comparison on cf528e78c6 does not cover the current integration. Please rebase and rerun the same focused tests on current main and the updated PR with the required validation-layer settings.

Non-blocking

• The updated overlap note is adequate for the guard: #9508 is compatible, and #5925's stale-base conflicts are outside the guarded sample-count range. Keep the explanation in the PR description.

Sources

• PR head: 6346c5f2fefef8eed6745f5cf4399d868876d50f.
• Current main: 3a2b91981651569163768854a1fcdc7193b6667b.
• CONTRIBUTING.md at current main.

Not verified

I did not build or run Vulkan tests locally. The focused GPU results and negative control are author-reported on the older base. Hosted policy checks pass; full product and specialized hosted jobs are skipped.

To get this to a good state

Rebase on current main, run the focused depth-only/pipeline tests on the same GPU on main and the PR with validation enabled, and report the exact revisions and VUID comparison.

[milescoviello]

@MarcZX10 thanks. Rebased onto main 3a2b919816 as e6d81fbe9b; the one commit applied without conflicts. The same focused set (pipeline_library|^agc_driver_prepared|^agc_driver_graphics$|sample_coverage|msaa|multisample|pipeline_cache|journal) and the base/head validation-layer comparison are queued behind the title runs on this machine. I will push the rebased head together with the results.

AI-assisted: yes (Claude Code)

[milescoviello]

@MarcZX10 rebased and rerun: head e6d81fbe9b on main 3a2b919816 (one commit, no conflicts). Same RTX 4070 Ti, NVIDIA 615.71.09; details in Tested:

• Focused tests: 85 of the 86 tests matching the regex pass in each of 3 runs. agc_driver_pipeline_journal fails on main too: the host's NVIDIA driver runs out of static TLS at the test's 11th device, and the test passes with a larger glibc.rtld.optional_static_tls.
• Validation layer (1.4.363, VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation ANYPS5_NO_SHADER_CACHE=1 ANYPS5_REQUIRE_VULKAN=1 ctest -V): the same 85 of 86 on main and on the head. No missing-layer message on either side, 104 devices checked on each, and no VUID- messages on either.

AI-assisted: yes (Claude Code)

[MarcZX10]

Re-checked — changes requested

The focused GPU and validation-layer report is detailed, including the same 85/86 result on base and candidate. However, the tested base is main 3a2b919816, while current main is 52c09d567d2fa453494dd720fcf53a98149468e4; this head is 36 commits behind. The contribution checklist requires the branch to be based on current main.

What I ran

• Reviewed exact head e6d81fbe9bf70441ed4fc17b5b2c4848c8e9298a against current main.
• Ran git merge-tree --write-tree and git diff --check.
• Checked the author’s exact-head GPU/validation report and current hosted checks.

Results

Check	Result
Current-main merge preview	Clean; current main is not in the branch history
git diff --check	Passed
Focused GPU tests	Author reports 85/86 on the old base and head in three runs, with the same known TLS failure
Validation layer	Author reports matching results and no VUID- messages on that old base/head pair
Current-main run	Not reported

Please refresh onto current main and rerun the focused test and validation comparison there. I did not run a local GPU build, so I cannot treat the earlier base/head comparison as current integration evidence.

[milescoviello]

@MarcZX10 thanks. Refreshed onto main 52c09d567d; the head is 5d1e214ce3. The one commit rebased without conflicts, and git range-diff shows it unchanged. On that base and head (RTX 4070 Ti, NVIDIA 615.71.09):

• Focused regex, the same 86 tests: 85 of 86 pass in each of 3 runs. agc_driver_pipeline_journal fails the same way on main: the host's NVIDIA driver runs out of static TLS at the test's 11th device.
• Validation layer (1.4.363, VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation ANYPS5_NO_SHADER_CACHE=1 ANYPS5_REQUIRE_VULKAN=1 ctest -V): 85 of 86 on main 52c09d567d and on the head. Neither log has a missing-layer line, the layer checked 104 devices on each side, and there are no VUID- messages on either.

AI-assisted: yes (Claude Code)

[MarcZX10]

Re-reviewed — approved

I reviewed exact head 5d1e214ce3de525b07e5328cb87993fc91d46439 against current main 2960e9a6e7e1fc99c4ed180c71495b5eb83464c7.

What I ran

• Inspected the sole production change in PipelineLibrary.cpp: it avoids forming a vector range from pColorAttachmentSamples when colorAttachmentCount is zero, and retains the existing values when the count is nonzero.
• Ran git merge-tree --write-tree refs/remotes/upstream/main refs/review/upstream-7985; it returned clean tree 8e92f48dd104208d3fc7de172916833f5a6a510b.
• Ran git diff --check refs/remotes/upstream/main...refs/review/upstream-7985; exit 0, no output.
• Confirmed current main has no later change to PipelineLibrary.cpp since the author's tested base 52c09d567d.
• I did not run a local build or GPU tests.

Results

Check	Result
Current-main merge preview	Clean
Diff check	Pass
Focused GPU/validation comparison	Author reports the same 85/86 result on base and head over three runs; agc_driver_pipeline_journal fails identically on both due to the NVIDIA static-TLS limit
Validation layer	Author reports it checked 104 devices on each side with no missing-layer or VUID- messages
Hosted checks	Windows, conventions, eligibility, labels and report pass; Linux and specialized jobs are skipped

Negative control

No dedicated control for the zero-color-attachment input is reported. The author-reported base/head run is a regression sweep, not a targeted assertion for that input. I did not run a local control.

Findings

Blocking

None. The guard is limited to the zero-count case and avoids constructing the color-sample range from a null pointer; nonzero counts preserve the previous behavior.

Non-blocking

A focused zero-color-attachment regression would strengthen coverage. The current PR changes only the implementation file, so the exact null-pointer case is not directly asserted by a new test.

Sources

• Implementation at the reviewed head
• Author's exact-head GPU and validation report
• Current contribution rules

Not verified

I did not independently run the GPU tests, validation layer, or a title. The test results above are author-reported. The unrelated agc_driver_pipeline_journal environment failure remains visible on both baseline and candidate.

[MarcZX10]

Source correction — test report link

The exact-head test report citation in my review should point to the author's 2026-10-29 06:26 UTC update, not the earlier comment ID. The verified link is the updated base/head GPU and validation report. The review outcome and stated findings are unchanged.

[blawesom]

Static review plus an independent Linux/AMD run on both trees per the repo AGENTS AGC protocol (CachyOS, kernel 7.2.10, GCC 16.2.1, Ninja 1.13.2, Release, BUILD_TESTING=ON, Ryzen 7 9800X3D). No findings.

What I checked

• The fix guards colorAttachmentCount != 0 before copying pColorAttachmentSamples into the sample-count vector. Without it, a depth-only linked pipeline (VkAttachmentSampleCountInfoNV with colorAttachmentCount = 0 and a null pColorAttachmentSamples, which Vulkan permits) reaches std::vector(ptr, ptr + 0) — null-pointer arithmetic, undefined behaviour regardless of the empty range. The guard is minimal and the empty colors vector keeps the map key shape (pair<vector, VkSampleCountFlagBits>) intact downstream.
• The remaining hunk relocates the key construction with std::move(colors) — no semantic change beyond avoiding a copy.

Paired AGENTS-protocol run (VVL env)

Fixtures exercising the pipeline-library link path (agc_pipeline_journal, agc_driver_pipeline_journal, agc_driver_pipeline_optimized_readback_* five variants, agc_driver_draw_cache_reuse_* family) — 16 tests total:

tree	result	VUID-	missing-layer
this head 5d1e214ce3	16/16 Passed	0	0
main bb04a4f1ea	16/16 Passed	0	0

Comparing logs, no new validation errors. Both trees show 0 was not found but was requested by env var VK_INSTANCE_LAYERS (layer found and requested on both).

Note on run history (transparency)

An earlier pass of mine reported agc_pipeline_journal SEGFAULT on this head. On a clean rebuild of agc_driver_graphics_tests at this exact head the fixture passes (and passed on main too) — the segfault was a stale test binary from a prior PR checkout in my worktree, not this change. Recorded here so nobody else chases it: if you see agc_pipeline_journal segfault locally after switching branches, rebuild agc_driver_graphics_tests first, that fixture's binary is easy to leave stale.

Not covered

The specific colorAttachmentCount = 0 link input (depth-only merged-coverage pipeline, per the PR body's remaining item) isn't pinned by a dedicated new fixture in this diff — the fix relies on the existing pipeline-link fixtures above for no-regression, and the null-vector UB is invisible in results until a debug/UB build catches it. Consistent with how this codebase treats such guard-only fixes, just noting the new condition itself has no direct assertion.

[milescoviello]

@blawesom thanks for the review and the paired run. You're right about the gap: no fixture links a depth-only merged-coverage pipeline with colorAttachmentCount 0 and a null pColorAttachmentSamples, so the existing link fixtures only show it doesn't regress. If a maintainer wants that input pinned, I'll add a fixture that links one and checks the library's sample counts come out empty.

AI-assisted: yes (Claude Code)

[TechLevelZero]

✅ NVIDIA GPU test: passed

PR head 5d1e214 merged onto main ba5b533 · tested 2026-10-29 18:42 UTC · 26 min

GPU	NVIDIA RTX 2000 Ada Generation, driver 595.99.02, Vulkan 1.4.329
Host	Ubuntu 26.04.1 LTS, kernel 7.0.0-38-generic, container ubuntu:24.04
Logs	build and test logs for this run
Build	✅ passed (Release, -DANYPS5_ENABLE_SPIRV_TOOLS=ON)
Tests	✅ 2,209 passed · 5 failed (0 new, 4 also fail on main, 1 unstable on main) · 39 skipped (ANYPS5_REQUIRE_VULKAN=1)
Test setup	CPU-only tests without a GPU; GPU tests (and any CPU-only test that failed or skipped without one) once on the GPU with VK_LAYER_KHRONOS_validation and ANYPS5_NO_SHADER_CACHE=1; main ran the same way
Test selection	2,253 of 2,891 tests run: the ones this change can reach, chosen by tools/select_tests.py from main's build graph
Vulkan validation	✅ no new validation IDs vs main (855 tests run on the GPU)
Slow tests (>30 s, GPU tests timed with validation layers)	none

Unstable on main (1, these also failed in recent main runs on this machine; not counted against this PR)

agc_driver_submit_progress: failed in 4 of the last 6 main runs

Failing on main too (4, not counted against this PR)

agc_compute_pipeline_inspection
agc_submit_progress_no_timeline
guest_mmap_executable
guest_socket_options_multicast

Validation IDs already present on main (4 IDs in 404 tests)

VUID-VkDeviceCreateInfo-pNext-pNext (404 tests): agc_compute_pipeline_replay, agc_driver, agc_driver_address_passes, agc_driver_address_passes_draw_transitions, agc_driver_address_passes_targets_split, agc_driver_alpha_to_coverage, agc_driver_array_layer_target_cpu, agc_driver_bc_block_copy, and 396 more
VUID-vkCmdCopyImage-srcImage-01548 (11 tests): agc_driver_depth_clear_hle, agc_driver_depth_plane_buffer_memory, agc_driver_depth_plane_cpu_write_after_memo, agc_driver_depth_plane_cpu_write_after_page_unwatch, agc_driver_depth_plane_cpu_write_after_partial_unwatch, agc_driver_depth_plane_partial_store, agc_driver_depth_plane_partial_store_unimported, agc_driver_depth_storage_dispatch, and 3 more
VUID-vkCmdCopyImage-srcImage-01551 (11 tests): agc_driver_depth_clear_hle, agc_driver_depth_plane_buffer_memory, agc_driver_depth_plane_cpu_write_after_memo, agc_driver_depth_plane_cpu_write_after_page_unwatch, agc_driver_depth_plane_cpu_write_after_partial_unwatch, agc_driver_depth_plane_partial_store, agc_driver_depth_plane_partial_store_unimported, agc_driver_depth_storage_dispatch, and 3 more
VUID-VkPipelineColorBlendStateCreateInfo-pAttachments-00605 (2 tests): agc_driver_prepared_exports, agc_driver_srgb8_color_target

Skipped (39)

agc_driver_bda_reads_shadowed_results: skipped, the device reports watched host memory written when it imports or reads it
agc_driver_bda_reads_shadowed_results_per_build: skipped, the device reports watched host memory written when it imports or reads it
agc_driver_msaa_dcc_compared_import_2: skipped, the device reports host imports that keep write protection, so the write-watch probe compares none of them
agc_driver_msaa_dcc_compared_import_4: skipped, the device reports host imports that keep write protection, so the write-watch probe compares none of them
agc_driver_msaa_dcc_compared_import_8: skipped, the device reports host imports that keep write protection, so the write-watch probe compares none of them
agc_driver_sample_order_grid_reference: skipped, the device does not keep depth drawn at custom sample locations at those locations, even after a transition that names them: the composite of uniform renders holds the guest's depth in 0 of 3005 sloped samples, so no path can be compared with it bit for bit
agc_driver_sparse_dma_buf_import: skipped, host imports are unavailable: /dev/udmabuf is not accessible
agc_driver_stencil_ref_export: skipped, the device lacks VK_EXT_shader_stencil_export
agc_host_import_sparse: skipped, host imports are unavailable: /dev/udmabuf is not accessible
agc_import_settle_initial_dcc: skipped, the device has no deferred settle of host imports: imports under 1 MiB wait for one only on Windows
agc_unit_shadow_completion_store: skipped, the device reports watched host memory written when it imports or reads it
guest_net_ctl: skipped, the host has no IPv4 address
guest_video_out_color_space: skipped, no display or Vulkan device: SDL_InitSubSystem(VIDEO | GAMECONTROLLER) failed: wayland,x11 not available
guest_video_out_hdr: skipped, no display or Vulkan device: SDL_InitSubSystem(VIDEO | GAMECONTROLLER) failed: wayland,x11 not available
guest_video_out_high_frame_rate: skipped, no display or Vulkan device: SDL_InitSubSystem(VIDEO | GAMECONTROLLER) failed: wayland,x11 not available
guest_video_out_output_mode: skipped, no display or Vulkan device: SDL_InitSubSystem(VIDEO | GAMECONTROLLER) failed: wayland,x11 not available
guest_video_out_resolution_status: skipped, no display or Vulkan device: SDL_InitSubSystem(VIDEO | GAMECONTROLLER) failed: wayland,x11 not available
guest_video_out_wqhd_detection: skipped, no display or Vulkan device: SDL_InitSubSystem(VIDEO | GAMECONTROLLER) failed: wayland,x11 not available
video_out_flip_controls: skipped, no display or Vulkan device: DisplayWindow: Vulkan support is either not configured in SDL or not available in current SDL video driver (offscreen) or platform
video_out_flip_cpuflip: skipped, no display or Vulkan device: DisplayWindow: Vulkan support is either not configured in SDL or not available in current SDL video driver (offscreen) or platform
video_out_flip_cpuflip_in_order: skipped, no display or Vulkan device: DisplayWindow: Vulkan support is either not configured in SDL or not available in current SDL video driver (offscreen) or platform
video_out_flip_eop: skipped, no display or Vulkan device: DisplayWindow: Vulkan support is either not configured in SDL or not available in current SDL video driver (offscreen) or platform
video_out_flip_eop_aftergpu: skipped, no display or Vulkan device: DisplayWindow: Vulkan support is either not configured in SDL or not available in current SDL video driver (offscreen) or platform
video_out_flip_eop_main: skipped, no display or Vulkan device: DisplayWindow: Vulkan support is either not configured in SDL or not available in current SDL video driver (offscreen) or platform
video_out_flip_fresh: skipped, no display or Vulkan device: DisplayWindow: Vulkan support is either not configured in SDL or not available in current SDL video driver (offscreen) or platform
video_out_flip_labels: skipped, no display or Vulkan device: DisplayWindow: Vulkan support is either not configured in SDL or not available in current SD

Reproduce

git fetch origin 5d1e214ce3de525b07e5328cb87993fc91d46439 ba5b5330b37724bca4b99f30faab504653635a04
git checkout ba5b5330b37724bca4b99f30faab504653635a04 && git merge --no-ff 5d1e214ce3de525b07e5328cb87993fc91d46439
git submodule update --init --recursive
cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=ON -DANYPS5_ENABLE_SPIRV_TOOLS=ON
cmake --build build && cmake --build build --target libs
VK_DRIVER_FILES=/nonexistent/icd.json ctest --test-dir build -E '^(agc|shader|recompiler|videoout|video_out|guest_video_out|vulkan)|gpu' --timeout 120 --parallel 32 --output-on-failure
ANYPS5_REQUIRE_VULKAN=1 ANYPS5_NO_SHADER_CACHE=1 VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation \
  ctest --test-dir build -R '^(agc|shader|recompiler|videoout|video_out|guest_video_out|vulkan)|gpu' --timeout 120 --parallel 4 --output-on-failure
# failures are then re-run alone: --timeout 360 --parallel 2; new validation IDs: the test alone, twice, --parallel 1

_{Automated build and test on a contributor's NVIDIA machine; it does not replace upstream CI. A new comment is posted for each new push. Full logs.}