Meant to be Seen

Apologies if this has been answered before but google didn't find a good answer.

Is it possible to make the drivers output the textures being rendered for the DX9 display to be mirrored to the Direct Mode system instead of being forced to use Extended Mode?

After updating to 0.6.0, I cannot get squat to work from Vireio or Vorpx. I actually took a break from DK2 for a couple of months so I have no idea what changed. Basically Extended Mode is all but useless now and I can only get Direct Mode demos working now. Now this could be my machine or the Rift or something but I never liked Extended mode anyway. Interacting with the desktop as it has to be primary is next to impossible in my opinion so Direct mode is awesome so I would love support for it.

The current SDK uses native DX11 mirrored texture support in its demos and also dropped DX9 support altogether apparently. Can this be mimicked in the driver for at least one layer? I looked into it and realized I'm in over my head with this code as I'm not a game developer. All I think I really needed is a copy of the final stereo texture and the map that to the raw output in the ovrHmd_SubmitFrame call like one would for OpenGL but I suppose I could be off-base. Or maybe use DX texture or something and convert to Rift format?

On my system it seems like DX11 files get loaded into memory for DX9 games so then could it be possible to maybe use the mirrored textures after all by some out exploiting this fact on DX11 capable systems?

Anyway, just checking if this is not even close to feasible or if there is a better way or something.

For now the only real solution is to roll back to use runtime version 0.5.

I have exactly the same issues as you with 0.6. Even without Vireio running I can't even start a DX9 game if the rift is turned on, directx just fails to initialise.

There are a couple of investigations on going as to how to tackle this issue, however as it currently stands, there's no easy way (as far as I am aware) of mirroring DX9 eye buffers to DX11. As far as I understand things, shared textures weren't introduced until DX9Ex, so it doesn't seem possible without copying texture buffers to standard memory (sloooow) to share the game's render target textures so that they can be used with the OVR DX11 SDK. However I am no expert on these things, so I may well be incorrect.

So for now the only advice on offer is rollback. We may be lucky and OVR might fix (assuming it is a bug, rather than intentional) whatever it is that is preventing DX9 initialising when the rift is turned on and runtime 0.6 is active.

Thanks for the answer. So I looked into OBS which uses hooks to inject itself into applications including DX9 games. They seem to load DX10 or DX11 into memory if they can and do some texture back buffer sharing to workaround the sharing needs. The texture data is then shared with the main application using shared memory.

They take that and render preview windows using DX10 in the main host. Now OBS has a lot of code basically for compressing the data to video streams as thats it main function which I dont care about and less for something like this. Also OBS and Vireio conflict with each other but I think that the OBS technique could be ported to Vireio due to how Vireio takes over the whole interface and not just individual functions. (One is GPL v2 and the other LGPL v3 so may not be compatible for direct code usage.)

