We are LunarG, funded by Valve to improve SteamOS on Linux, the Vulkan API and SPIR-V. Ask us anything!

Would it be possible (and desirable if possible) to implement OpenGL on top of Vulkan, so that we get a vendor neutral OpenGL implementation that can be used by any driver that supports Vulkan? For me that sounds better than having good, bad and mediocre implementations of OpenGL across vendors that have to be maintained and fixed per vendor .

We think this is a really good idea...but we don't think it is easy. We expect to see native OpenGL implementations continue for a while.

How many lines of code would it take to perform a "Hello Triangle" in Vulkan (compared to modern core OpenGL)? Of that, how much would you say is reusable?

We think about 600 lines of code, but you will reuse that code all the time. Should be available in open source libraries making it easy to reuse.

Thanks again guys! We had a blast.

One of the really bad itches with the Linux OpenGL ABI is, that the libGL.so in the linker path is to be provided by the driver. This makes it close to impossible to use multiple GPUs of different vendors in the same runtime environment (it has always been possible to launch programs in different REs on the same system (different X server, different linker path or container), thereby linking to different libGL.so).

In light of that, the mechanism of Windows, using OpenGL ICDs that are hooked into by opengl32.dll is a much easier to work with approach.

Vulkan has the clearly stated mission goal for allowing seamless heterogenous multi GPU support. While I can think of a number of ways, this can be implemented, I'm curious on what your approach on the actual implementation would be?

(EDIT: missing words added).

We are developing a common loader to work across multiple simultaneous vendor's GPUs. This is not just for our driver, or a handful of select vendors. This is designed to address the cross vendor challenge you identify so well here.

In the Khronos session at GDC they mentioned the concept of a "loader library, initialized with vkCreateInstance()", which to me sounded a lot like a jump-table based approach similar to how OpenGL operates on Windows and how the new OpenGL ABI on Linux was proposed

You are on the right track...

Thank you for doing this AMA.

• How are you envisioning extension support for Vukan? Will it be similar to OpenGL where you check for availability and then GetProcAddress the entry points?

• In the Khronos session, it was explained that you would have to manually opt in to any extensions. Does that mean that, for example, if an extension provides an additional texture format, the driver has to validate every time textures are created whether the format extension was opted-into or not? Or is the behavior in such a case simply undefined and responsibility pushed to the debug layers to catch this?

• What additions to the Intel DRM driver were necessary to make it work with Vulkan?

• What are "descriptor set pools"? From what I have read elsewhere, it's a special kind of memory heap to allocate descriptor sets from, but why would you need to reference the pool explicitly? In what kind of scenarios would you be using multiple pools?

• What was the rationale behind pipeline objects being serializable, what is the use case for this? Are serialized pipeline vendor/driver/device(context) specific?

• Why are you using the two terms "event" and "fence" if they're more or less the same thing? Isn't a fence just an event signalled automatically when a commandbuffer has finished executing?

• What does "querying the GPU memory requirements for images" entail? It sounded a bit like you would need to allocate memory from multiple pools for one image, is that the case? And when would an image require a different pool than usual, is it based on size?

• Will there be a distinction between textures and renderbuffers as offscreen rendertargets in Vulkan, or does that not make sense anymore on modern hardware?

That's all I could think of off the top of my head, thanks in advance for answering.

What additions to the Intel DRM driver were necessary to make it work with Vulkan?

We did not have to make any changes to the kernel DRM, but there are enhancements that are needed for improving performance.

When you say performance "needed" to improve, are you talking about some bottlenecks that cause it to currently underperform compared to OpenGL, or about optimizations that will blow OpenGL out of the water?

The OpenGL driver can use the 2D engine, but we can not in the way Vulkan API requires due to limitation in the current DRM driver. That said, we have gotten alot of mileage out of the current DRM implementation.

What are "descriptor set pools"? From what I have read elsewhere, it's a special kind of memory heap to allocate descriptor sets for, but why would you need to reference the pool explicitly? In what kind of scenarios would you be using multiple pools? What was the rationale behind pipeline objects being serializable, what is the use case for this? Are serialized pipeline vendor/driver/device(context) specific?

Really good questions...these are still being actively discussed. Join Khronos and help define the answer.

In the Khronos session, it was explained that you would have to manually opt in to any extensions. Does that mean that, for example, if an extension provides an additional texture format, the driver has to validate every time textures are created whether the format extension was opted-into or not? Or is the behavior in such a case simply undefined and responsibility pushed to the debug layers to catch this?

No, it's not every time it is created. It is only at CreateDevice time.

Sorry, but it seems that you misunderstood my question. I was not asking where the act of opting into extensions was done, but whether the driver would have to validate the usage of extensions at run time because they might not have been opted in for.

Specifically what I'm thinking about are scenarios where the distinction between opted in and opted out would be more code than simply telling applications "if you don't want to use it, don't use it"; see my example about texture formats.

