Rift, Vive, and Virtual Reality

PSA: Valve has finally implemented Async Reprojection in SteamVR alongside its less effective interleaved reprojection technique.

Support is currently only present In today's SteamVR Beta build and only works on Nvidia GPUs:
* Notes on async reprojection:
  1. Requires Nvidia driver version 372.54 or newer.
  2. AMD not supported in this version.
  3. Can be disabled in SteamVR settings under Performance by unchecking "Allow asynchronous reprojection".
  4. Current status is listed in the lower left section of SteamVR Settings (Async Reprojection On/Off). If you have "Allow asynchronous reprojection" checked, but are still seeing Async Reprojection Off on the left, this means it is not supported on your current setup - see above for requirements.
  5. Frame timing graph has been updated to show the number of times each frame has been presented (white line in the stacked cpu graph) and the number of times each frame has been reprojected to a different vsync than originally rendered for (red line on the stacked gpu graph).
  6. "Allow interleaved reprojection" checkbox still applies in async mode. It controls whether the application is dropped to 45hz when not making framerate, or if it is allowed to get further and further behind until a frame winds up getting presented twice. This leads to less positional judder, but that judder is more random (which tends to be more annoying).
http://steamcommunity.com/games/250820/announcements/detail/599369548909298226
 
...and only works on Nvidia GPUs...

This VR landscape of super short turnaround R&D seems to further highlight the gap between Nvidia and AMD. It's hard enough that they've got a missing product segment at the high end, but they also seem to be struggling to keep the same pace for supporting existing cards. A lot of AMD's VR users who bought into the 'async compute = superior VR performance' marketing and opted for 290/390/Fury cards over Maxwell are not feeling too comfortable now.
 
This VR landscape of super short turnaround R&D seems to further highlight the gap between Nvidia and AMD. It's hard enough that they've got a missing product segment at the high end, but they also seem to be struggling to keep the same pace for supporting existing cards. A lot of AMD's VR users who bought into the 'async compute = superior VR performance' marketing and opted for 290/390/Fury cards over Maxwell are not feeling too comfortable now.
It's simply not currently supported in the first beta build. That is all. What does it have to do with what you just posted? AMD has nothing to do with this as this is purely Valve's doing. As a matter of fact it's not even working on several NVidia GPUs even with the recommended drivers listed above...so yeah you lost us here...ATW on Oculus (which is what this is but for SteamVR) has been working perfectly fine on Nvidia AND AMD GPUs... :-\
 
Last edited:
Yeah, it's more about Valve playing catch up with Oculus. Oculus hasn't had problems with supporting it on both IHVs hardware. I'm guessing that Valve is just dedicating less resources to VR on the software side of things and hence lagging behind.

And as stated, it's a BETA implementation. I'd be disappointed in Valve if support wasn't there for both IHVs hardware by the time a final release is out.

Regards,
SB
 
A lot of AMD's VR users who bought into the 'async compute = superior VR performance' marketing and opted for 290/390/Fury cards over Maxwell are not feeling too comfortable now.
Was it marketing though? We haven't really seen the effects used with DX12/Vulkan which actually provide the asynchronous behavior natively. Maybe for PSVR, but there haven't been many articles on that. Even now I doubt the effects are compute based just for compatibility on Nvidia parts. It's also reasonable to assume these techniques will be built directly into the apps by the developers as opposed to hacked in. It would definitely be nice if AMD stepped in and got some AMD specific implementations working for the VR guys. The approach shouldn't be that difficult, but maybe they aren't concerned with DX11 performance on VR?
 
It's simply not currently supported in the first beta build. That is all. What does it have to do with what you just posted? AMD has nothing to do with this as this is purely Valve's doing. As a matter of fact it's not even working on several NVidia GPUs even with the recommended drivers listed above...so yeah you lost us here...ATW on Oculus (which is what this is but for SteamVR) has been working perfectly fine on Nvidia AND AMD GPUs... :-\

Valve also spoke of working on a motion vector extrapolation technique (akin to ASW), which last I saw AMD hasn't announced plans to bring to 290/390/Fury. I think in the context of the VR landscape, whether something is "beta" or not isn't a terribly moving consolation as this entire endeavor is effectively a beta in both hardware and software, resulting in a prickly community that is sensitive to important feature releases. Only reason I brought this up was because it was only in the past week or two that we had the ASW support ruffling some feathers.

