mirror of
https://github.com/bearstonem/openmohaa-vr.git
synced 2026-10-25 13:00:25 +01:00
bearstonemandClaude Opus 5
214933c5fe
vr_resolutionScale has been at 0.6 since the days when a frame cost 50-60 ms per
eye, which meant the headset was being given 1008x1056 against a native
1680x1760 - 36% of the pixels it has.
The measurement that justified it has since answered the opposite question.
Rendering at 36% of the pixels bought only 23% of the frame time back, which is
what proved the cost was never fill rate: it was CPU in rend2's back end binding
a GLSL program per surface per eye. Swapping to renderergl1 on gl4es took the eye
from 50-60 ms to 4-6, and nothing has claimed that budget since.
So it goes back to 1. The cvar stays rather than being deleted - it is still the
first question worth asking of any frame time regression, and it is the cheapest
thing to trade if a later feature wants budget it has not got.
Measured on the device afterwards, in the Bocage:
standing at spawn 90.0 fps eyes 8-9 ms
moving in the level 77-85 fps eyes 11-12 ms, most frames over the 11 ms period
So this does not hold 90 Hz while moving and the compositor is reprojecting a
good share of frames. Kept anyway, on the judgement of how it actually plays -
the picture is much sharper and the reprojection is not felt. The number is
recorded here so the trade is a known one rather than a surprise to whoever reads
the frame times next.
Two things follow. There is now no headroom for MSAA. And the frame split cannot
be taken at face value: it reports world 1 ms against hud 5 ms, which is the
Set2DWindow flush attributing the world's deferred draw calls to the first 2D
call that forces them out - the trap in QUEST_PORTING_GUIDE.md section 7.1. The
one figure that is trustworthy is gpuwait, still 3 ms, so the GPU remains idle
and whatever the 11 ms is, it is CPU side.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>