Thank you for the reply,
Oh it’s most certainly a CPU bottleneck in most cases: In unity’s 2019.4.31f1 built-in renderer, dx11, I wish some more threading on material setups before being sent to the gpu or offloaded. I guess it’s conventionally understood by most that dx11 is somewhat limited in the render threads it can run, but perhaps I don’t understand it deeply enough.
You mentioned:
Are you referring to this to get the gaze directions as they are queried by the application?
Yes, and I actually didn’t know it’s treated the same as 2d in the driver: that’s great info.
Is that also the case for for fixed foveated rendering and VRSS? Are there cases where it would stop working/give up?
I’ll spend a little more time in NSight for sure. That being said, you mentioned:
To test this hypothesis I’d suggest to lower the resolution and see if the framerate stays unreasonably low. If so, it hints at a CPU bottleneck.
That’s absolutely true, but here’s where it gets unusual. Even lowering the resolution to 1600x1900 @144fps, and CPU limiting the render rate to reduce cpu load still yields situations where if there’s 60-80 players in an environment even with a 12900kf, you will get around 45-60fps if you’re very lucky with a steep overclock on windows 11. This is with motion smoothing and reprojection turned off.
However, (and I suppose this forms the meat of my inquiry) quite strangely, if I open SteamVR Dashboard, the system immediately jumps to full frames: in a very unusual, almost “buggy” way that doesn’t happen when manually setting the resolution even excessively low, to something like like 800px before launching, which would usually “mimic” the “half resolution” step the dashboard does to the running, not paused application in the background.
This does not seem to be related to a specific headset intermediary runtime either, as the same thing occurs when using steamvr or oculus’s OVR runtime and dropping to dash.
On the other hand, on a 144hz 1440p+ monitor in desktop mode on the same hardware, the game will run unconstrained at or above 144fps no problem in the same situation: I know this because I’ve pulled my cable while playing, and the game launched again to the same situation on 2d.
Unfortunately, few to no applications are like or as advanced as VRChat is with Unity. This is further extended with everyday users creating new and custom shaders every day, custom render textures, some using grab passes, and interacting with each other on the fly with environment dynamics and post processing so advanced they previously only existed in siggraph papers.
It’s incredibly hard to simulate this situation outside of the live environment, and moving to something like HDRP or URP as far as I know isn’t an option for them due to the legacy content involved.
It’s a very weird and specific ask, I know, and I deeply appreciate the insight thusfar.
For context, I work as a VR content and marketing developer that often partners with VRChat for our events, and we use assets from multiple studios that they’re bringing to us to promote, like for example the game models from Neir and Guilty Gear, or the high resolution assets from Netflix’s Ghost in the Shell:SAC.
We would love to squeeze a few more frames in VR, and after 2 years of A-B testing our own builds and software in and outside of VRChat, I personally think this seems to be a “VR hardware specific miss” that we just can’t figure out. Basically we run into the same issues with many materials as they do. I work in the optimization side too, and we do some over the top things like getting under 50 or less set pass calls and use a single texture, and in unity editor in run mode hitting over 4000 frames, but in the final app, in VR, once you get over 50 materials of any type in read/write it gets a little weird and chunky.