Was it marketing though? We haven't really seen the effects used with DX12/Vulkan which actually provide the asynchronous behavior natively. Maybe for PSVR, but there haven't been many articles on that. Even now I doubt the effects are compute based just for compatibility on Nvidia parts. It's also reasonable to assume these techniques will be built directly into the apps by the developers as opposed to hacked in. It would definitely be nice if AMD stepped in and got some AMD specific implementations working for the VR guys. The approach shouldn't be that difficult, but maybe they aren't concerned with DX11 performance on VR?

I guess I'm coming from the position of when I see marketing slides how long does it take for those things to materialize in a white paper, driver support, sample code, engine integration, and the pudding proof of content performing better. Early on it felt like AMD was positioning their LiquidVR initiative to contrast Nvidia's GameworksVR. Looking through their developer portal to see just what LiquidVR is comprised of now and what their SDK offers gives me the impression that it has more value as a consumer focused message of, "We're doing VR too" than it is a toolkit for VR developers.
 
I guess I'm coming from the position of when I see marketing slides how long does it take for those things to materialize in a white paper, driver support, sample code, engine integration, and the pudding proof of content performing better. Early on it felt like AMD was positioning their LiquidVR initiative to contrast Nvidia's GameworksVR. Looking through their developer portal to see just what LiquidVR is comprised of now and what their SDK offers gives me the impression that it has more value as a consumer focused message of, "We're doing VR too" than it is a toolkit for VR developers.
Both the VR SDKs seem more marketing than anything to me. LiquidVR for example is just DX12/Vulkan capabilities to provide better timing controls. Few other nice features, but nothing I'd call critical.

Implementing ATW with async compute should be fairly easy. ASW is more interesting, but we've seen at least one game(Doom) already writing out motion vectors. At the very least keeping the scene and cockpit in different resources could help things along. Considering most of the PC based VR content is coming form the major engines, I'd expect them to be able to implement the features in a reliable fashion. Just need the HMD kits to provide an API allowing appropriate resources to be passed in.
 
F@king finally! Epic has released UE 4.14 Preview which includes a relatively barebones forward renderer for VR! (the internal version being used door Robot Recall is definitely more advanced with SSR already supported)
https://www.unrealengine.com/blog/unreal-engine-4-14-preview-1-released

Rendering Updates:
  • A Forward Shading Renderer for VR (Experimental) that supports high-quality lighting features, enables Multisample Anti-Aliasing, and is faster than the Deferred Renderer in select projects.
    • To use this, enable ‘Forward Shading’ in the Rendering Project settings and restart the editor.
    • To use MSAA, set the default Anti-Aliasing Method in the Rendering Project settings.
    • DBuffer Decals, Dynamic shadows and Capsule shadows do not handle MSAA properly yet and may exhibit artifacts along object edges.
    • Not yet supported in the Forward Renderer:
      • Screen space techniques (SSR, SSAO, Contact Shadows)
      • Shadow casting Movable Lights
      • Dynamically shadowed translucency
      • Translucency receiving environment shadows from a Stationary light
      • Light functions and IES profiles
 
Last edited:
Both the VR SDKs seem more marketing than anything to me.

GameworksVR had the API and sample code with functioning demo scenes available since last summer, Nvidia has released tech demos of them integrated into game engines, has released the source for those game engine branches, and there are examples of VR games that implement features like MRS that impact rendering performance.

Implementing ATW with async compute should be fairly easy

But to that I answer, "So what..?" ATW isn't an expensive operation, so optimizing isn't particularly meaningful. AMD's shortfall right now is in frame times, not VR compositor performance. Maybe there's some light at the end of the tunnel for them with DX12/vulkan and/or Vega, but as things are right now it feels like the real world gap between the two companies is actually getting wider in VR as we see more UE4-based games popping up and content having their hardware requirements crawl upwards in response to Pascal becoming more common.
 
Has anyone else tried having a desk fan blowing on them while playing a racing game in VR? I've just given it a go in Project Cars while racing some topless cars. Add's a nice extra dimension of realism!
Mad Max with goggles rendered in would be a lot more entertaining with that fan.