The intent is to avoid unintended side effects. If you do not specify extension behavior, the app will not see that extension behavior. The driver might do the run time check at the driver level...or as a validation layer. In the latter case...there won't be any production run time overhead.

The intent is there will be validation layers both GPU independent and dependent that catch issues like this during development.

What does "querying the GPU memory requirements for images" entail? It sounded a bit like you would need to allocate memory from multiple pools for one image, is that the case? And when would an image require a different pool than usual, is it based on size?

The intent is the application manages GPU resources and the driver tells the app what GPU resources it needs for an object.

Will there be a distinction between textures and renderbuffers as offscreen rendertargets in Vulkan, or does that not make sense anymore on modern hardware?

Too early to tell...it's a topic of discussion.

How are you envisioning extension support for Vukan? Will it be similar to OpenGL where you check for availability and then GetProcAddress the entry points?

Yes, applications are required to specify extensions they want to use.

How much simpler is a driver that only implements Vulkan compared to a driver that only implements OpenGL, all other factors being the same?

Implementations will vary a lot...depending on architecture, etc: 77.2% :-) The compiler frontend doesn't have to be there...which is about 40k lines of code.

Will Vulkan be able to use the VRAM of both cards in a multi GPU system? Could NVIDIA and AMD cards work together making SLI/Crossfire obsolete?

That is the target...but it will place a significant effort on app developers to make this work well.

Hi!
Can Vulkan improve performance of non-gaming applications as 3D modelers or CADs (huge polygon count, near zero lighting effects and often no texturing)?

Yes, NVidia gave a CAD demo at GDC using Vulkan

Cool! So, something like NVidia's NVPath extension could be written for Vulkan?

Sure.

How hard will it be to move codebases between OpenCL and Vulkan? Will OpenCL C++ be able to compile to and run as Vulkan shaders? From the SPIR-V spec, I saw that programs have specific capability sets, including one for CL kernels and one for VK shaders, despite both APIs using SPIR-V.

What kind of extensions can we expect to see for SPIR-V, and will it be supported by other APIs than OpenCL and Vulkan?

How much do you think existing game engines and toolkits will have to change to reflect the full flexibility of Vulkan? Will we need entirely new abstractions, and how hard is it to support the old ones?

How hard will it be to move codebases between OpenCL and Vulkan?

They are still different operating environments, with different programming models, but convergence will occur over time. Tools can be shared.

What kind of extensions can we expect to see for SPIR-V, and will it be supported by other APIs than OpenCL and Vulkan?

We think it would be great if SPIR-V is supported by more API's than just Vulkan and OpenCL. Existing OpenGL extensions will be added to SPIR-V, if needed by Vulkan.

WebVulkan? Do you foresee any additional challenges in potentially bringing Vulkan to Javascript in contrast to WebGL/OpenGL? JS is ultimately single-threaded.

It's been discussed...we'll see.

Hello,

so I heard you guys wrote the Linux Intel Vulkan driver. How many source lines of code approx. is the userland implementation of that?

The driver is substantially smaller than the Mesa driver. About 27k lines of code for the driver (not counting the compiler)

To and from SPIR-V added about 8k lines of compiler code.

I guess the compiler is something that can be easily shared between drivers (open source AMD for example) without extra code?

GLSL -> SPIR-V can be shared across ISVs.

SPIR-V -> target is vendor specific.

"Not counting the compiler" is referring to the GLSL->SPIR-V compiler and not the SPIR-V -> hardware ISA assembler, yes?

It's not counting anything in the compiler stack

Hi!

How do you see Vulkan affecting Linux graphics stack in the light of OpenGL → Vulkan transition? For example will it fit into Mesa project or produce something new? Also, what can happen with APIs like EGL which assume OpenGL stateful architecture, when Vulkan presents new stateless approach? Will EGL have to be replaeced with Vulkan based alternative? And how might that affect projects like Wayland?

Thanks!

OpenGL will live on...it serves a key purpose. EGL will live on with OpenGL. The Vulkan window system interface is still being discussed. Vulkan is targeted for explicit control over the GPU for minimal overhead in the driver.

The Vulkan window system interface is still being discussed.

That's interesting.

OpenGL will live on...it serves a key purpose. EGL will live on with OpenGL.

What purpose do you see for OpenGL in the future besides supporting legacy applications? I got an impression that Vulkan proposes new application design that is geared towards increasing hardware parallelism, while OpenGL is restricted by design in that regard. So I'd assume that for any new projects it's advisable to use Vulkan (and build whatever is needed on their own on top of that). I.e. no matter whether it's games or graphics servers and windowing systems. Or you consider OpenGL useful for future projects too in some cases?

OpenGL is easier to use, so that's going to stay around for a while. We heard the comment that writing a Vulkan backend for an engine is pretty much like writing an OpenGL driver that only does what you want it to do.

How many years of programming experience does your team have on average? Also how many programming languages do you need to know on average to work on a project like this?

Team members have 15+ years on average per engineer

How does Vulcan compare to Gallium3D architecture? Would it make any sense to develop Vulcan on top of Gallium3D or use it as the basis for a Gallium3D 2.0?

