At Facebook Connect we teased various improvements to the Quest Platform, including support for 90Hz applications on Quest 2—both natively and through Oculus Link. We’re excited to start rolling out those features with today’s
v23 software update, which also coincides with Oculus Link exiting beta and the upcoming releases of Oculus Move and App Gifting.
90Hz on Quest 2
Developers can now start shipping Quest titles with native 90Hz support, and Quest 2 system software including Home, Guardian, and Passthrough will run at 90Hz.
Although 72Hz is still the default for applications on both Quest and Quest 2, 80Hz and 90Hz refresh rates are now available as an opt-in to developers on Quest 2. It’s important to note that while apps can now request a higher frame rate, rates above 72Hz are not guaranteed: in rare cases, the system may decide to throttle the display refresh rate down. Our system may lower the frame rate in response to a severe thermal event (VrDriver will force the application to minVsyncs=2, effectively 36Hz rendering, although the screen still runs at 72). Though these sorts of events are very rare, they can be visually jarring for some users. For 90Hz rendering, the system will first drop to 72Hz before dropping down to half-rate if confronted with unusual thermal pressure.
90Hz and 80Hz rendering are only supported on Quest 2. Applications that request 90Hz will run at 72Hz when executing on an original Quest device.
How to Use and Test Your App for 90Hz
Once the application manifest has been updated, the usual VRAPI and engine-integrations APIs can be used to request the supported refresh rates and set the display frequency to 90. Here’s the documentation for changing the display frequency in Unreal and Unity:
With the v23 update, the VrDriver logcat telemetry every second will show you the current system refresh rate. The following example shows that the system is running at 90Hz, and the application running at 89FPS:
VrApi : FPS=89/90,Prd=34ms,Tear=0,Early=8
If the system decides to throttle your refresh rate for any reason, you will receive an event warning you of that change. The vast majority of developers will not need to do anything based on that event, but on VRAPI for example, a new event was created:
// Event structure for VRAPI_EVENT_DISPLAY_REFRESH_RATE_CHANGE
typedef struct ovrEventDisplayRefreshRateChange_ {
ovrEventHeader EventHeader;
float fromDisplayRefreshRate;
float toDisplayRefreshRate;
} ovrEventDisplayRefreshRateChange;
The next release of engine integrations on Unreal Engine and Unity will integrate ways for developers to easily handle that event as well.
Lastly, in order to test a runtime-driven refresh rate change, we added a broadcast intent in VrDriver that will simulate the compositor going from 90 to 72. In an ADB shell, calling
am broadcast -a com.oculus.vrruntimeservice.COMPOSITOR_SIMULATE_THERMAL --es subsystem refresh --ei seconds_throttled 10
will throttle the screen from 90 to 72 for 10 seconds and send the appropriate events. For example, calling it on VrShell will show in the VRAPI logcats:
VrApi : FPS=90/90,Prd=33ms,Tear=0,Early=0...
VrApi : FPS=87/72,Prd=33ms,Tear=0,Early=0...
VrApi : FPS=72/72,Prd=36ms,Tear=0,Early=0…
With this change, developers are free to build apps that run at 90Hz. We’re excited to see what you come up with!