fearlessfrog

Here's the official confirmation of the Win10 1903 WMR VR renderTargetScale bug that impacts the Reverb, Odyssey and other WMR headsets. Hopefully quiets the 'flat earthers' on this, as it was getting tiresome to being told that it didn't exist, especially when trying to help them. https://steamcommunity.com/app/719950/discussions/0/1644292361960505688/ "A number of users have reported issues with blurriness after upgrading to Windows 1903. Unfortunately we didn't see this in insider flighting and in our private testing. We have investigated and the underlying issue here is part of the Windows release, and not contained in the WMR for SteamVR package. We've tracked down the issue and have a fix ready, and are working on getting it released as a Windows update. Doing this means it takes a few weeks as Windows updates ship on a regular schedule. If you have already updated to 1903, please know that we are actively looking into workarounds to address the issues here. If you haven't updated to 1903 just yet, you may want to wait for this to be fixed." You can also discuss the bug and possible workarounds with them here:

On a quick look through the results my best guesses would be: 1 - There's a performance increase on the CPU frame time side, but it is usually not the bottleneck for our typical settings so doesn't impact as much as perhaps we'd think it would. People seem to have GPU bottlenecks perhaps? 2 - Only a couple of the results show dramatic release vs beta changes, so re-verifying those would be good (as it might be easy to get release vs beta option.lua's not the same, for example). Due to the low number of the result set, it's just worth doing a verification on those outliers before inferring too much. An interesting experiment for those with release and beta still installed would be to use the system settings 'Low' preset and then run the same TF-51 test run. It might point at some CPU optimization revealing themselves a bit more between the two builds, as the GPU would be doing less and the CPU changes shine.

Since this topic sort of turned into 'The Lost WMR Settings Manual' tips area, the other thing I wanted to point out for people to try (as this one is quite subjective and based on personal tastes) is in WMR you can use the SteamVR setting of 'Enable advanced supersample filtering' on or off. It's found in the Developer tab of the latest SteamVR settings panel. Because SteamVR is doing the supersampling for WMR, this setting is used and applied to the pipeline at the end. It is sort of a FXAA algorithm that smooths out some jaggies and has a low run-time cost, typically a couple of fps. I personally like MFD fonts and the like super sharp, so turn it off, but it does help the 'out of the cockpit' antialiasing in DCS a bit, without having to resort to the much slower MSAA on the DCS settings side. It could be worth a try. So, anyway, thought I should point that out for future Reverb (or other WMR) using people to try.

Yep, 1809 is good. It seems the maximum impact is on the Odyssey Plus clarity, but it does do something for sure on Reverb as well. Because we're talking much higher resolutions on the Reverb, it might still just be good enough on 1903, but I don't have one, so can't offer a decent opinion for sure.

https://www.microsoft.com/en-us/software-download/windows10ISO Pick the Windows 10 October 2018 version for 1809. Not sure where 1803 is available without a MSDN subscription or publicly now.

TF-51D Instant Action mission Flight Over Tbilisi - FPS for both tests Release 68 fps / Open beta 72 fps - System specs Windows 10 Pro x64 v1809 Important for WMR, NVIDIA 2080 8GB, INTEL i9 9900K @5.0 GHz, 32GB DDR4 @3200 , Aorus Elite 1151 Z390 - Graphics settings (same options.lua used on both build) - VR settings above in spoiler PD 1.0, SteamVR SS 212% - Type VR set used and driver version Odyssey Plus, WMR 1.0.432.0 driver (WMR for SteamVR Beta) SteamVR Beta - 1.5.10 motionReprojectionMode forced off NVIDIA game ready driver 430.86, all Nvidia app settings default Summary: No real difference for me.

A lof the issues sounds like similar ones to the Rift USB power drain (and again with the Rift S) where not enough juice is going through the USB 3.0 port. I wonder if they are going to redesign that cable connector and perhaps look at an external power supply now? Some people are claiming to have success with the Reverb with a PCI-E powered USB card, rather than their motherboard - sort of pointing at a power issue.