We would say that Vulkan is Gallium3D 2.0...it's even more explicit than Gallium3D today.

Thanks for doing this AMA:

1. Valve as a company focuses on the PC primarily. What do you think the adoption rate of Vulkan on consoles will be? Vulkan for PC is, in and of itself, not enough of a motivation to switch of D3D for a company already heavily invested in D3D for Windows/Xbox (and PS4 has its own API).
2. Khronos is, as an organization, much more closed than other similar non-profit committees (e.g. Standard C++ Foundation) that have open mailing lists and show proposals in flight. Do you imagine this will ever change?
3. Will GLAVE be open sourced?

Will GLAVE be open sourced?

Yes!

What is your opinion of the current state of Linux drivers and its future? Especially, Mesa and Gallium3D.

Like OpenGL, Mesa will live on. It plays a vital role in our ecosystem.

More like your personal opinion, you guys have done quite a bit for the open source graphics stack on Linux. Below are some more explicit questions.

In which ways is open source graphics community stack growing now with SteamOS pushing Linux into mainstream video gaming.

When do you think Mesa will have full support for OpenGL (through 4.5)?

Do your feel that open source Linux drivers in the future would eventually be better than any proprietary ones? In my opinion, graphic drivers have become too complex for one company to create.

In which ways is opens source graphics community stack improving now with SteamOS pushing Linux into mainstream video gaming.

Getting OpenGL up to parity for Mesa is alot of work. With Vulkan we are there out of the gate.

Do your feel that open source Linux drivers in the future would eventually be better than any proprietary ones? In my opinion, graphic drivers have become too complex for one company to create.

Yes, with the caveat that there is a similar level of investment.

Do you honestly believe there will ever be a 'similar level of investment' for Linux that could possibly ever make it a mainstream gaming platform at least equal to windows?

I see many advantages of Linux but can't justify using it because it requires dual-booting because of the lack of support for games and a number of applications (particularly adobe). Especially when my mainboard takes a few minutes to post.

I think that it is very unlikely when you consider that big players like EA and Ubisoft will NEVER get behind a platform/API created by Valve.

This is all speculation...we can't really add much here.

Not sure if this question fits your expectation: Vulkan and OpenCL 2.1 both use SPIR-V as IR. Does that mean that all Vendors which will support Vulkan will also have to support OpenCL? (looking at NVidia)

No, they are different programming models.

Could parts of your Intel Vukan code be ported to windows, or does it rely heavily on some dependencies?

It's a simple matter of software...the real challenge is kernel level support...open source DRM vs closed source Windows kernel module.

Hey, thanks guys for having an AMA.

Is there a release date for the (open source) Intel Linux driver?

The day the spec is publicly available, we plan to release source code.

How does context creation work with Vulkan?

What context? :-) There are no contexts in Vulkan. Everything works on objects that are passed around across the API.

I think OP means the handle(s) to the GPUs/compute devices. Eventually the command buffers have to be submitted somewhere.

There are devices, queues, command buffers and pipelines.

In regards to the SPIR-V stack of Vulkan/OpenCL, my understanding is that the driver should directly take the SPIR-V code and JIT that directly into machine code.

If we were to use the Gallium stack as a base, would SPIR-V be intended to replace the LLVM-IL based optimizer for the driver, the TGSI compile target, or both? I realize that it was not designed to fit into that stack per se, I am merely trying to understand were it fits.

Or, is that up to the individual drivers?

SPIR-V can go on top of LLVM or TGSI. LLVM is being used to optimize in our case.

Does this mean that SPIR-V is not a good optimization target, or would the benefits trickle down?

SPIR-V is designed to be a target for device independent optimizations.

Probably the biggest question right now: when is Vulkan expected to ship and on what OS's/hardware? I understand that you might not know everything, but you're showing off this really cool stuff with no indication of when or where we can use it. Can you at least give a hint?

Khronos says "this year"...if you know more than this...then please tell us.

Hi,

In the newer version of OpenGL some things were added to approach zero driver overhead, are we going top see things like multi_draw_indirect in Vulkan?

Yes. Vulkan started with the concept of minimizing driver overhead.

How about GLSL shader debugging (breakpoints, step in/out, watch variables, etc ... ) ? Will Vulkan/Spir-V helps to enable it ? I think it exists for HLSL in AMD's GpuPerfStudio and some people tried to do it for GLSL (https://github.com/GLSL-Debugger/GLSL-Debugger) but I couldn't make it to work...

Yes, SPIR-V has debug info in it to enable debuggers.

Vulkan supports multiple threads talking with it at the same time, but is there any support for multiple processes doing so?

Resource sharing works best within a single process...multiple apps will work concurrently, just as they do today with OpenGL.

Now that DirectX 12 is lacking the features of Vulkan, do you see it finally becoming the standard for...everywhere, instead of being the "ketchup" API? Do you believe DirectX 12 will under-perform when compared to Vulkan?

Vulkan approaches Zero Overhead...