![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
UE4. I know of nothing close to release that is Vulkan or DX12 currently. Surely that will change, but it
I would not even begin to say that either.
LOL! Your expectations and reality are going to be greatly opposed.
, well basically cheap enough for everyone, these results only matter to the few people who are either buying or have bought a HMD for their pc. So if the devs want to perform temporal AA to avoid shader aliasing reprojection is a bit of a repeat of the step just taken. A knowledgeable dev should be able to do a more performant job than leaving it up to the SDK.
I guess I haven't checked specifically, but I'd have to imagine they have some implementation for ATW. It begs the question of why use 45fps and even intervals for async operation. If you are already adjusting for time and motion, a little bit more shouldn't be that big of a deal. That framerate should be flexible with lower rates having more artifacts.
With foveated rendering I'm not sure how helpful that stenciling would be. The console approach of scaling resolution or compositing tiles would seem a far better approach than a fixed resolution and stencil. Do the VR kits even support DX12/Vulkan paths yet or are we arguing over DX11/OGL where these techniques require IHV workarounds? Last I checked the async behavior was only available through vendor libraries for the kits as DX12/Vulkan were lacking to provide it more directly.
That's the point of reprojecting quickly. It wouldn't be as fast as possible as much as being as close as possible to being displayed. So if it took 2ms to reproject, schedule it 3ms prior to presenting a frame to keep latency low. Even a minor reprojection should be more accurate than a direct rendering with higher frametime. If the frame can be rendered in a few ms direct is fine, but if reprojection is sufficient to hide a lower framerate that opens up additional performance. Point being the dev could do a better job with that reprojection than just handing off a frame to the sdk. At the very least you could remove a memcpy from the chain.
Safety net sure, but I'd think reprojecting frequently to get an effective 4ms frame would be superior to >14ms reprojected to 14ms or even just less than 14ms. I'm sure future kits could push those refresh rates a bit. Even at 0ms there will still be a delay on the display.
I don't really consider the current batch of "VR" games much more than cheap arcade games. Sure better examples are coming, but they are still hacking together the tools that inherently come with DX12/Vulkan. We are talking about ATW everywhere with APIs that don't currently support the functionality directly.