The graphics pipeline store kept a fixed 1024 entries and the pipeline journal replayed at most
1024 records, and a replayed pipeline that found the store full was dropped. A title whose
working set is larger rebuilt the rest at the draw on every run, and evicted pipelines it kept
using were rebuilt again and again.
The bound now starts at 1024 and doubles up to 4096: a journal replay that does not fit grows it
instead of dropping the pipeline, and so does eviction churn (a ghost list of evicted keys, checked
every bound/32 evictions: more than half of them came back). It never shrinks during a run;
APS5_PIPELINE_STORE_ENTRIES still fixes it. The journal loads its last 4096 records by default
(APS5_PIPELINE_JOURNAL_ENTRIES). Resident pipelines are bounded by count, not bytes.
agc_driver_recorder_tests --benchmark-pipeline-store-memory [count] (opt-in, not registered)
builds count graphics pipelines with one fragment module each through CachedPipeline and prints
process private bytes and VK_EXT_memory_budget heap usage before and after: with the triangle
shaders about 59 KiB host and no device memory per pipeline on an RTX 4090, 100 KiB host and
8 KiB device-local on a UHD 770.
Tests: agc_pipeline_store_growth (fails on main), agc_pipeline_store_fixed_bound,
agc_pipeline_store_replay_growth (replays on one thread: the mock Vulkan is not thread-safe).
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_017SNUYRd7sRKZrMYpquAsnU
sceUsbdGetDevice, sceUsbdGetDeviceSpeed, sceUsbdGetMaxPacketSize,
sceUsbdGetMaxIsoPacketSize, sceUsbdOpenDeviceWithVidPid,
sceUsbdSetInterfaceAltSetting, sceUsbdClearHalt and
sceUsbdDetachKernelDriver follow FreeBSD 11.4 libusb10.c over the host
libusb. The packet sizes and the alternate setting checks are done as
FreeBSD does them, so the library records which interfaces are claimed,
and a device stays known while a handle to it is open.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Accept valid special handles in scePadGetControllerType by using KnownHandle, reporting PAD_CONTROLLER_TYPE_UNKNOWN (0) for special handles with no physical controller behind them.
The printf family formatted floating-point conversions through the host,
which prints every exact digit and rounds ties to even. The libc.prx
that titles ship keeps the exact digits only down to a position derived
from the binary exponent and prints zeros after them, rounds half up on
the kept digits, and rounds an exact tie down once that exponent
estimate reaches 8. So %.0f of 2.5 is 3 and %.1f of 0.25 is 0.3 there,
and %.20f of 0.1 is 0.10000000000000000555.
Format finite double and long double e, f and g conversions with those
rules from exactly generated digits, on every host. On 600,000 random
formats every output with up to 17 significant digits now matches the
copies bundled with PPSA07923, PPSA05916 and PPSA13934; longer outputs
still differ where the console's extended-precision digits end one unit
lower.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The libc debt entry for %a and %A still described the Windows-only
formatter and said Linux hands %a to glibc; since Linux routes %a and %A
to the same formatter, describe it for both platforms.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The Windows printf family handed %a and %A to the host, whose UCRT prints
a subnormal unnormalised (0x0.0000000000001p-1022) and pads with zeros
even when the - flag is given (%-010a of 1.5 gave 0x001.8p+0). The
libc.prx that titles ship normalises subnormals (0x1p-1074), rounds a
shorter precision half up without renormalising a carry, and lets -
override 0, as C requires.
Finite doubles are now formatted here, checked against three titles'
copies of libc.prx run side by side.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Felipebmaitan