WMR headsets on SteamVR SS don't take into account the distortion warp, so put simply, they don't line up with the exact panel native resolution on the SteamVR slider, you need to set it higher if you want clear pixels in the middle for stuff like DCS. Lots of previous stuff around resolution here: https://forums.eagle.ru/showthread.php?p=3944936#post3944936 Plus stuff on how reprojection in WMR works here (not relevant to your question, but handy anyway): https://forums.eagle.ru/showthread.php?p=3945739#post3945739

The last open beta update had a change in the LOD of the trees. That seems to have made a big impact for people that run a lot of trees :) or with Normandy, that uses them for hedgerows. I don't think the SpeedTree's LOD change was for VR specifically, but it does seem more apparent in high resolutions that VR uses perhaps?

The only way to prove it to yourself would be to have Win10 1809 and 1903 and do the comparison like we did already. If you don't have that and have healthy skepticism or a fear that other are simply not telling you the truth (for, um, reasons) then I think you're out of luck. I personally don't think it impacts the Reverb a lot, and is mainly a O+ issue. Even then, I think the majority of Odyssey and WMR users probably don't run it near native resolution anyway, so aren't that bothered. Sort of a niche within a niche.

Don't worry about it, just return the Reverb and move on is my advice. For others, more info:

Yep, the bug exists for the Reverb on 1903: https://forums.mudspike.com/t/vr-news-hp-reverb-second-gen-headsets-are-on-the-way/8165/402 It's only really apparent on high super sampled values, for people trying to get cockpit like clarity with a native res like 212% on the O+ or 188% on the Reverb. I wouldn't be surprised if people are sending their units back without ever really seeing them work properly, which is dumb of Microsoft to let this go on so long.

Kinda. :) fpsVR has CPU Usage, which is the average across all the cores, like the Windows Task Manager would show. It also has a CPUmax/thread percentage that indicates the highest loaded core percentage. That is better than plain avg usage, but not perfect as it is still time sampling between the core hopping (or rather, it is using an underlying API that does that, and fpsVR reads it and passes it on).

Thanks. I'm working on an article at Mudspike to try to gather up the various VR tips and whys, as it's a really confusing subject for all and probably worth consolidating. If SteamVR goes away, in some ways all it is doing now is (a) identifying the WMR device as an OpenVR API device for the pass-through of calls to the underlying driver (this is a very small run-time overhead in reality, but interesting to see what ED find here in profiling DCS with it) and (b) providing the target resolution to up or downsample to, through the SteamVR SS value. DCS already has pixel density, so I guess we would just have to use that. The WMR does everything else already, reprojection etc. The only wrinkle in this is Microsoft continue to full support and grow out the Win32 mixed reality side or not. They have more reason than any (being the awkward third child) to put full effort behind something cross-company like OpenXR as the main API. Out of all the partners, they put the most effort into a OpenXR runtime for their devices. Valve will likely go that way, but I'd imagine Facebook/Oculus are just stalling or playing along - it makes more sense for them to be a closed stack business-wise.

