mirror of
https://github.com/MobileGL-Dev/MobileGL
synced 2026-11-07 01:53:24 +09:00
swung0x48
45664725f8
Section 11's matrix ran at VD12, where BOTH monolith and run-ahead hit the 120 Hz panel ceiling - so that section answers "can it reach the ceiling", not "which is faster". At render distance 32 the load rises to ~3550 draws/frame (4.2x) and neither arm is near any cap (the game's own enableVsync:false / maxFps:260, and the measured max is only 37-71). That is the comparable round. - Five runs per arm, interleaved, CPU clocks pinned (checked before AND after, both PINNED), GPU held at pwrlevel 0, fan on; 75-150 s in-world settle before a 40 s window - VD32's chunk streaming runs far longer than VD12's and reusing the 20 s settle would have counted loading as steady state. - monolith p50 median 58.5 (range 56.3-67.9), inproc run-ahead p50 median 59.9 (range 56.8-61.1), client CPU 16.19 vs 15.72 ms/frame. Level, run-ahead marginally ahead, and with half monolith's spread. - Against the lockstep it replaces: p50 +69%, client CPU -40%, apply CPU -43%. The heavier the load the more it is worth, which is what the mechanism predicts: rendezvous count follows draw count, ~900 per frame at VD12 and ~3600 at VD32. - Both arms are client-thread saturated (~94%), so the client ms/frame column is each arm's real bottleneck and the two are directly comparable. New section 11.1 records an OPPORTUNITY rather than a defect: apply spends 11-12 ms against the client's 15.7 ms, so the two sides are unbalanced and moving work from client to apply lowers the bottleneck directly. Under lockstep that was meaningless (the two sides add serially); run-ahead is what turns it into a lever. Left to a later phase. options.txt restored from .p5e-backup to renderDistance:12; the device is unpinned, fan off, GPU back to governed.