They say there will be some CPU optimizations in the next update, fingers crossed, I hope they will fix this weird frametime spike issue that RR has. In my case I have to go as low as 6-7 miliseconds in frametime to (mostly) get rid of the framedrops it causes. That's around 40% of performance wasted. I'm sure That I'm not the only one with this issue. The only thing I was able to doo is to manually optimize the processes with Process Lasso so that only RR runs on 4cores, only Pimax runtime on other 4, and everything else on the E-cores. Running RR's process on 4 cores that other processes are not using at all made a noticeable difference. Hope this tip helps someone. Here is a pic of the "smoothness" after process lassoing.
I am currently looking at our VR implementation, and I have definitely noticed that the frametime spikes often seem related to our render thread migrating between cores. So it makes sense you can see improvement with core lasso/core affinity changes! I do think I’ve found some parts that can be improved to make it more consistent, so I hope we can make the experience a bit better for VR.
We need a native OpenXR support. I just installed raceroom to test with my Reverb G2 after 2 years. It is STILL completely unplayable since using SteamVR hogs so much performance out of my system. My PC specs are 5700x3d with 3080ti, which should be more than enough to run this game as it is enough in every other sim. Even cutting FOV to minimum in SteamVR does not help. It is quite sad since the driving physics and FFB were pretty impressive. Other optimizations would be welcome aswell, such as QVFR, which Iracing just implemented into their game, but i assume that you'll need to do alot of changes in to the engine first. Is there actually anybody running a WMR headset with an acceptable performance AKA. locked 90hz with preferably native res? Any tips or just imba with my specs?
Native OpenXR support won't be possible until we move to a newer graphics API, which is not happening yet. I will take a look if we can somehow make the openXR branch of opencomposite work. It has an option for dx10, which we use for our VR implementation, so there is a chance. Just no promises, as there is plenty of other stuff to work on too!
Thanks for the response! I am looking forward to being able to play this sim as it felt really nice. Unfortunately my rig is VR only so not for me at the moment. The upcoming Oasis SteamVR driver for WMR by mbucchia should make the Reverb G2 basically a native SteamVR headset, so that could change things quite significantly. We'll see.
This would be awesome news since I've been forced to abandon RR due to a VR-only switch (Quest 3). Still way up there for me in terms of driving/racing experience - not to mention tons of purchased content. SteamVR is just a mess.
opencomposite should already work for any oculus/meta headsets, you just need a special version of it. it's explained in the first post of this thread: https://forum.kw-studios.com/index.php?threads/vr-performance-tweaks-tips.13068/
Thanks, I know. Been there, done that. All of it, numerous times. Worked once, after a meta update it stopped working and has never worked again since. Always getting an INVALID DEVICE error.
Update: It runs for now!! (Note to self: Need to tidy up that download folder more regularly) Anyways, in the DL folder I found an old version of the required openvr.api file (quite the coincidence, was looking for s.th. different). I have tried several of those over the month, none worked. Tried the one I found: no change, crash at stratup with that INVALID GRAPHICS DEVICE error (yes, in caps, don't shoot the messenger). Just for giggles I also replaced the opencomposite.ini file I found lying there along side with the api-file while I was at it and >tadaaa< that did the trick . Left me rather baffled, I never gave much thaught to that file and even rember someone on reddit saying it wouldn't be necessary at all anymore. Nevertheless I kept it, but as it turns out it was a different and therefore wrong version. If you'll excuse me now, I have some old touring tintops to buy! See you guys on track! PS: You can find the opencomposite.ini file that worked for me, if you scroll further down.
Is there a way to get it running with virtual Desktop and openxr+oc? That's the way I use with ACC and it gives me the best performance and the possibility to decrease the fov, so that I can save tons of performance and increase the visuals dramatically. But with raceroom it didn't work yet...
Although I have VD installed I am hesitant to touch my setup right now, since I just got it working after months of failures. Cable-connection is out of the question for you? Hard to believe that a wireless solution would provide a better performance. I can also decrease fov via Oculus Debug Tool, but never bothered. How do you have your fov configured? You got me curious now
Well the freedom of being wireless is nice and I had a lot of trouble with meta link when connecting. I had to restart headset and PC very often to get the connection. Didn't matter if wired or wireless. Since I use virtual Desktop, I only have to press the power button of my PC and use the headset. It always connects without problems. The fov is reduced by the open xr toolkit within the headset. I reduce the horizontal fov just a bit until I can see the edges but I reduce the vertical fov a lot cause it only shows the roof of the car and the legs. Soni can save around 50% of the rendered pixels which gives a huge performance boost in ACC at least. I can run very high settings then.
Gotcha, if it works and the cable bothers you: good for you! I know the process, thanks, just curious about the actual fov numbers your using I think I'm not gonna touch horizontal fov since the native fov of the HS is not the biggest to begin with, but vertical could be worth a try. What's your vertical fov right now if you don't mind me asking?
Well I would have to check it but it is definitely very low. Like 50 to 60%. I only reduce the horizontal fov until the edge starts to appear and then I add a bit again. It is then at around 90%. Together this saves around half the pixel, so you can nearly double the fps or crank up the visuals. For this to work properly, you should use the modded dll by ohnespeed. He made a great tutorial on his YouTube channel and has the links to the files there. Without that mod, the fov is reduced but the amount of rendered pixels is not reduced that much as with the mod. That's what he says at least.
Anyone has the Varjo Aero working correctly? If yes what did you do? I’ve always had ultra low res , flickering graphics to the point text is not readable .
So I did a dive into our VR code this week and wanted to share some of my findings Firstly, I did a comparison of rendering the game in normal 2D vs rendering the two eye view used in VR (but also rendering to 2D to remove the VR overhead). I compared 3840x2160 normal 2D vs 2036x2036 per eye for the '2D VR', for the same amount of total pixels. This resulted in 200 fps for normal 2D and 150 fps for '2D VR', the extra cost here coming from having to do the geometry passes twice compared to normal 2D rendering. It's not ideal of course, but it's also not as big of a difference as I was expecting. This was also with reflections on Low, the higher reflection settings cost the same amount of GPU time in 2D and VR, so the gap would actually close up further with higher settings. The main thing I wanted to optimize this week was the overhead from submitting the frames to the VR headset. I'm not sure if this is the same for everyone, but I could not get higher than 85% GPU usage on any resolution setting, indicating some kind of overhead is costing us precious time where the GPU could have been rendering the game. This is not so surprising considering VR shouldn't even be possible in DX9, so it's never going to be ideal. What our engine does to allow VR is: Render eye views in DX9 -> Share the final textures with a DX10 API -> Submit the textures to the VR compositor from DX10 -> return the texture to DX9 -> etc.. This is also why the VR frametime analysis doesn't really work in our game, as from the VR compositor's perspective, our 'DX10 VR engine' pretty much just spawns a texture out of thin air and submits it. Sharing between APIs like this is always going to cause some extra overhead, especially the cost of sending the finished texture from DX9 to DX10 is something we cannot get around. However, what I noticed was that it was actually returning the texture from DX10 to DX9 that was often costing extra time and causing frametime spikes. This felt improvable, and I did so by making it alternate between two textures. This way, we can do the API work of getting the texture back to DX9 and ready for rendering, while the other texture is rendering the next frame. I also made some other changes to 'hide' as much of the API overhead during other rendering work. The final result was that I can now get up to 95% GPU usage, with much steadier frametimes too! My hope is also that these improvements might help with some of the API issues that non-SteamVR headsets have in RR. Unfortunately, I don't have one of those to test, so we will find out when the update comes. I could now keep a steady 90 fps at about 20% higher resolution in SteamVR compared to before my changes, which should compensate nicely for the slightly more expensive shaders that are coming with the update. Running this same resolution while skipping the VR overhead and simply rendering the VR view to 2D, I got about 105 fps. So about 10-20% overhead for submitting the frames to the VR headset and the VR compositor work, which doesn't seem too bad anymore. Finally, I think I made a nice QoL change to how the 'display VR view on monitor' option works. This setting/keybind now only controls if the VR view is rendered to the monitor during actual driving, where performance is crucial. In the main menu, when pausing in-game, and in replays, the VR view is now always displayed on your monitor It made testing a lot easier for me at least As a final note, I would still really like to see if we can somehow support openXR via opencomposite in RR. Though this might be tricky, as I 'only' have native SteamVR headsets to test with (Index and Beyond). We'll have to see if we can find some way of working with it, but can't promise anything unfortunately.