One thing I forgot to say yesterday and wanted to add, is that your CPU utilization indication can sometimes be a bit deceptive. Because DCS only uses one main rendering physical thread (the other one for sound and some housekeeping I believe) then it used to be the case on something like Windows 7 and an i5 2500K that you'd see 'Core 0' (or whatever was the launch core) be maxed out at 100%. You'd still see an overall 25% utilization (because cores 1,2,3 weren't doing much), but it was obvious DCS was CPU bound. Now with Windows 10 and its new Thread Scheduler, it uses a new technique for CPU thermal management called 'core hopping'. What is happening is that the overloaded physical thread (of DCS giving all those DX11 instructions) is bounced between cores more rapidly. This helps the CPU stay cooler, but gives a bit of a false impression that DCS is uses more cores and is not CPU bound. You can play with the process affinity and such to try to prevent it, but on something like a Skylake gen chip it's pretty efficient hopping and you won't gain much. So generally you can max out the GPU using MSAA using a high VR resolution and it should be typically to see 90% usage on that, if the power profiles on the card are ok. If you have GPU headroom (unlikely with VR) then antialiasing is good. For the CPU and an i9 it would be typical to show 10-15% utilization and DCS would still be showing it is CPU 100% bound on the single core. The bottleneck is the CPU not being able to feed the GPU pipeline instructions fast enough in this single threaded game loop. This is a restriction of DX11 and the engine that DCS uses, and will hopefully evolve over time as they move to the Vulkan API. If you have CPU headroom (again, unlikely in VR with the single core) then Visib Range and object count could be increased. Anyway, a bit off topic, but if you are checking out fpsVR then I wanted to provide some info around what you might see as the bottleneck.

Thanks for that, interesting! I wonder when in the pipeline it's doing it. The DCS engine might be applying their's at a different stage to the driver.

Just a theory but with ref back to here, could it just be the case that your 'motionReprojectionMode' is set to 'auto' and then it's doing enough work to get to vector reprojection and then idling a bit? If you aren't at 90 Hz then it will try to make a timing for a frame in the next 11ms slot, so that means you could be comfortable doing 55 to 65 fps, making a frame and then shows you locked to 45 fps (with reprojection showing you 90 Hz refreshes). If you turn off motionReprojectionMode (just comment it out etc) then does your framerate vary and the CPU/GPU work more but your frames vary as well? PS For getting what is bound in VR in a bit more detail, fpsVR is quite good. Info on that here.

As I understand it, the Nvidia driver Antialiasing modes are not used by the Mixed Reality Headset driver render. I've never proved it for sure though, so I could be wrong of course. I believe only the things like the 'virtual reality pre-rendered frames' and 'power management modes' are used from that side. Are you sure Nvidia Manage 3D Settings / Antialiasing - FXAA has an visual impact when forced on in VR/WMR? It would be great if it did, but I've not seen it myself so interested to see if anyone has done some A/B tests.

The MSAA is tough to have off I gree, but it's a real balance between the high resolutions we're needing for VR clarity in the cockpit versus the deferred rendering engine that DCS uses. Deferred rendering gives you good dynamic lighting as it doesn't matter how many objects you have, just your light sources. Forward rendering (which most games use) on the other hand gives you aliasing pretty much for free. MSAA on deferred is a O(n^{2}) quadratic problem, meaning it kills pretty much every card we have on DCS with each resolution step up we do in VR. x2 and maybe x4 are possible, but reaching that magic 60 fps or so is getting hard. Something like an edge aliasing or FXAA on DCS would be great, especially for VR, but I've not heard anything about that. It's either that or multiple GPU support (perhaps under Vulcan one day), and that's where I run out of money.. :)

I tried today's Win10 update on 1903 but it still breaks the resolution, at least for sure on the Odyssey Plus. I guess we just have to wait.

On a 2080, i9 at 5.1 GHz in DCS to run ok and still look good I use MSAA off, Shadows/Terrain Object Shadows: Flat with an O+ at DCS PD 1.0 and Steam SS at 212%. Everything else you can have as high (well. perhaps not Visib Range) as you like, but has less impact than the using MSAA and the shadows. I think a lot of people would like a scalable MSAA solution, as it's not ideal yet. Hopefully the VR patch (tomorrow?) will help out some more.

Ideally it would be in the Microsoft KB release notes, but who am I kidding :) One way to tell would be to edit your config file here: \SteamLibrary\steamapps\common\MixedRealityVRDriver\resources\settings\default.vrsettings ..and set motionReprojectionIndicatorEnabled to true (just uncomment the line) and motionReprojectionMode to auto. When you start a game you'll get a small square in the top left, which indicates if the reprojection is working or not. The way to tell if the renderTargetScale 'not being read as 2.0' bug is fixed or not is to edit that renderTargetScale value to '1.0' and go look at the square. Now restart SteamVR / WMR (restart both if you ever change anything in that file, it's only read at start-up) and set it back to '2.0' again. Did the square appear smaller and more to the top left or not when using 2.0 vs 1.0? If it did then this is fixed, if the 2.0 looked like the same size/position as 1.0 then it's not. It's a good illustration of what is being limited, as it shows the underlying resolution is smaller if not fixed.

