perf(agc): the draw committer polls briefly for the next draw before it sleeps

[Raghav314]

What

With pipelined draws (on by default, depth 8), the committer thread sleeps on the condition variable whenever the queue is empty. In a draw-heavy frame the worker hands over a draw every few microseconds, so the committer goes to sleep after almost every commit and the worker pays a wake for the next one.

• APS5_PIPELINE_SPIN_US=<us> makes the committer poll the queue count for up to that long before it sleeps (_mm_pause between polls, the clock read every 64 polls, as the queue-0 memory wait does).
• The default is 0: the committer sleeps at once, as on main. On a 4-core host the poll gave no fps and a worse p99 (below), so it stays opt-in.

PPSA36082

Level UI/menu standing still, APS5_HOST_IMPORT_MIB=6784, one build with the poll switched off and on (50 us) every 15 s in one sitting, 4 windows each, MangoHud fps per window (first 2 s of each window left out):

	windows (fps)	mean fps	p99 frame time
8 cores, off	52.7, 53.0, 53.3, 53.7	53.2	24.1 ms
8 cores, on	55.9, 53.6, 54.2, 55.4	54.8	23.6 ms

On 8 cores the poll won every pair, by about 3%.

On 4 cores (taskset -c 0-3), same procedure: 49.4 fps off, 49.5 on; frame time p99 26.8 ms off, 31.4 ms on. So the default stays 0, and a host with cores to spare can set it.

Tested

Linux (CachyOS), x86-64, GCC, 7800X3D / RTX 4090, NVIDIA 615.78.08, on main f474fb7.

• The linux job of current build.yml run locally: configure with SPIRV tools on, test registration check, build, libs, ctest 1299, all pass except agc_driver_store_over_untracked, which fails the same way on main.
• With APS5_PIPELINE_SPIN_US=50, the agc_* suite passes except agc_driver_store_over_untracked, as on main.

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
• Unblocks: none
• GPUs tested: NVIDIA GeForce RTX 4090, 615.78.08, Linux 7.2.10 (CachyOS)
• AI-assisted: yes

[CnRJay]

Polling briefly before sleeping is a reasonable trade for a hand-off every few microseconds. Two things to check before 50 µs becomes the default:

• Core count. A 7800X3D has 8 cores and 16 threads to spare. On a 4-core / 8-thread host, or a laptop under a power limit, a committer that spins whenever the queue drains takes a core from the title's own threads and can lower the clock the worker runs at. That can cost more than the wake it saves. A run with the process limited to 4 cores (taskset -c 0-3, or the equivalent affinity on Windows) for both builds would show whether the gain survives.
• Noise. As the description says, one run each with whole-frame changes inside run-to-run noise leaves draw_enqueued (2.0 → 1.5 ms) as the only signal. Two or three alternated runs per build would make the frame-time line usable as well.

Since this only applies with the opt-in APS5_PIPELINED_DRAWS, defaulting the spin to 0 until those numbers are in would keep the mode's behaviour unchanged for anyone already using it.

[github-actions]

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.

Pull request	Conflicting files (lines on main)	Same exports	Same new files
PR 6632	core/libs/prx/libSceAgcDriver/Execution/src/Driver/Draw/DrawPipeline.cpp L121
PR 6641	core/libs/prx/libSceAgcDriver/Execution/src/Driver/Draw/DrawPipeline.cpp L16

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 1896	core/libs/prx/libSceAgcDriver/Execution/src/Driver/Draw/DrawPipeline.cpp
PR 6188	core/libs/prx/libSceAgcDriver/Execution/src/Driver/Draw/DrawPipeline.cpp
PR 6208	core/libs/prx/libSceAgcDriver/Execution/src/Driver/Draw/DrawPipeline.cpp
PR 6538	core/libs/prx/libSceAgcDriver/Execution/src/Driver/Draw/DrawPipeline.cpp

[Raghav314]

Rebased onto main f474fb7 (only the poll commit is left; the rest is in main). The default is now 0, so the committer behaves as on main unless APS5_PIPELINE_SPIN_US is set.

Both checks, level UI/menu, one build switching the poll off and on (50 us) every 15 s, 4 windows each:

• 8 cores: 53.2 fps off, 54.8 on; the poll won all 4 pairs. p99 frame time 24.1 to 23.6 ms.
• 4 cores (taskset -c 0-3): 49.4 off, 49.5 on, and p99 26.8 to 31.4 ms. As you expected, it does not hold on 4 cores.

LLM assistance used.

[adriadam10]

Checked the diff, built it merged onto current main and ran the AgcDriver ctest scope: green except agc_driver_tessellation (segfault, same on main on RADV here). With the default 0 the committer behaves exactly as on main; the 4-core measurement you added settles the earlier question.

• Overlap with #6632: it also makes the draw committer spin before it sleeps (APS5_HANDOFF_SPIN_US, window picked from the usable core count, plus a agc_handoff_spin test) and edits the same part of DrawPipeline::run / DrawPipeline.cpp. Only one of the two can land. Please agree with its author on which approach stays (yours is opt-in and 20 lines; theirs sizes the window by core count and covers the GPU mutex too) and list the other in Depends on or drop the overlapping part.
• Docs: the other APS5_* switches of the driver are described in docs/user/USAGE.md; if this one stays, add APS5_PIPELINE_SPIN_US (unit, default 0, 4-core caveat) there.

[Raghav314]

Closing this in favour of #6632, which spins in the same place in DrawPipeline::run and also before the GPU mutex and in DrawPipeline::Drain, with a window picked from the usable core count and its own test. The measurements here back that policy (8 cores: +3%, 4 cores: no gain and a worse p99), so I posted them on #6632 instead.

Thanks @CnRJay and @adriadam10 for the reviews.

LLM assistance used.