We are LunarG. Developers of Glassy Mesa and other driver based technologies. We were contracted by Valve a year ago to work on improving graphical performance on SteamOS by providing Linux expertise at the driver level. We have more recently been involved in their work on Vulkan API, GLAVE, SPIR-V and other tools for the new open source standard. Ask us pretty much anything (hint: we like technical questions) :)!

Proof http://lunarg.com/reddit-ama-today/

Edit You can check out the Vulkan trace file debugger GLAVE here: https://www.youtube.com/watch?v=miZmas6sGqM

Edit Alright guys, thanks so much for your questions! Time to get back to work ;)

Comments: 205 • Responses: 46  • Date: 

blackout2453 karma

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 .

OfficialLunarG43 karma

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.

HildartheDorf23 karma

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?

OfficialLunarG27 karma

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.

OfficialLunarG23 karma

Thanks again guys! We had a blast.

datenwolf22 karma

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).

OfficialLunarG20 karma

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.

ancientGouda14 karma

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

OfficialLunarG10 karma

You are on the right track...

ancientGouda15 karma

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.

OfficialLunarG11 karma

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.

arendjr6 karma

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?

OfficialLunarG5 karma

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.

OfficialLunarG10 karma

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.

OfficialLunarG8 karma

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.

ancientGouda6 karma

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.

OfficialLunarG7 karma

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.

OfficialLunarG8 karma

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

OfficialLunarG7 karma

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.

OfficialLunarG5 karma

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.

OfficialLunarG5 karma

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.

LupinePride13 karma

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

OfficialLunarG12 karma

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.

blackout2412 karma

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?

OfficialLunarG15 karma

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

kwahoo29 karma

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)?

OfficialLunarG14 karma

Yes, NVidia gave a CAD demo at GDC using Vulkan

gulpaz4 karma

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

OfficialLunarG7 karma

Sure.

tiffany3528 karma

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?

OfficialLunarG5 karma

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.

OfficialLunarG5 karma

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.

Wollan8 karma

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

OfficialLunarG10 karma

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

blackout248 karma

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?

OfficialLunarG13 karma

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

OfficialLunarG8 karma

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

blackout243 karma

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

OfficialLunarG11 karma

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

SPIR-V -> target is vendor specific.

ancientGouda4 karma

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

OfficialLunarG6 karma

It's not counting anything in the compiler stack

shmerl8 karma

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!

OfficialLunarG8 karma

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.

shmerl7 karma

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?

OfficialLunarG8 karma

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.

Juiceisgreat7 karma

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?

OfficialLunarG12 karma

Team members have 15+ years on average per engineer

slacka1237 karma

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?

OfficialLunarG11 karma

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

banachtarski6 karma

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?

OfficialLunarG7 karma

Will GLAVE be open sourced?

Yes!

adila016 karma

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

OfficialLunarG7 karma

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

adila015 karma

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.

OfficialLunarG12 karma

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.

OfficialLunarG8 karma

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.

gaspah0 karma

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.

OfficialLunarG9 karma

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

zishh5 karma

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)

OfficialLunarG8 karma

No, they are different programming models.

ScepticMatt4 karma

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

OfficialLunarG5 karma

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

Leandros993 karma

Hey, thanks guys for having an AMA.

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

OfficialLunarG9 karma

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

Overv3 karma

How does context creation work with Vulkan?

OfficialLunarG9 karma

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

datenwolf3 karma

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

OfficialLunarG6 karma

There are devices, queues, command buffers and pipelines.

BillDStrong3 karma

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?

OfficialLunarG5 karma

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

BillDStrong3 karma

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

OfficialLunarG2 karma

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

K900_3 karma

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?

OfficialLunarG5 karma

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

Karanlos2 karma

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?

OfficialLunarG9 karma

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

Haypol2 karma

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...

OfficialLunarG6 karma

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

nope_dot_avi2 karma

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

OfficialLunarG4 karma

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

3GenGames-5 karma

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?

OfficialLunarG5 karma

Vulkan approaches Zero Overhead...