120HZ option is needed for proper displaying of 60FPS games. about citravr HOT 7 OPEN

@alucard0712rus may I ask how to force 120Hz through adb? THX\

adb shell setprop debug.oculus.refreshRate 120

:-)

from citravr.

You don't even need to test it. Any time you consume content at a refresh rate that's not some integer multiple of the framerate the content is mastered in, will exhibit visible stuttering, especially during high speed panning.

Carmack wrote this:

It's the same reason Apple Vision Pro supports 96 Hz (and automatically switches to it) when consuming 24 FPS content (it's called 4:4 pulldown. 24 at 60 Hz would be called 3:2 pulldown, which is a well-known animation artifact and well-studied):

120 Hz TVs also became the norm due to watching 24p movies in 5:5 pulldown. (repeating each frame 5 times). 120 Hz refresh rate HMDs are thus ideal for all kinds of commonly mastered framerates: 24, 30, 60, repeating frames 5 times, 4 times, or twice in the case of 60. This is just a consequence of 120 being the least common multiple of all three of those. AVP also supports 100 Hz for 50 Hz PAL content in Europe, displaying it at 2:2. It's too bad AVP doesn't support 120, and nor to many upcoming OLED HMDs, sadly, which are mostly limited to 90 Hz at the display level.

There's nothing that needs to be repro'ed, it's fundamental, your refresh rate has to match exactly, ideally, or at the very least use some integer multiple of the input framerate, for animation to appear smooth. When I worked at Felix and Paul, for instance, all the VR video content was mastered at 60 FPS, and played back perfectly on GearVR which ran at 60 Hz (though with visible flickering), while Rift at 90 Hz (which I was responsible for porting it to) was noticeably choppy. This is a fundamental problem that can only be fixed by a) changing the mastered content to be congruent modulo your refresh rate, or b) using interpolation.

But even repeating frames twice will show, on low-persistence displays, a double image due to strobing the same frame twice while your brain expects the content to have moved since the last frame. You can see this easily on UFO motion blur test, if you look at the 60 FPS line on a 120 Hz monitor with ULMB (strobing, similar to VR headsets) you'll see images that are sharp but clearly doubled. This is why we really want 60 FPS at 120 Hz, then later, using frame extrapolation to double the game's framerate to 120 FPS, since hacking the actual game logic to run at 120 FPS natively appears to be a challenge, and difficult for performance, too. To use the frame extrapolation function above on XR2 chips may require lowering the render res, especially on Quest 2. Quest 3 might be fine with 720p ish res per eye.

from citravr.

What specifically are you noticing? Is it a single-frame stutter, and is it video-only?

I'd be very interested in knowing whether running CitraVR at 120Hz had a pronounced effect on audio or video stuttering, as well as anything else you noticed comparing the refresh rates. Quest has a weird display/software-vsync, so there's tons of explanations for why that would be, and it would be a fantastic (brilliant) insight.

One challenge I have with this argument as it's laid out is that, as of right now, the emulation render loop and the VR frame loop run async to one another. So there isn't frame pacing regardless: without VR frame timing threaded through the entire pipeline, the same artifacts that occur due to the refresh not being an even multiple of 60 should occur at 120Hz as well.

Note: 120Hz on Quest has visual tradeoffs for applications like this one due to its tiny compositor headroom and the fact that the VR compositor is preempting the app GPU work (kicking it off the GPU and doing a hard context switch) for a larger total percentage of each app frame. The worst-case is small-to-moderate visual artifacts, e.g., missed frames or white snow (Bigscreen Beta has examples of this). Additionally, the tiny amount of compositor headroom prevents these apps from using resolution-improvement techniques like sharpening and SuperRes. So it depends on what you care about visually.

from citravr.

@alucard0712rus may I ask how to force 120Hz through adb? THX

from citravr.

By the way, please continue looking into visual artifacts, especially the display-pipeline- and pacing-related ones. It's very appreciated!

from citravr.

+1 for 60 FPS at 120 Hz

Once 60p at 120 Hz works smoothly, the next step would be 60 FPS doubled to 120 FPS, at 120 Hz on Quest 3, using this function. If I have time, I will try it, if not, I encourage anyone else to fork this and experiment with it.

https://registry.khronos.org/OpenGL/extensions/QCOM/QCOM_frame_extrapolation.txt

from citravr.

What specifically are you noticing? Is it a single-frame stutter, and is it video-only?

Regarding frame-rates and such I've noticed 3 kinds of stutters:

1. That what I've described before (due to the refresh not being an even multiple of 60). It's continuous and constant. Video only. And it's only in games that run at correct 60FPS. 30FPS games are fine!
2. Typical shader compilation stutter that comes with audio stutter/glitching too. It's less noticeable in Vulkan backend, but the problem is every time I start the game it stutters in same places. Maybe disk-based shader cache is not working or shaders did not precompile before starting a game?
3. Some random stutters like few missed frames here and there. Not depended on anything. But it's not CitraVR alone - it's in everything with Quest 2 or 3. Video only.

'Same artifacts that occur due to the refresh not being an even multiple of 60 should occur at 120Hz as well'

I cannot say that I understand your sentence properly but 60FPS games in 120HZ mode looks way smother ('as they should') and I no longer see that 90/60 uneven frame pattern as before.

Hope it helps! Please ask freely if you wan't any feedback on this!

from citravr.