Ah good – that’s great for us because the GLSL problem happened in 10.25, which is what’s on DVDs right now.

I have been following Vulkan as closely as possible, and I read the entire Mantle programming guide (which is now freely available) to get some sense of the IP they were starting with. You are correct: Vulkan moves resource management, memory management, and threading responsibility to the app. This is almost entirely a good thing; applications typically know a lot more context about these things than the driver does.

For example, X-Plane’s threading model is built such that a lock is -never- needed between a resource being loaded and a resource being drawn. OpenGL, however, is required to apply locking _just in case_ the app is thrashing between drawing and uploading.

So one thing we could do would be to create an emulation of the basic OpenGL calls we use (e.g. create-a-texture, draw a VBO) in Vulkan. When Vulkan is available, those implementations could be much faster than OpenGL because we could implement the simpler, more direct problem.

For example, X-Plane -never- mutates a texture’s size. OpenGL has to check for this and handle it, but we don’t use it. So our Vulkan layer’s texture builder would be much simpler, and could skip a lot of sanity checks and special cases.

The challenge for us (and anyone who developers a game/rendering engine) is the capabilities that Vulkan can do that OpenGL just can’t. Because Vulkan’s threading model is “don’t hurt yourself”, it is possible to create a rendering engine that spreads the CPU work of building the frame over several cores and then assembles the results later.

There really is no equivalent of this in OpenGL, so an application that wants to do “multi-core render” would have to support two very different code paths in the rendering engine – the “multi-core” draw path and the “single-core” draw path.

That kind of -fundamental- split of capability is what drives up the cost of development – it’s literally building two engines, and each one is likely to have very different bugs, require separate testing, etc. That’s a lot harder than having Vulkan provide a “fast GL” by taking advantage of what we know about the sim.

In terms of time: I believe we could probably put together Vulkan-based rendering that replaces OpenGL in weeks. The reason I think this is that our iPhone app used to be GLES 1.1 and we had to (at the last minute) change it to GLES 2.0 for performance, which meant replacing a chunk of Open GL 1.1 (texture combine, matrix transform, lighting) with our own code. The entire change took about a day of coding to get something that worked just about as well. And what made the ‘port’ so quick was that we only had to implement the parts of tex-combine, matrix transform and lighting that we -actually used-. GLES 1.1 has spot lights, but we only use directional lights – time saved. We never use a modelview matrix that’s not orthanormal – time saved.

I hope someone will build a complete GL 1.x on top of Vulkan – the result would almost certainly be more reliable than ‘real’ OpenGL, because the OpenGL API is too complicated to be properly tested by the IHVs. But a full GL 1.x is a huge project — tons of texture options, line stipple, lighting options, etc.

What we would need to do would be a lot simpler: shaders, VBOs, UBOs, textures, and framebuffers…that’s pretty much it. It’s doable.

As far as I understood Vulkan proposes an approach where much of the memory and thread management to generate command buffers, previously done by the graphics driver, would be moved to the application itself. I don’t know if you plan to migrate to Vulkan somewhere in the future, but I imagine it would be one heck of an overhaul to the X-Plane source code…

We need to run on Intel. We don’t need to run on Intel at maxed out rendering settings.

So Intel’s not holding us back in terms of what we can plan for at top settings; it’s necessary always to run on a spectrum of hardware.

Hmm
So does this mean XP will always be catering to being accessible on Intel HD graphics?

ugh. That’s like tying a racing boat to an anchor forever.

Sorry, I just wanted to express my point of view, probably overdone.
I just want to X-Plane 10 was the most advanced in the world, both graphically and in terms of productive aircraft simulator.

Kirill: please limit yourself to _one_ comment for each blog post. If you want to reply, reply -to- that post. Please do NOT post to the blog multiple times. (I have had to delete many of your ‘extra’ post copies.)

Three issues:

1. We have a minimum set of hardware requirements that we shipped X-Plane 10 with. While we are still in the v10 run, we are not going to raise those hardware requirements.

If we raise our minimum API version to 3.0 or 4.0 we won’t be able to run on that hardware. So no bump to 3.0 or 4.0 minimum in v10.

2. It’s important that X-Plane be demo-able to users who have never done flight sim. A -lot- of those users will have Intel HD graphics on their CPUs and nothing else. So the lowest-end Intel GPU we want to support really matters; if we crank the spec up to GL 4.0 minimum, it’s going to be tough for people to try X-Plane without buying a new system first.

3. On OS X, you can’t get the ARB_compatibility extension with GL 3.0 or 4.0. And without ARB_compatibility, pretty much every single plugin will break. So we use GL 2.1 + extensions.

RE: efficiency, there’s no question that the rendering engine would be -easier- to support if we required a GL 4.0+ renderer. But it would also run on a lot less hardware; those multiple cases in the sim are serving multiple hardware ‘buckets’, and that’s pretty much just something we have to do as part of our business. We can’t mandate a super-computer for every user.