cancel
Showing results for 
Search instead for 
Did you mean: 

Preliminary SDK 0.4.4 RC4 Feedback

cegli
Honored Guest
I've finished integrating and testing the 0.4.4 RC4 SDK with Dolphin VR. The integration was fairly smooth. I only had to change the name of one variable (ovrRenderAPIConfigHeader->RTSize was changed from ovrRenderAPIConfigHeader->BackBufferSize), which wasn't a big deal.

This bug: https://forums.oculus.com/viewtopic.php?f=34&t=16910 is still in there from SDK 0.4.3, so I modified it myself to fix it again.

I haven't noticed any improvements from 0.4.3, but I'm not exactly sure what I'm looking for either. I also didn't notice any regressions. Here's a reproducible issue that has always existed that I still have:

---------------------------------
Direct Mode -> OpenGL to Direct3D switch bug.
Steps to Reproduce:
1. I start a program (Dolphin VR), but I don't run ovrInitialize() or ovrHmd_Create() yet.
2. Choose OpenGL as the rendered and launch and a game in direct mode, which does ovrInitialize()/ovrHmd_Create() and all of the configuration.
3. Close the OpenGL game, which executes ovrHmd_Destroy(hmd) and ovr_Shutdown()

Now, if I start an OpenGL game again, everything is fine.

4. If I try and switch to DIrect3D I get a crash in OVR_Win32_RenderShim.cpp at line 347:
        return (*oldProcExW)( lpLibFileName, hFile, dwFlags );


Here are the variables at that time:
lpLibFileName =    0x000007fef8b34648 L"gdi32.dll"
hFile = 0x0000000000000000
dwFlags = 0
lpLibFileName_cstr = 0x000000000012b770
targetAPI = DirectX (0)


The offending code is called from here:
    HRESULT hr = DX11::D3D::LoadDXGI();
hr = DX11::D3D::LoadD3D();

IDXGIFactory* factory;
IDXGIAdapter* ad;
//Oculus SDK Bug: Once OpenGL mode has been attached in Direct Mode,
//running the next line will cause a crash in Oculus SDK. Seems to work
//If you never ShutdownVR() the OpenGL mode, and never InitVR() for the
//Direct3D mode, but that is very hacky. Running ovr_Initialize(); here stops
//crash, bug kills Direct Mode. Wait until SDK fixes this issue?
hr = DX11::PCreateDXGIFactory(__uuidof(IDXGIFactory), (void**)&factory);


As the comment says above, I've found that placing ovrInitialize() before DX11::PCreateDXGIFactory fixes the crash, but then Direct Mode fails to start. I've also found in testing that if I never ovr_Shutdown() the OpenGL mode, then never ovrInitialize() for Direct3D it works, but then breaks it in the reverse direction.

Going Direct3D -> Direct3D, Direct3D -> OpenGL, and OpenGL -> OpenGL work fine.
----------------------

I also have found that Direct Mode is considerably slower in both OpenGL and Direct3D mode. I am making sure that the mirrored window does not overlap a task bar. Direct Mode works fine on other games/demos where it is supported. I don't have any technical data on this right now, except that I am still using the deprecated ovrHmd_GetEyePosePerEye().

I have found some other minor issues as well, but I want to really dig into them first to make sure they are not my fault! I will post back later once I've investigated further on this side.

Computer Specs:
Windows 7 x64 latest updates
AMD HD7970 with 14.7 RC3 Drivers
Intel i3570k @ 4.4GHz
8GB RAM
5 REPLIES 5

rezanourai
Honored Guest
Can you clarify if you are fully shutting down the entire process in between, or just shutting down LibOVR and then reinitializing it for D3D within the same process?

ovr_Initialize must be called prior to creating any D3D or GL objects, and shut down only after destroying all D3D/GL objects. I believe we've added an error return + debug output message when these conditions aren't met.

I'm currently trying to reproduce your issue here to investigate. Thanks for reporting this.

cybereality
Grand Champion
Thanks for the feedback. This is just the kind of stuff we need to know about.
AMD Ryzen 7 1800X | MSI X370 Titanium | G.Skill 16GB DDR4 3200 | EVGA SuperNOVA 1000 | Corsair Hydro H110i Gigabyte RX Vega 64 x2 | Samsung 960 Evo M.2 500GB | Seagate FireCuda SSHD 2TB | Phanteks ENTHOO EVOLV

cegli
Honored Guest
Thanks for looking into this!
"rezanourai" wrote:
Can you clarify if you are fully shutting down the entire process in between, or just shutting down LibOVR and then reinitializing it for D3D within the same process?

ovr_Initialize must be called prior to creating any D3D or GL objects, and shut down only after destroying all D3D/GL objects. I believe we've added an error return + debug output message when these conditions aren't met.

I'm currently trying to reproduce your issue here to investigate. Thanks for reporting this.

I believe I am:
1. Calling ovr_Initialize()/rest of the flow before creating any D3D/GL objects.
2. Destroying all D3D/GL objects.
3. Running ovrHmd_Destroy/ovr_Shutdown().

It's open source code I'm building on top of, so there's always the chance that something on some thread is happening that I'm not aware of, but I pretty much put the VR init things right at the very beginning on the game launch, and the VR destruction right at the very end.

If you have any problems reproducing it, you can always try building our latest version of Dolphin below. It's pretty simple to build in Visual Studio 2013, and should show the problem right away. There's a lot of code in there though, so if you can get it working with a smaller test, that may be easier.

rezanourai
Honored Guest
It appears the issue is if the same process tries to tear down one rendering stack (ex: GL) and then reinitialize with another (ex: D3D) we don't fully work in all cases (ex; Gl -> D3D, but we work the other way).

I've created a task to track this, but given that it's not a common case for apps to use 2 rendering architectures and expect hot-swap between them, it doesn't meet the bar for squeezing into this release. Exiting the application and relaunching it afterwards should work around the problem.

We'll get this prioritized accordingly and fixed in a future release. Thanks again!

cegli
Honored Guest
"shaver" wrote:
To be super clear, does the process exit between GL and D3D?


Sorry for the late reply! No, we close down all the GL/D3D stuff, but the process remains. It works fine if I close the process between GL->D3D.

"rezanourai" wrote:
It appears the issue is if the same process tries to tear down one rendering stack (ex: GL) and then reinitialize with another (ex: D3D) we don't fully work in all cases (ex; Gl -> D3D, but we work the other way).

I've created a task to track this, but given that it's not a common case for apps to use 2 rendering architectures and expect hot-swap between them, it doesn't meet the bar for squeezing into this release. Exiting the application and relaunching it afterwards should work around the problem.

We'll get this prioritized accordingly and fixed in a future release. Thanks again!


Yep that's exactly what I've found! No worries, I know it's not a super common use case :). Great work tracking it down!