Khronos Frequently Asked Questions

OpenGL

Will GLSL be the standard shading language for Vulkan?

Vulkan contains no normative reference to any high level language specification. The only thing that a Vulkan implementation requires is the ability to accept shaders in the SPIR-V format. We have defined for the convenience of the developers, an extension to GLSL to allow it to generate Vulkan compatible SPIR-V (9:40) but we pose no barrier, we intend to encourage other mechanisms of generating valid SPIR-V. The SDK is a set of tools which you can use to validate whether a SPIR-V program is legal for Vulkan and should be accepted by a Vulkan implementation. We strongly encourage developers to develop their own language ports or their own tools such as graphic tools, graphical tools such as the SDK to generate languages using other high level formalisms.

Can OpenGL functions be used with the Vulkan API?

The short answer is no. For all the hidden state that is being carried around by OpenGL implementations to interact with the very explicit exposed ... to Vulkan is a pretty normally technical problem.There is an Nvidia extension to allow that. My guess is that it would have to be fairly hands-off, and UP explicitly passing surfaces between one side and the other, and otherwise maintaining them as pretty independent entities.—I think the question is could you use GL and Vulkan in the same application and without interrupt you could render to different Windows and those kinds of things, with GL and Vulkan, but you would need the NVIDIA extension to mix rendering.—In our implementation, we actually package the OpenGL and Vulkan drivers in the same DLL, and so you can certainly use both of them in the same process, and that would be true, even if they weren’t in the same DLL. You can use them independently. It’s sharing data or sharing state between them, requires an extension to one or both APIs. Although, for multi-window applications, there is no real problem.

What about proper text support (high quaility LCD) that is lacking in OpenGL?

Our initial goal in Vulkan 1.0 is to address the functionality of current GPUs and current drivers. So we have stressed the hardware capabilities as opposed to anything that you could handle through middleware. So high quality text rendering, anything involving fonts, is out of scope for this level of activity. We think it’s ideal for layered implementations and layered APIs that would run on top of Vulkan.

Will we be able to mix OpenGL rendering with Vulkan rendering?

Nvidia at least has mixed OpenGL and Vulkan rendering and has published the extension that allows this. One of our first extensions is a pretty limited form of interop where you can synchronize between an OpenGL context and a Vulkan queue, and additionally copy image content from Vulkan to OpenGL. Interop is certainly a technical possibility, and I expect we’ll probably have additional extensions in the future.

Are shaders in Vulkan written in the same way as in OpenGL or GLSL?

In OpenGL, the only choice for writing shaders is to use GLSL, and pass the GLSL into the driver. In Vulkan, you can also write in GLSL, and use an offline tool chain to translate that to SPIR-V. (Standard Vulkan only accepts SPIR-V). There are plenty of other choices, and there will likely be lots of people experimenting with different languages and different kinds of tool chains, middleware, and game engines as a variety of ways of generating the SPIR-V that goes into the driver. So you can do it the way it works for OpenGL, or you can experiment with the new and different ways. Some of those can be linked directly into an application, so you don’t have to rely solely on offline support. We usually call it off-driver support, but you could do it online by using a side tool real-time. It just isn’t part of the core Vulkan drivers stack.

What performance improvements might a well-tuned OpenGL application for games / simulation expect with a switch to Vulkan?

If your application is well-tuned and is GPU-bound at present, you’ll perhaps notice some reduction in CPU power. The CPU may be idle more often, but you’re not going to get a graphics difference, because the pipeline is the pipeline. If it’s maxed out now, it will be maxed out in Vulkan. But you might expect to get many of your CPU cycled back, so you may have the opportunity to enhance your rendering using some offline sort of CPU techniques. You may get more out of that if you choose to give back some of that. If you are happy that you’re using less power and your CPU is idle more of the time, that’s great, but you may choose to add some techniques back in outside the rendering pipeline, so that you can still get better results, but you’re doing it in a combination of CPU and GPU work.

As a beginner, is it better to learn OpenGL before Vulkan?

If you’re really new to 3D graphics, probably OpenGL, or one of the traditional APIs, is probably the best place to start learning and not get totally swamped by all the details that you need to drive Vulkan. The interesting thing to me is over time, the middleware layer could evolve to potentially provide some interesting learning platforms over time. Right now, if I was starting from scratch, I would probably still start with OpenGL.

Can OpenGL be developed as a layer on top of Vulkan?

It is certainly feasible. There are rumors of projects for running OpenGL on top of Vulkan, but we don’t have any direct knowledge of them. This would have all of the issues that writing an OpenGL driver straight to the metal would have in accessing all the hardware features. If you wanted to get comparable performance, you can do it because Vulkan is that level, but you would be signing up for duplicating all that cleverness that has evolved inside the major IHVs over the years.

What is the relationship between SGI and Khronos Group?

SGI is not a member of the Khronos Group. Khronos licenses the OpenGL ES trademark from SGI. Khronos is authorized to run the OpenGL ES adopter program.

Is an OpenGL ES adopter required to comply with OpenGL licensing when they have an OpenGL ES conformant product?

No.

safety