Just like with the native resolution, WMR is also fairly confusing when it comes to the forms of reprojection it uses. Here's my findings (I'll do a copy/paste rather than offsite link, as I think that is politer here and I've already type it :) ) : "If a game can reach around 55 to 60 fps the WMR with the default.vrsettings set to ‘auto’ will use something called ‘motion temporal reprojection’, which is the Microsoft clone of ‘Async Space Warp’ (ASW) on the Oculus side. It looks ahead/behind frames with GPU geometry to work out an in-between frame that’s pretty convincing. This allows the trees to appear smooth at 90 Hz in the headset, but DCS needs to reach about 60 fps. If a game only reaches about 45 fps or less then WMR falls back to ‘asynchronous rotional reprojection’, which is what the old ‘Async Time Warp’ (ATW) used to be on Oculus, i.e. ok for moving your head around, but bad at predicting things moving outside the cockpit. When you see the cockpit moving ok but the trees to the side ‘jumping’ in WMR then it’s using reprojection but falling back to what it can do. I didn’t realize before why it falls back to the older algorithm like that, but does explain what people see. It’s also why DCS will just stick at 45 fps even if motion reprojection is not set to ‘auto’ in that config file or everything is left as defaults - it’s because it defaults to the old ‘asynch rotational reprojection’ by default unless the ASW equivalent is enabled or the app is reaching 90 fps. It will be interesting if the DCS VR optimizations allow more people to get to 60 fps with more settings maxed out. In my experiments with the WMR reprojection, the ‘motion temporal reprojection’ is very good, i.e. very smooth sideways trees. REF: https://docs.microsoft.com/en-us/windows/mixed-reality/enthusiast-guide/using-steamvr-with-windows-mixed-reality#enabling-motion-reprojection-for-steamvr-apps 2 Oh, plus should say. You can turn things on and off in the SteamVR settings stuff for the Valve ‘motion reprojection’ and all those things, then it’ll be completely ignored by the WMR headset. If you see any difference using those settings then it must be a placebo, as the reprojection steps only happen on the Microsoft driver side using its own rules/steps mentioned above I believe. I think the resolution / super sampling percentage value is probably the only setting from SteamVR that is read, everything else is probably on the Windows WMR side of things. It seems the best ‘tuning’ algorithm for WMR and using reprojection in DCS would be: Go to the default.vsettings file and comment out (using //) the motion line, i.e. turn it OFF. Test DCS with your settings. Adjust them so you get to 55 to 60 fps with the resolution / super sampling you want. Go back to default.vrsettings and uncomment the line (remove the //) so it says “motionReprojectionMode” : “auto”, in there. That way you’ll get smooth tree sideways and reprojection working properly. The things I didn’t realize before were: WMR always has some form of motion reprojection on, it’s just the simpler ‘rotational’ type (where looking sideways causes judders for example) if it can’t make some headroom over 45 fps (it seems typically you need 55 to 60 fps to be safe). The fancy ‘motion vector’ reprojection is very good, but needs to be turned on in that file. Once on then you’re only ever going to see either 45 or 90 in the fps read-out. Turning it off is useful to adjust detail settings. WMR is like archaeology on how it works underneath. I half expect to find a stick of a certain length that’s going to refract the sun’s rays over a temple map through a jewel, so we can find out how to do nicer anti aliasing one day…;) "

I think that's because the native resolution of the Reverb is 2160x2160 per eye, so 188% gets the SteamVR resolution to 2206x2160. SteamVR reports 100% on the Reverb as 1608x1576. The trouble with that is that it's not taking into account the warp distortion, so I wonder if it's meant to be best targeted at 3024x3024 (as in 2160 x 1.4 ish) or is already included for that headset? I don't have a Reverb so can't tell, plus would suspect current WMR limits things before getting to a resolution like that. If HP made some more then I could get one. :) At the end of the day, all the sliders and adjustments are a balance for clarity and performance, so even doing stuff like undersampling on a Reverb is probably still clearer than a O+ pentile. One of the reasons the Rift S is so clear despite the resolution is the RGB pixel layout, so it's always more a combination of the panel tech, lens and various stages in the render stack as to what works best for different people. EDIT: BeachAV8R is documenting his Reverb set-up steps here - in-case it helps anyone in the future.

The SDK shows 2072 x 2582 as the max buffer for the O+. Publicly the nearest comment from Microsoft was this: ..which is handy for other headset ratios as well.