Forum Discussion
OpenGL working with Direct HMD mode
Currently OpenGL isn't supported in Direct HMD mode with the Oculus SDK. Unfortunately this causes serious issues since unless you set the Rift as your primary monitor, you will end up having some form of v-sync and/or judder issues. Direct3D doesn't seem to have these problems when running in Direct HMD mode. OpenGL also currently doesn't support some of the functionality that's available in Direct3D, such as Overdrive.
To solve these problems I've created a demo showing how you can use Direct3D to interact with the Oculus SDK, but still use OpenGL for your rendering. The linked code is an updated version of this demo which has been stripped down to the bare minimum. It uses GLFW for OpenGL window creation and management. It actually creates two windows, one for an OpenGL context, and the other for a Direct3D context. The Direct3D window is kept hidden behind the GLFW window at all times through a little bit of Win32 trickery.
I'm considering creating a custom version of the Oculus SDK that will automatically use this technique if OpenGL is selected as the rendering API, direct HMD mode is active, and the extensions are supported on the system.
To solve these problems I've created a demo showing how you can use Direct3D to interact with the Oculus SDK, but still use OpenGL for your rendering. The linked code is an updated version of this demo which has been stripped down to the bare minimum. It uses GLFW for OpenGL window creation and management. It actually creates two windows, one for an OpenGL context, and the other for a Direct3D context. The Direct3D window is kept hidden behind the GLFW window at all times through a little bit of Win32 trickery.
I'm considering creating a custom version of the Oculus SDK that will automatically use this technique if OpenGL is selected as the rendering API, direct HMD mode is active, and the extensions are supported on the system.
4 Replies
- Thanks for this work!
I assume this would have a rather significant performance hit, no?
You are essentially creating two contexts to the graphics card and copying from one buffer/memory location of some kind to another, which Oculus is again doing behind the scenes with their stuff, every frame.
Great for small projects but that is two/three hits, every frame, right off the bat.
Wish Oculus would fix this so that we can avoid these types of nasty workarounds which kill framerate. "tmason101" wrote:
I assume this would have a rather significant performance hit, no?
You are essentially creating two contexts to the graphics card and copying from one buffer/memory location of some kind to another, which Oculus is again doing behind the scenes with their stuff, every frame.
I doubt this would impose a serious performance penalty. While you're creating two contexts, you're essentially using them for discrete tasks. Previously, OpenGL would have been used for both rendering and distortion. Now OpenGL is used for rendering, while Direct3D is used for distortion. Consequently, you're actually reducing the amount of work the OpenGL context has to do.
Furthermore, I doubt that any memory is being copied at all. I don't think nVidia would be so crude as to make a special OpenGL texture area and copy the data to Direct3D texture when OpenGL writing was complete. Instead, nVidia has all the freedome they would require to make sure that OpenGL and Direct3D are sharing the exact same memory. Even if they weren't, the copy would be a block to block transfer directly on the video card, much faster than CPU to GPU transfers.- Thanks for the information; I was wondering why my OpenGL application wasn't sending anything to the Rift, despite rendering fine.
I'm considering using your solution, but I'm concerned about the resulting increase in complexity and/or compatibility issues. Has Oculus said anything about when this will be fixed? "Philpax" wrote:
Thanks for the information; I was wondering why my OpenGL application wasn't sending anything to the Rift, despite rendering fine.
I'm considering using your solution, but I'm concerned about the resulting increase in complexity and/or compatibility issues. Has Oculus said anything about when this will be fixed?
Nothing really beyond 'soon'. Given that they have more work to do they seem to be prioritizing the Windows/Direct3D path, so who knows how many resources are being diverted to OpenGL. Also, their mechanism for driver interjection isn't what I would consider the most stable approach in the world. Even if they get a release out, there's no guarantee how widely effective it will be.
