Best Answer

Vulkan is a newer rendering pipeline, it's an alternative to OpenGL. It's far more modern and can give better performance in games. But it requires a fair bit of effort to support, it's not an automatic thing, the developers need to rewrite their graphics engine.

In X-Plane 11.50 they added an optional Vulkan renderer. There's a checkbox to turn it on in the graphics settings page. It runs better and doesn't have the bug that stops X-Plane from running on Oculus runtime v17.

Sorry but it's kinda hard to say (looks like a display port problem, but who knows?) since you do not give your PC specs, the version of xp11 you are using (v11.41 or 11.50b6 beta, your Oculus version (v16 or v17ptc), your nvidia driver version, and whether or not you have managed to run xp11 in vr before.

Just a wild guess of what to do but I would make sure your nvidia drivers are reasonable up to date (I'm using 442.19), your headset cable and pc connections are firmly connected (maybe unplug and plug them in again, maybe even try a different usb port and/or DP.

You could send your last xp11 logfile to Laminar and see if they can help sort this out. Good luck mate.

Edit; Also, make sure that if you are using any super sampling to take this back to 1.0 to begin with. If it is too high xp11 can often hang/shutdown when going into VR. Also, make sure that your xp11 settings are not too high as well. What you want to start off with is 2D xp11 settings that give you about 70-80fps on your monitor.

Something really wrong with XP11.5 beta and Rift S. I have taken out all plugins and custom scenery from XP11 along with preferences and validated files in Steam. Repaired (and re-installed Oculus software) and RiftS does not want to work with Xplane 11.5x, or vice versa. I understand XP11 does not run via SteamVR like other headsets, rather via the Oculus software directly. Oculus and Laminar need to talk about this, one killed the other. I have submitted tickets to Laminar but I now going back to 11.41, 11.5x not ready from primetime, at least if your fly with an Rift S headset.

Works fine with my Rift cv1. Maybe make sure you are not on an Oculus PTC update. Also check your gpu driver is reasonably up to date. The only issue I have is that it will not exit properly and I need to use task manager to kill it. Been doing this since Oculus v13.

If xp11.41 works ok just stick with that until 11.50’gets out of beta, especially if you are using any xp11 plugins.

I thought I'd take a look at what X-Plane is doing with the Oculus sdk using my Oculus Injector. Umm, why is X-Plane loading the Oculus runtime library 375 times in a row before I've even ticked the "Enable VR" button?

I'm going to have to change my hooking system to avoid maxing out hooks, no other vr game I've tested does this.

Edit: while writing this it's already reached 3455 calls to load the oculus library. Is it just reloading the library every frame?

I thought I'd take a look at what X-Plane is doing with the Oculus sdk using my Oculus Injector. Umm, why is X-Plane loading the Oculus runtime library 375 times in a row before I've even ticked the "Enable VR" button?

I'm going to have to change my hooking system to avoid maxing out hooks, no other vr game I've tested does this.

Edit: while writing this it's already reached 3455 calls to load the oculus library. Is it just reloading the library every frame?

Where are you looking to see this? Nothing obvious in my xp11 log files. If there is anything you can sent to Laminar support to help them sort this out that would be great. Thanks mate and cheers.

The Oculus Injector that I mentioned above is my project that injects code into the Oculus SDK allowing me to intercept any call made by a game, modify what it does or log out what it's parameters and result were. It's what I've been using to do things like trick Beat Saber into thinking my DK2 has Touch controllers (but they are really xbox thumbsticks).

Repeatedly initializing and shutting down the oculus sdk 25 times a second is not normal behaviour for a VR app. Also maybe they should update their oculus sdk, they are requesting a runtime from 2 years ago. That shouldn't hurt, I don't think the application binary interface has changed between then and now, but if it had...

I need to add some more logging to see if they are doing anything else between the initialize and shutdown. (I can't tell why they do anything, all I can see is what they are telling the sdk to do, and I need to manually write code for each function I want to check).

Interesting side note: Audica and Pistol Whip both use runtime 1.37. Beat Saber uses 1.45. All three do the same procedure (they are all Unity apps): initialize the sdk in invisible mode (has full access but no rendering, what I use for Auto Oculus Touch), shut it down a fraction of a second later, then initialize again in focus aware mode for the actual game. I'm guessing the first invisible call is to check connected hardware or something.

(Still takes effort to add each function and more to do something custom with each one, but it's much easier than before)

It looks like after about 37 init / shutdown cycles X-Plane does an initialize with focus aware. It then creates a session, checks the session status a few times, destroys the session, then goes back to the init/shutdown loop for the rest of it's lifetime.

I've hooked into a LOT of sdk functions now (almost every one, I just left out some like guardian boundary querying and haptics for now).

Ok, some progress.

When I enter X-Plane everything is fine. I click on Settings and it goes to the VR device page with the VR checkbox off. That's when it starts spamming initialise/shutdown.

When I click to enable VR mode, that's when it does a create session.

It then does 3 calls to ovr_CreateTextureSwapChainGL. But the third one fails with an error of "wglDXRegisterObjectNV failed".

It then calls ovr_CommitTextureSwapChain 3 times, the second time fails with the error of "Null chain pointer provided."

Next it sets up tracking origin style and waits for the next frame to start (using ovr_WaitToBeginFrame).

It does a ovr_BeginFrame, then a couple of misc calls.

Then an ovr_EndFrame, which fails with "NULL texture provided to ovrLayerType_Cube. Disabling layer 0"

Next it checks for inputs and waits for another frame.

It tries to do the ovr_BeginFrame again, but it now fails with "BeginFrame called before EndFrame." because the previous ovr_EndFrame failed.

Then it tries ovr_EndFrame again, which now fails with "EndFrame called with different frameIndex from BeginFrame."

It was about to try a third time, but it crashed at that point.

So long story short, X-Plane is trying to create 3 textures for the swap chains, but 1 failed for some reason. It doesn't validate it, just tries to use the broken texture, which breaks the EndFrame (which submits the frame to the runtime for distortion and display). That then breaks the requirement of matching begin/end pairs and it all falls apart.

Next I'm going to get it to tell me more details about the textures it's trying to make.

The ovr_CommitTextureSwapChain that is failing is trying to use type ovrTexture_Cube (to make a 512x512x6 cube map), but the SDK header says "Must be ovrTexture_2D". I don't know if that is still a valid requirement.

Anyway, turns out if I go into the graphics settings and turn on Vulkan mode, it runs fine. I'm in X-Plane 11.50b9 with Oculus v17. It's only the OpenGL path that is failing, the Vulkan path seems ok (and is supposed to give better performance anyway).

I've only tried 11.50b9 with OpenGL in VR once and the performance/visual quality was terrible compared to Vulkan. However, it did seem a lot worse than what I would have expected based on using it with 11.41. So, maybe because of the coding issues you've discovered.

Between Vulkan and improved stock scenery xp11 is looking and working very well for me. Hope to see better multicore utilization, hence better performance in the near future, esp. with my i9 9900k.

Except for the shutdown bug (since v13) xp11 looks and performs very well with my Rift cv1. However, xp11 looks even better with my Vive Pro as do all my flight/racing sims (and shuts down xp11 properly as well). So my poor old cv1 is now relegated to most Oculus store games and Steam/VivePort games that benefit from its great touch controllers (at least 50% of these right now).

I'll send a bug report to Laminar once I write up some details (there's going to be some explaining to do as to what I was doing).

Yeah, that shut down bug is still there (in GL or Vulkan). There's no Oculus SDK calls going on at that point. The swap chain textures were all destroyed and the sdk shut down, so it doesn't seem like a resource issue. It's much harder to see what's up at that point.

I wonder if it's related to how X-Plane loads the Oculus runtime library hundreds of times? There are supposed to be a matching number of Frees, but I'm not intercepting that. (Libraries are reference counted, if you load a library 10 times you are supposed to free it 10 times).

Have the same issue here. I can get it to work for one flight session by running OculusSetup.exe's repair tool, but the Oculus app bugs me to update right after the repair is done, even though the Rift S firmware is still 2.2.0. Once the computer restarts or wakes from sleep the Oculus seems to load up new firmware and I have to run the repair tool again to get it to work.

I tried using the OculusRoomTiny(GL) demo that comes with the oculus sdk. Using the same numbers I get exactly the same error.

So I modified the type. I intercepted X-Plane's call and changed the type to 2D instead of Cube. Everything now ran fine!

Looking at my logs, the cube map is only used for a single frame as soon as you enable a VR headset, then never used again. But if that one use breaks, it makes every later frame fail too.

The SDK has been saying to not use ovrTexture_Cube since at least 1.35 (maybe earlier). It's possible that it's been deprecated for ages and v17 finally removed it. Since X-Plane is so out of date for oculus sdks (they used 1.23) they might not have noticed that ovrTexture_Cube hasn't been allowed for a while in openGL.

I've asked on the dev boards about it, but the odds of a response there are pretty low these days.

Oculus v17 rolled out to me today. All seems to work fine. During the installation I did not see any new driver install windows. After it finished installing I shutdown my PC (full, not sleep or hibernate btw). Then restarted my pc and fired up my Oculus Rift cv1 w/2x sensors.

I tried a couple Oculus Store games (including Lone Echo for ~30 minutes), a couple Steam games, and a couple VivePort games. Everything ran good as ever, no problems. Also, all my Oculus devices properly reported usb 3.0 in the green.

Although I don't really use my Rift for xp11 anymore, just my Vive Pro, I thought I'd give it a go anyway. I always startup xp11 with my Rift by calling up the Oculus desktop panel, then use my mouse to startup with a shortcut on my taskbar. 11.50b9 Vulkan started up no problems and I ended up in the usual startup hangar facing the menu boards. Selected a flight and all worked perfectly. Had a good fly around Chicago at dawn and everything was a very smooth 45-55fps. The good old Oculus shutdown bug is still in effect and I still need to use task manager to kill it.

So, for me, v17 is working fine. Thank goodness!

ASIDE: In the past I have occasionally had xp11 hang either during the wait to get to the hangar and/or when I tried to start a new flight. In all these cases this was due to using too high xp11 and/or super sampling settings. Once I lowered these (xp11 by starting up in 2D monitor mode), SS for me with OTT, all worked fine. For those having issues starting up xp11 in VR you might want to consider this. Good luck mates and cheers.

Update;Someone on the xp11 forum asked me to check out how Oculus v17 works with the last stable version xp 11.41. Fortunately I had saved a full backup of this prior to entering the 11.50 beta program so this was pretty easy to do. Well, I hate to say it but xp11 crashed every time I tried to go VR with my Rift cv1. It worked ok in non-VR mode though. So, since my backup was done prior to entering the xp11.50 beta program and this was with Oculus v16 I'd have to say it def looks like an Oculus v17 related issue. I tried it again with the latest xp11.50b9 and it worked perfectly again (but I still needed to kill it with task manager).

Just for fun I tried 11.41 with my Vive Pro and it ran perfectly (and shutdown perfectly as well). It was a useful exercise because it demonstrated 2 things;1) xp 11.50b9 Vulkan is far superior to both the old OpenGL 11.41 and even 11.50b9 in OpenGL mode, and2)xp 11.50b9 Vulkan looks and performs much better with my Vive Pro.