Some games were not working correct and crashing in the Oculus user mode driver over some issue with D3D11CreateDeviceAndSwapChain and the Microsoft Basic Render Driver or something but some games were apparently streaming fine using this technique at 60 FPS (which is the limit of my primary monitor so couldn't get that to 75 fps for testing).

I was sort of thinking that this technique could be useful for the Rift. It would potentially allow sharing textures to another app which could be pure DX11 and drive the rift. Alternately the D3D11CreateDeviceAndSwapChain might be able to create a DX11 compatible device and mirror textures which could be fed to the Rift direct mode in-process.

Anyway food for thought. I might play around with it as technique just for my own education.

There is news on this:
https://www.facebook.com/vireioperception

Great news!

This is great news. I was making some progress but I'd prefer the professionals come in and do it as I'm sure they will do it right.

There were a couple of new posts yesterday and some hints of a release soon so looking forward to that.

If you are interested check out the DX9ex branch on Github to see how it was done in the end. Quite similar to your earlier explanation in some ways. Current thinking is to get it out in current state as quickly as possible (probably this week - although we are aware of some broken games) and get feedback from users.

So I've been busy for the past couple of weekends so I haven't had time to try it out. I recompiled it again but had to redo all of the projects to work with my machine and that killed the fun last time I could work on this. Finally got Oculus SDK and this compiled with VS 2015 and it mostly works in the sense that DirectToRift works with some artifacts in Dishonored. It doesn't seem to actually do the stereo effect though other than present the game in a giant billboard effect (still better than typical behavior though).

So just wondering if that is because its still alpha or if it is a problem with my configuration (using VS2015 for example). I'll assume the former for now. It seems to be outputting graphics in the DX11 thread just fine so looking good from that perspective. Anyway good job so far and now I suppose its time to dig a little deeper and see what is going on under the hood.

The "giant billboard" is the new disconnected screen view, games now start in that mode so you can navigate through opening menus etc, and once you are in the game, click the middle mouse button (on the wheel usually) and it will take you into normal vr mode.

Dishonored is known to have some issues at the moment, looks like it might be related to alpha blending or something.

The DX9Ex branch has come on further than the recent Alpha, so you might wish to pick up the code again if you haven't lately.

I am on W10 x64. With Alpha 3 on extended in 6.0.1 or 0.7 (yes, you can set it on extended, it's just a bit more complex than before) I get no headtracking, and in any of those runtimes, Direct to HMD has abbysmal perrformance on Skyrim (4-5 fps vanilla). And no, it's not SDK Pose Prediction; I turned it off. I was hoping 0.7 would solve the abbysmal Direct to HMD performance, but no cigar...

My specs:
CPU: i7 4770k
RAM: 16GB PC1660 DRR3
GPU: Nvidia GeForce GTX 980 - 355.83 beta Drivers (happened with WHQL 355.60 and before, too).

Any help?

Just upgrading to Win 10 now - I have pretty much identical specs to you. I'll let you know how my performance is an if I can see anything obvious.

Got onto Win 10 - 0.7 - 355.83 Nvidia Drivers (as suggested by Oculus). Direct to Rift mode. We no longer support extended mode at all so don't use that.

Performance equivalent to before. Get around 30 - 50 outside depending on options. Inside getting around 75.

Smooth throughout providing the DX9 FPS stays above 37.5.

I7 4790 @ 4ghz
Nvidia 980 GTX
16gb Ram

Where in Skyrim does ithave the low fps - all the time or just on complicated scenes?
What is the FPS of the Async thread (Shift + F)?

P.s.
My Skyrim is modded as well so vanilla should be even better performance

baggyg wrote:Got onto Win 10 - 0.7 - 355.83 Nvidia Drivers (as suggested by Oculus). Direct to Rift mode. We no longer support extended mode at all so don't use that.

Performance equivalent to before. Get around 30 - 50 outside depending on options. Inside getting around 75.

Smooth throughout providing the DX9 FPS stays above 37.5.

I7 4790 @ 4ghz
Nvidia 980 GTX
16gb Ram

Where in Skyrim does ithave the low fps - all the time or just on complicated scenes?
What is the FPS of the Async thread (Shift + F)?

P.s.
My Skyrim is modded as well so vanilla should be even better performance

Welp, something must be wrong with mine...
Modded or vanilla I get between 9 and 20 fps, asynch between 68 and 75 at 20 fps, around 25 when at 9 fps. Also, there is half a second lag on my head movement (head-to-photon) and there are graphical glitches like missing textures and weird white meshes covering the LOD mountains. (things from mods, the glitches don't happen in Vanilla, but in vanilla there is no headtracking).

EDIT:

Went through Vanilla introduction scene (Helgen). During the cart, the average fps was 8.2; after the dragon arrived, 15.4 and inside the keep if I didn't look at any actors it was 68-75, even 80; if I looked at one actor it dropped down to 45, and more than one down to 15-20. The Asynch was constantley outputting 75 fps.

The thing is that in the worst situations, using 6.0.1 and 2.1.6 I get solid 30 fps (I've tested it in huge 200 actors battles in the open). Not using ENB or supersampling at all. I don't understand what's wrong.