But to that I answer, "So what..?" ATW isn't an expensive operation, so optimizing isn't particularly meaningful. AMD's shortfall right now is in frame times, not VR compositor performance.
If you're reprojecting effectively, does the time to render a scene matter as much as the compositor? We haven't seen much of DX12/Vulkan with VR yet either. Nor higher refresh HMDs that likely warp at a higher multiple. Comparing frametimes of say UE, which has historically favored Nvidia, doesn't seem that relevant a comparison. I'd say AMD does a comparatively better job as resolution increases. So under ASW with gamers cranking up the super resolution, are they really that much worse?
 
Last edited:
Ugh, this makes me sad. I've run into some people that are now taking drugs (Dramamine) in order to play VR. Apparently it's also the new "thing" for getting high and having hallucinations if you take more than the recommended dose. /sigh. It apparently isn't inherently addictive, but when abused can cause the formation of an addiction to the drug.

Regards,
SB
 
Ugh, this makes me sad. I've run into some people that are now taking drugs (Dramamine) in order to play VR. Apparently it's also the new "thing" for getting high and having hallucinations if you take more than the recommended dose. /sigh. It apparently isn't inherently addictive, but when abused can cause the formation of an addiction to the drug.

Regards,
SB

I'd think we can put that down to whimsiness, wouldn't think we saw true whacko-ism yet. Now wait, maybe with magic leap™.
 
Ugh, this makes me sad. I've run into some people that are now taking drugs (Dramamine) in order to play VR.
I'd say this is a crude way of doing it, We prescribe the drug for controlling sea sickness, also for treating symptoms of inner ear inflammations (which misses up balance and induces vertigo), It's an Anti-Histamine drug (think Anti Allergy), the motion sickness part was discovered accidentally while treating a bad allergy case, however it crosses over to the brain, and blocks some neurotransmitters there, causing dizziness and drowsiness, we even use it on patients with insomnia for this effect!

A much better alternative is a drug called Betahistine (an anti-vertigo agent), it's a pro histamine drug that enhances neurotransmitters release, with no significant side effects, except for when the patient is badly susceptible to allergies, in which case his allergies will become worse. Never the less, it's use in managing motion sickness is debatable right now, the patient should consider using it to see if his motion sickness improves or not, In my experience it's pretty harmless, I have yet to encounter any major side effects on those I prescribed it for, so giving it a trial is not actually a bad idea, and certainly better than Dimenhydrinate (Dramamine).
 
As the first generation of gamers to experience video gaming, we are often exposed to a lot of the early problems without real training from the start, children have a much better chance of training themselves to withstand these problems when experiencing them at such an early age, as opposed to someone in his early 20s, 30s or 40s.

I just find it sad that people resort to drugs of any sort in order to play games.

A large portion of the blame is on developers, they need to design their games with less nausea inducing effects (Motion Blur, DoF, Chromatic Aberration), control their camera movement so it is not disturbingly bad, have decent frame pacing and good optimizations to deliver decent frame rate on good hardware, have good field of vision that is customizable to user preferences and so on.

Motion sickness during gaming is not the only problem to affect the population, epileptic seizures is one other common problem, exacerbated by the exposure to flashy lights and loud noises, and there are a lot of Epilepsy patients out there, a lot of my children patients have one form or another of epileptic brain activity, they are usually controlled with medications, and Epilepsy meds have became so good at controlling the disease. Motion sickness is another story though, a lot of it's mechanisms have yet to be fully understood. We will conquer through it when we unlock more of our brain's secrets. Here is hoping it happens soon enough.
 
Last edited:
I do hope the brain eventually adjusts (as many people report) or we find new techniques in games to get rid of it (very few games induce it for me). Bound's camera for instance works great, which immediately solves the issue for all 3D platformers.

I already got nauseous from one or two first person shooters. Some combination of camera motion and field of view that my brain just doesn't want to deal with (I think Resistance 2 was an example).
 
Time seems to help in regards to motion sickness with VR. I have a friend who gets very sick with my rift but has gone from being able to play a few minutes to almost an hour at a time.

Also he says ginger helps him a lot and he brings over real ginger ale.

I think also in time there will be advances to the tech to fix these things. Higher res panels , better audio tracking and eye tracking should help
 
Back
Top