Interview with Jason Ekstrand
Vulkan in Open-Source. A discussion of the new Vulkan graphics API and its impact on Open-source software
Jason Ekstrand will give a talk about Vulkan in Open-Source. A discussion of the new Vulkan graphics API and its impact on Open-source software at FOSDEM 2016.
Q: Could you briefly introduce yourself?
My name is Jason Ekstrand. I’ve been a user of open source software ever since I was first playing with Linux over 15 years ago. I got my start as an open source software developer in the Wayland project towards the end of 2012. In 2014, I was hired by Intel to work on the intel 3-D graphics driver in the Mesa project.
Q: What will your talk be about, exactly? Why this topic?
I’m going to be talking about the new Vulkan graphics API. I’m going to focus mainly on some of the history of 3-D graphics, why we need a new API, and some of the opportunities that this new API presents. Why this topic? For one thing, It’s something that I’m very excited about personally. I’ve been interested in graphics programming for a long time and this is one of the biggest things to happen in the industry for a while. While Vulkan hasn’t yet impacted how hardware works (it probably will given time), it does substantially change the way you do graphics programming and it does so, I think, for the better.
Q: What do you hope to accomplish by giving this talk? What do you expect?
Primarily, I want to get people excited about what’s coming. Vulkan isn’t going to improve the graphics world over-night on Linux or on any other platform. However, it is a step forward and one that I want people to get excited about. I also want to present a “friendly face” for Vulkan to the open source community. One of the down-sides to groups like Khronos is that, while people may talk to each other fairly freely within Khronos, they very tightly control what the public is allowed to know about what they’re doing. This doesn’t sit well with a lot of free-software people. Many people in the open source world, especially users and community members with no corporate affiliation, are left in the dark and feel like this is one more corporate black-box that we will have to reverse-engineer. However, there are a number of well-known open source software developers (myself included) who have been involved in developing the Vulkan API and working towards bringing it into the free software world. I want the open source community to know that they are represented.
Q: What’s the history of the Vulkan API? Why did Khronos start it and which problems does it solve?
Over the years, graphics hardware has changed a lot. The GPUs of today look almost nothing like the GPUs of 10 years ago. There are other things that have changed such as the fact that 10 years ago, multi-core processors were still only for the elite and software didn’t take advantage of them; now it’s almost impossible to buy a single-core processor and many applications are multi-threaded. With these changes comes the need for new graphics APIs. OpenGL is now 24 years old and, while it has held up amazingly well given its age, there are aspects of the API that have become substantial pain points for both driver and application developers. Unfortunately, some of these pain points can’t be fixed without breaking the backwards-compatibility for which OpenGL is known.
One specific example of this is that OpenGL is a state-based and screen-based API. Everything is done in terms making calls that change internal state and then, after setting the state to what you want, you make a draw call which changes what is on the screen. This was a near-perfect match for early 1990s hardware where accelerating drawing triangles was important and where you barely had enough video memory to hold all of the pixels displayed by your monitor. This meant that the way you did rendering was to first talk to the window system (X, usually) and get a context that was tied to some piece of the screen. Everything you did would then be relative to that context and you needed to talk to the window system to get it. This caused a couple of problems. One is that everything is implicitly tied to the window system and you can’t really get a headless (non-graphical) context in which to do rendering. Extensions have been written to allow you to get an off-screen context but they do that by having a fake window system that just isn’t capable of displaying anything. Another aspect is that it doesn’t handle multi-threading well. Since everything happens by changing state on a single global context, you can’t really have multiple threads all trying to do work at the same time. Some attempts have been made to make OpenGL better for multi-threaded applications, but it is still very limited. Vulkan, on the other hand, solves both of these problems by design. It’s an inherently object-oriented API with little to no global state. Instead of getting some giant context from the window system, you just talk to the driver, find a GPU, and start rendering. It also multi-threads very naturally because each object has its own self-contained state instead of having so much bound up in a global context.
Why has it taken so long to fix these problems? Because backwards compatibility is very important and application developers want to be able to take advantage of new features without rewriting their entire application for a new API. In the world of game consoles, game developers want complete access to the hardware, so new SDKs are developed for each console, but with desktop computing you need more cross-platform stability than that. However, the time has come for the desktop and mobile worlds to move forwards. In the last few years, we have seen a lot of new graphics APIs coming out to address some of the needs of more modern software: AMD has Mantle, Apple has Metal, Microsoft has new DirectX versions, etc. All of these APIs, while trying to solve some of these problems, are specific to one hardware or software platform. Vulkan, on the other hand, is developed by the cross-company Khronos group and will hopefully be embraced industry-wide.
Q: How can the free software community benefit from the Vulkan API?
Right now, basically all open source graphics software and drivers are written against the OpenGL API. There has been talk from time to time in the free software graphics community about coming up with our own graphics API. People have tried, for instance, to write applications directly for the Gallium API that’s used as a middle-layer in Mesa. The problem is that drivers take a lot of work, developer time is at a premium, and if you want to play games then you have to support an API that has traction outside the open source community. The result is that OpenGL is basically the only option for free-software graphics programming.
Vulkan changes all this. We will soon have a graphics API that is both cutting-edge and available cross-platform to anyone willing to implement it. Free software applications and games will now have access to one of the best graphics APIs available. Hopefully we will also see better availability of games and other applications on free software platforms. Right now, most of the momentum for desktop games is in DirectX with a few being ported to OpenGL. With Vulkan, developers have access to a next-generation API that will run across multiple platforms. While it still takes effort to go from Windows+Vulkan to Linux+Vulkan, it is substantially less work than porting from another graphics API. Time will tell, but it will hopefully make the free software world a little more appealing.
Q: What capabilities will the 1.0 version of the Vulkan specification have? And when will we see the first Vulkan SDK?
The initial feature set won’t really be any different from what is currently available through OpenGL. Vulkan is intended to run on hardware that is already shipping and available today. What it does provide applications is less CPU overhead, tighter control over the hardware, and a more modern graphics programming model. As time moves on, both hardware and software will continue to evolve to take advantage of the new programming paradigms that APIs like Vulkan provide.
Unfortunately, I can’t really talk about exact timelines for an API or SDK release. What I can say is that, even with the release of the API, it will take time before the graphics ecosystem that we have today gets converted over to Vulkan. Toolkits such as GTK+ and Qt will have to grow Vulkan support, tools and helper libraries will have to be developed, and applications will have to be ported. It will also take time to educate people in how to program in this new model. While writing software in Vulkan is something anyone with graphics experience can do, it’s a lot different than writing software against OpenGL and even the most seasoned graphics developers will have a learning curve.
Q: Have you enjoyed previous FOSDEM editions?
This is actually going to be my first time attending FOSDEM. I was planning to try and go last year, but my schedule did not allow it. I am very excited to be attending FOSDEM this year and to have the opportunity to give a talk.
Creative Commons License
This interview is licensed under a Creative Commons Attribution 2.0 Belgium License.