So, looks like I'll be continuing to use my Vive Pro with all my flight/racing sims, Google Earth VR, and Aircar. My good old cv1 will still see lots of action with my Oculus store games and a few of my Steam and VivePort games that benefit with their touch controllers.

I feel really bad for you guys that only have Oculus PCVR headset(s) because if your PC cannot handle xp11b9 you are kinda screwed for now. If you can run 11.50b9, preferably in Vukan mode, you should def do so imho. Once I observed the differences I know I'll never go back to 11.41 OpenGL. Good luck and cheers.

Edit; Someone on the xp11 forum just informed me that while xp11.50b9 will work fine with the Rift cv1 (and I assume Rift S) in Vulkan mode, it will not work with 11.50b9 in OpenGL mode. Probably not surprising since xp11.41 is OpenGL. Anyway, I'll take his word on this. I don't fancy firing up my Rift cv1 ever again to try this, lol!

It definitely seems what has happened is that X-Plane used an Oculus SDK from 2 years ago. Every SDK from maybe 1.5 years ago has said not to use cubemaps for this GL function. X-Plane never read that because they are out of date and kept doing it.

Although... the actual fail is happening inside of wglDXRegisterObjectNV, which is a Nvidia extension to OpenGL, included in their driver. It would be interesting to see if AMD also has this problem. Is Oculus calling wglDXRegisterObjectNV incorrectly, or has wglDXRegisterObjectNV stopped working?

I gave Laminar a detailed bug report. Hopefully they'll take it seriously. There's little chance my Oculus developer forum post will get a response, there's almost no oculus developer contact for smaller developers since Imperativity left. Laminar has a better chance of getting through to the Oculus dev team than I do.

I gave Laminar a detailed bug report. Hopefully they'll take it seriously.

Well, looks like they didn't. Their response was that it's Oculus' fault. They've reported it and are waiting for Oculus to fix it (the thing Oculus has been saying for 1.5 years to not do, but X-Plane keeps doing).

Someone on the X-Plane forum said they reported it to Oculus and was told it's Laminar's fault for not updating their code.