Repository navigation
fix(agc): stop optional compute captures at their bounds - #6259
Conversation
jotitadev
left a comment
jotitadev
left a comment
There was a problem hiding this comment.
macOS run of the capture tests, plus one macOS-specific case the optional path still turns into a fatal error.
Machine: Apple M2 Max, macOS 27.2, Apple clang (Xcode 27), libc++. Head 870952f2c, base main 8856f180c. main does not build fully on macOS, so I compiled agc_compute_pipeline_capture_tests the way its CMake target does (tests/ComputePipelineCapture.cpp + Execution/src/ComputePipelineCapture.cpp, -std=c++20 -O2, Vulkan headers from the SDK) as a standalone binary, natively on arm64 and as x86_64 under Rosetta.
- All five modes pass on both architectures: default (0.29 s arm64 / 0.60 s x86_64),
--optional-entry-cap,--optional-byte-cap(0.70 s / 0.77 s),--optional-io(cannot create capture directory: Not a directory),--optional-invalid. - The PR's test does not compile against the base writer (
WriteOptional/OptionalEnabledare new), as expected.
Finder writes a .DS_Store file into folders it opens. The directory scan only accepts subdirectories, so that file hits capture directory contains an unexpected entry, which is a CaptureError, not a limit or I/O failure. WriteOptional rethrows it, and the next distinct compute pipeline creation fails. Reproduced on this head: one WriteOptional, then an empty .DS_Store in the capture directory, then WriteOptional with a different specialization value throws compute pipeline capture: capture directory contains an unexpected entry. The check is the same on main, so this is not a regression, but on macOS just looking at APS5_DUMP_COMPUTE_PIPELINES in Finder during a run is enough to make the next pipeline creation fail. Skipping entries whose name starts with . in the scan, or treating an unexpected entry as an optional stop, would avoid it. Your call whether that fits this PR or a follow-up.
Written with AI assistance (Claude Code). I ran the builds and tests above on my machine.
870952f to
6655644
Compare
|
@jotitadev thanks for the macOS run. I rebased onto On I've also added current-head RTX 3060 results to the description. All seven AI-assisted: yes |
|
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.
|
|
Thanks, that makes sense. Re-ran I'll take the Written with AI assistance (Claude Code). I ran the builds and tests above on my machine. |
|
Tested on Linux x86-64 (Release build, lavapipe / llvmpipe LLVM 20.1.2), with 6655644 merged into main 4eb91ea:
AI-assisted: yes (Claude Code) |
6655644 to
0984c30
Compare
|
We rebased this onto current main (c842491); the new head is 0984c30 (was 6655644), the same two commits with their authorship unchanged. |
Preserve strict capture validation and immutable writes while disabling optional dispatch captures after capacity or host I/O failures. Co-Authored-By: Codex <noreply@openai.com>
Keep malformed record structures outside the optional host I/O boundary. Co-Authored-By: Codex <noreply@openai.com>
0984c30 to
a437891
Compare
github-actions
Bot
added
unblocks title
4 participants
What
When
APS5_DUMP_COMPUTE_PIPELINESreaches its 128-record or 256 MiB bound, the strict writer throws inside compute pipeline creation. The optional dispatch capture now stops once with a diagnostic at either bound or a host I/O failure, and skips subsequent capture filtering and SPIR-V copies. The strictWriteAPI retains its bounds, deduplication, immutable records and diagnostics. Invalid pipeline input, damaged/incomplete records, unexpected entries and allocation failures still propagate.PPSA01342 reached the generic error
compute pipeline capture: capture directory reached 128 entriesat 1385.2 seconds in the historical external experimental integration runds-c0076. Its metadata, triage and fatal line were checked. This title observation is scoped to that experimental integration; current-main title execution has not been verified for this change.Tested
Windows Server 2025 10.0.26100, O3 CPU tests using the actual production capture writer and repository homebrew fixture:
VulkanDevice.cpppasses O3 syntax checking with the matching component headers.Current head
66556448b(rebased ontomain38d245448, patch unchanged), MinGW GCC 15.2 Release, NVIDIA GeForce RTX 3060 12 GB, driver 591.86:libSceAgcDriverbuilds. All sevenagc_compute_pipeline*CTests pass withANYPS5_REQUIRE_VULKAN=1andANYPS5_ENABLE_SPIRV_TOOLS=ON, includingagc_compute_pipeline_capture_run: 2 pipelines are captured through the dispatch path and replayed without dispatch.APS5_DUMP_COMPUTE_PIPELINESset to a directory already holding 128 entries, a directory at exactly 256 MiB, or a path below a regular file. On this head each run passes, prints oneoptional capture disabledline naming the bound or I/O error, and adds no records. Withmain's writer and dispatch gate the same three runs fail: the 128-entry and 256 MiB errors end the fixture with exit 1, and the I/O case raises an undeliverablefilesystem_error(exit 67). An empty directory receives the same 2 records on both.No title run or title-performance claim.
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)Co-Authored-By: Codex noreply@openai.com