Repository navigation
perf(agc): read DCC keys from the pending GPU fills that cover them instead of waiting for the fills - #5520
Conversation
MarcZX10
left a comment
MarcZX10
left a comment
There was a problem hiding this comment.
Reviewed the newest-write range overlay and its fallback: later writes shadow earlier ranges, unknown stores fall back to synchronization when the pending values cannot be established, and inaccessible ranges do not get read speculatively. The added cases cover partial fills, mixed values, unknown writers and shadowed keys. The report provides Windows RX 7900 XTX test evidence; the current automated eligibility, conventions, intake and report checks pass, while Linux/full-build jobs are skipped and Linux was not run. I found no code-level blocker based on the submitted evidence.
…nstead of waiting for the fills
…wer the keys without a GPU wait
|
Rebased onto current |
2a95722 to
838c1ca
Compare
…ded before it A title's DCC key clear is a recorded fill of a known value over the keys. The key store queued behind it saw a pending writer it did not know and fell back to the plain fill, which was a third of the stores in PPSA15304 after boykopovar#5520 and brought the descriptor faults back. The snapshot now predicts the import: the bytes read at queue time with every pending fill of a known value applied in note order, so the kernel stores the 0xff pattern over the clear's bytes and still keeps a CPU store made after the record. APS5_TRACE_KEY_GUARD=1 prints the pending writers of the stores that stay unguarded. The test records a key clear before the store and expects the keys stored, then a late CPU store kept. (cherry picked from commit 3da4934731c9231976f395b8f517bd2b03578968)
…ded before it A title's DCC key clear is a recorded fill of a known value over the keys. The key store queued behind it saw a pending writer it did not know and fell back to the plain fill, which was a third of the stores in PPSA15304 after boykopovar#5520 and brought the descriptor faults back. The snapshot now predicts the import: the bytes read at queue time with every pending fill of a known value applied in note order, so the kernel stores the 0xff pattern over the clear's bytes and still keeps a CPU store made after the record. APS5_TRACE_KEY_GUARD=1 prints the pending writers of the stores that stay unguarded. The test records a key clear before the store and expects the keys stored, then a late CPU store kept. (cherry picked from commit 3da4934731c9231976f395b8f517bd2b03578968)
3 participants
What
A DCC key read that finds recorded GPU writes over the keys waits for the GPU unless the key-store memo holds one entry covering all of them. Keys filled in parts, a fill over part of the keys whose other part already holds the same byte, fills the fill HLE did not take as key fills, and keys under a unit shadow all wait, although the recorded fills already say what the keys will be. This change answers those reads from the recorded writes. In Ready or Not on
mainthe GPU waits for DCC keys drop from 16.9 to 8.5 ms per frame, but the FPS doesn't move, because a buffer copy that #5372 fixes takes most of each frame there. On my Ready or Not bring-up build, an older base with other local changes, the slow color-target lookups went from 28.7 to 3.9 ms per frame over three steps, two of them this change's commits (table below).main. Writes are ordered by when they were recorded, as the memo already assumes.Tested
Windows 11 Pro 10.0.22631, Ryzen 7 7800X3D, RX 7900 XTX, WinLibs GCC 15.2.0, Release, on
main0aa4cb1.pendingKeyStoreTestsgets its own ctest,agc_pending_key_stores, with new cases for fills over both halves of the keys, a later writer of unknown bytes, a fill over half of uncompressed keys, and keys that run past the end of committed memory.agc_driver_dcc_keys_first_writenow expects no wait where real GPU fills settle a storage image's keys, still expects one where a kernel's store is the newest writer, and checks the landed key bytes after each read.shadowedKeyStoreTestsintests/Recorder.cpp(ctestagc_shadowed_key_stores): keys under a fresh unit shadow are published and read after a wait, a fill over a stale unit shadow answers without a wait, and the stale slab is never published.ctest -R "^agc_": 482 of 485 pass and 2 skip.agc_driver_layered_volume_vertex_no_gplfails, as it does onmainon this GPU.main0aa4cb1, all libraries built from it and only the driver swapped, same scene, one run each, 30 s profiler windows. In this scenemaincopies a 768 KiB buffer on most draws (the case perf(agc-driver): join every range a bound buffer crosses #5372 fixes), so a frame takes about 500 ms of queue-0 time and the FPS does not move:The frames match within the difference between two runs of the same build. With this change a texture whose pending fills leave mixed keys logs the existing "has mixed DCC keys ... read as stored" line;
mainreads it as stored too, without the line.Linux: not run.
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)