mirror of
https://github.com/boykopovar/AnyPS5.git
synced 2026-11-05 13:20:11 +00:00
Dean Galvin
23d67b59a7
PPSA21564 clears each occlusion query slot with a 256-byte WRITE_DATA before its begin dump, about 8,400 times per frame in one level. The clear is larger than a deferred label, so it is recorded at once, and Recorder::NoteLabel entered all 64 of its dwords in the pending-label table: 64 map inserts, 64 batch dword entries and 64 group entries, then 64 lookups in CloseLabelGroup and 64 erases when the batch is reaped. A replay of that pattern (21 clears per batch, 20 batches in flight) costs 1.6 us for the inserts, 0.7 us for the close and 1.3 us for the erases per clear, about 31 ms of the graphics worker per frame there. The new path costs 0.07 us per clear in the same replay. The table serves WAIT_REG_MEM values and CPU pollers, which read 4 or 8 bytes. A store larger than 64 bytes (the bound the driver's own label history already uses) now enters one range instead of its dwords: - table entries inside the range are removed, as the store replaced them before: a lookup there finds no value and falls back to the pending-write path, where it used to find the store's value; - the range leaves with its batch, like the dword entries; - PendingLabelIn sees the range, and the write-evidence check, which syncs a capture read over any pending label dword, now also syncs over a pending range (Recorder::WideLabelIn). The store is still a pending write of the open batch (the flush hook syncs CPU readers), still starts the label flush deadline and is recorded exactly as before. Stores of 64 bytes or less are unchanged. Test: agc_driver_recorder_tests largeLabelTests (a 256-byte label enters no dwords and removes the older entry under it but not one beside it, its range, pending write and deadline, a later 4-byte label over it, a 64-byte label entered in full, everything gone after the batch).