This time we have the pleasure to discuss Zink with one of his key contributors, Michael Blumenkrantz. What is Zink, you may wonder? Zink is a project somewhat similar to DXVK in concept, where you take calls from one API language and you translate them to Vulkan instructions. For DXVK, it’s DirectX 9,10 and 11. For Zink, we are talking about OpenGL.

Now, why support OpenGL through Vulkan? After all, OpenGL drivers are typically available on Linux, and most hardware should properly support it. Well this is your lucky day, as Mike will provide a full perspective about the Zink project and what it can be used for.

Since this interview was conducted in mid January 2021, a few things have changed since them, the most relevant one being that GL 4.6 and GLES 3.1 support was already merged into Zink in the meantime.

Now, on to the episode:

Boiling Steam: Thanks for joining us today! First I wanted to ask you a couple of questions regarding Zink and your former graphics experience. Can you let us know a little bit more about yourself and where you came from? What was your background regarding Linux, and how did you end up getting into graphics drivers?

Michael Blumenkrantz: Thanks for having me here! My background in Linux and open-source goes back about 20 years now. I started using Linux on the first PC that I built for myself after a summer job. Just kind of tinkering around for the enjoyment of it. Back in the early days of the Internet taking off, and back then there was not a ton of potential for gaming. There were the Loki ports of games. I played a lot of Unreal Tournament back in the day on the Loki port; that was a lot of fun. But I never really did much in the way of programming until about 10 years ago.

All throughout school, I took a couple of courses and it was nothing that I had really set my life’s ambition towards. Nothing that I was incredibly interested in. Or at least it wasn’t as interesting as I had expected it to be. I thought it was going to be a lot more like the Matrix, and it was a lot more of just sitting at a keyboard so the mystique was not there. But that all changed after I graduated from university as all things do when I needed a job. I got a job at a small startup company with some friends from university, originally just doing documentation and build system stuff. That sort of evolved into doing more programming and more architectural work. This was virtualization- and networking-oriented. From there, I got involved with the Enlightenment project, because I had been using that pretty much since I started using Linux.

It was that or Fluxbox, and Fluxbox was great, but Enlightenment had the unique ability to have unsynchronized virtual desktops on multiple displays and did not interrupt video playback when changing virtual desktops on displays. That was important at the time. So my work on Enlightenment progressed and I continued integrating things there and improving things. Then Samsung came knocking. So I moved to the UK to work there for a time before moving back to the US, to work for the open-source group under the great leadership of people like Ibrahim Haddad, Guy Martin, Brian Warner. That was an incredible experience. I got to work with a lot of very smart people, much smarter than me, much better engineers than me – that’s for sure – since I still don’t have a CS degree and I’m sort of picking things up as I go along.

So Samsung, unfortunately, had to end early last year due to a number of factors, the least of which was the growing COVID situation. That put me in a position where I needed to rethink what I was doing in my engineering life. Until then I had been working exclusively in the desktop and the graphics layer pretty high up the stack so to speak, and so I thought to myself, “Well I’ll check out some of the lower level stuff, see how that goes.” That led me into graphics. I got a recommendation from Daniel Stone, an incredible person, incredible engineer who said “Why don’t you check out Zink? There’s a lot of work that could be done there, you’ll learn a lot” and I did. That led me down the path of low-level graphics and here I am.

BS: So you had no prior low-level graphics experience before working on Zink directly?

Mike: I had done a couple of patches in Mesa. I ported a couple of features from the i965 driver to Iris on Intel since I had Intel hardware and I knew some people at Intel. So I got a little mentoring along the way there. I hooked up YUV planar support for Gallium and only broke a few things in the process. But I wouldn’t say I had anything even remotely approaching a deep level of understanding of low level graphics. Probably the most I had done on the API side was that I wrote Compiz plugin for Enlightenment a few years ago, just to see if I could make that work. I did all right.

BS: So you actually had to delve into both Vulkan and OpenGL for the first time?

Mike: Yeah, I was learning both of those at the same time, which was a fun experience.

BS: Wow! What did you expect when you started working on this?

Mike: I didn’t really have any idea what I was getting into, so to speak, and that was sort of magnified, because the first thing that I set out to do in Zink was to handle stream-out or transform feedback, which is sort of the biggest pain in the ass possible in a driver. Jason Ekstrand has a lengthy blog post about why transform feedback is awful and why it needs to even exist in Vulkan. The short of it: it needs to exist solely for compatibility with stuff like OpenGL and applications that are expecting to be able to do that.

BS: Okay, so there is actually in Vulkan some kind of function that make it possible to do OpenGL as well?

Mike: In the sense that it makes it possible to emulate some use cases of OpenGL that are not directly supported by Vulkan - Yes. There are some areas that are sort of still not yet covered, and Khronos and the Vulkan community are working pretty hard towards smoothing that out and getting all that working.

BS: At this stage what would you say about Zink, and if you were to explain Zink to a more laymen audience, how would you describe it and what would you say it’s able to achieve at this stage?

Mike: Sure. So all hardware up to this point pretty much has had very little choice in the graphics API to support. If you’re on Windows you usually support DirectX. Maybe you support OpenGL as well to ease your porting to other platforms. But if you’re on other platforms you mostly support OpenGL because that’s sort of the de facto standard. In recent years that’s changed with the emergence of other graphics APIs like Mantle, like Vulkan.

There are newer versions of DirectX which are still Windows-specific, but OpenGL is sort of fading out, and with that said newer hardware is not necessarily going to be supported by any driver that is capable of doing OpenGL. At that point, it becomes necessary to have some sort of layer in place that allows that hardware to work going forward with older applications. For example, stuff like game emulators, or even Minecraft. Zink is intended to fill that void.

BS: Would you say that it’s already achieving that role right now? Or is there still some ways to go before it could be used as a complete replacement?

Mike: I don’t think anybody is going to be using it as a complete replacement anytime soon; there’s still a lot of work to be done. It’s shipping with GL 4.1 supported. I’ve done work to get all the way up through 4.6 and GLES 3.2 and a lot of performance work. There’s still a lot of work to be done before that can be landed. I have the great support of Erik Faye-Lund from Collabora and in helping me in that process, along with others from the Mesa community. Zink is already being used in some places at quite a high level, let’s say nearly production, and it is already sort of filling that void. There is work being done by some community members in the Zink project to get it working on MacOS, because Apple has limited OpenGL support. There are people who have deployed it in a production environment there. In some cases, I would say it is ready to be used as a drop-in replacement. But for general gaming, there’s still a little ways to go.

BS: You mentioned Apple. So for Apple, does it work through MoltenVK or do you have a direct Metal implementation?

Mike: It’s on top of MoltenVK and we have the great Duncan Hopkins working on that end.

BS: Does it work also on Windows or is there any kind of Linux-only specification at this stage?

Mike: Currently we’re just targeting Linux and related platforms. I would like to see it running on Windows at some point, just from sort of personal curiosity – can I make this work? That would be a neat thing but that’s that’s pretty far off.

BS: What is hindering the support on Windows at this stage?

Mike: There’s the obvious part: I haven’t actually tried it. So I have no idea what’s missing but beyond that, Zink currently doesn’t have any sort of window system integration, which means that for example if you’re running on Xorg, there’s a lot of hacks that go into getting it to sync with the display server to avoid massive tearing. Adam Jackson is hard at work on that. I think we’re gonna see that coming in fairly soon, and that should reduce a lot of the uncertainties regarding other platform support too.

BS: Going forwards, what would be the objective? Is Zink integrated through Mesa directly?

Mike: Zink is in Mesa already and so that’s going to be basically living through there from now on. Zink has been in Mesa releases for a couple of years now. The currently shipping GL version supported in Mesa is 4.1.

BS: And your plan is to go to 4.6 or upwards as well in the future?

Mike: That’s correct. I have that work done, and we’re working on getting that into a state that can be shipped in Mesa.

BS: A couple of months ago, you announced that you were being sponsored by Valve. Can you let us know a little how this kind of things happen?

Mike: There’s not really a ton to the story. I’ve been working on Zink for probably six or eight months, and I was contacted by Valve, and they said that they liked the work that I was doing, they really liked the passion that I was showing for the low-level graphics side of the open-source community, and they were interested in sponsoring me and the things that I work on. Not necessarily that they are sponsoring Zink as a project but I happen to be working on Zink.

BS: Is Valve shaping in any way the work you are doing or simply supporting you?

Mike: I would say it’s mostly up to me. Valve provides a lot of great support in things like getting specifications moving, getting conformance testing moving. There’s a community of other developers who work for Valve in sort of the same capacity that I do, who I get to connect with and provide great information and support in the course of doing work on Zink and other related things.

BS: Hypothetical scenario: Let’s say one day you achieve the specifications for 4.6 or above, how would you consider your work to be done at that stage?

Mike: That’s a tough question. 4.6 isn’t exactly like the end of specifications. There’s some other extensions that are necessary to play the top-level games that run in OpenGL, like, for example, Doom 2016, which is kind of the final boss for Zink if you will. […]. I would say ideally if I am able to get Zink to support all the critical extensions and OpenGL features that are necessary to play the majority of games from the majority of applications and do so at within 10% of native performance I would say that would be certainly good enough.

BS: When you say native performance, are you referring to the original OpenGL client that was available for such games or something else?

Mike: I’m speaking of a native OpenGL driver. If you’re on an Intel platform you have the classic i965 driver or the Gallium-based Iris driver, and so if I’m able to get within a certain amount of performance of those drivers then that’s definitely where I want to be.

BS: Do you think it’s even possible that you can go beyond the performance of those OpenGL drivers as the Vulkan implementation can bring some additional benefits in how you manage hardware?

Mike: The best example I can give on this is my continuing battle to catch up to the RadeonSI driver, which is the fastest OpenGL driver I’ve encountered because it’s kind of pushing the boundaries of Gallium development and thus serve as implementing all these new APIs that allow it to be the fastest. In that sense, I would not expect that I would really be able to catch up to a driver like that, because there’s really no room for improvement in a significant way.

By contrast, there are some drivers I’m not going to name here which are less optimized or are not written in such a way that they can take advantage of more modern CPU architectures and parallelization. So for those drivers, I would expect that I can exceed that performance.

BS: How long do you think it would take on Zink to get to the stage where you can support a title like Doom 2016 you were mentioning earlier?

Mike: I honestly can’t speculate how long it’ll be before that sort of thing is widely available. It’s sort of one of those things where I might say it’s a year but then a year from now I have it working great and some critical issue is discovered, which means that everything else is broken or that sort of thing. Driver development is very tricky, especially when you’re intending to support multiple platforms. Zink has the misfortune of having to support all the Vulkan drivers. Things that might work great on for example Intel might not work great on another platform. Every time I bring up a new platform to test, I find all these issues. Maybe I’m not quite following the specification as exactly as I need to be. So that sets me back a lot of times, going back fixing regressions. So at this point, I’d say it’s a little premature to be trying to give any sort of estimate, unfortunately.

BS: Does the evolution of the Vulkan specifications incur any regression for your work on Zink?

Mike: Not frequently. The specification itself changing has no real impact on drivers because that’s sort of just the language of what the driver should be doing. With that said, there have been a couple of cases where tests in Zink have regressed due to changes in the underlying Vulkan driver that I’m testing against. Zink has become a good thing for the developers working on those drivers, because they are able to catch those which the conformance test suites for Vulkan aren’t covering, because they’re strange corner cases.

BS: Do you think there is going to be a day in the future where GPU makers or vendors actually stop delivering an OpenGL driver?

Mike: I don’t really know the answer to that. I know there is still a lot of support at companies for OpenGL, but there is certainly more work going into the newer APIs, if only because that’s where game developers are. I don’t think any AAA studio at this point is writing new OpenGL-based games.

BS: OpenGL is still being used for commercial applications as well or industrial applications too…

Mike: Absolutely, yeah, so that is certainly a factor. But it’s important to keep in mind that OpenGL is evolving much more slowly than the other APIs. There isn’t necessarily a lot of churn in the code base. There’s nothing major and new that needs to be supported there. It impacts how development resources are allocated.

BS: It’s almost like a maintenance mode?

Mike: Yeah, something like that.

BS: Is there personally one game you’re looking forward to making work, apart from Doom (2016) you mentioned earlier?

Mike: I got a personal request to try and get the new Wolfenstein games running. So that will probably be my next target since that’s been pending for quite some time. Aside from that, just from the sort of challenge aspect of it, the Yuzu emulator… is a difficult one. I have not ever actually tested Yuzu in any capacity, so I can’t speak to that, but in their OpenGL implementation they use Uber shaders, which have some very interesting usage of OpenGL limitations.

BS: Let’s say in the future you’re completely done with Zink: you managed to implement most specifications and you have acceptable or great performance you are happy with – what would you like to be working on next?

Mike: That’s a good question. There’s a lot of areas that could be interesting. There’s things like DXVK and Proton: those are huge projects. There’s a lot of room, not necessarily that they need a lot of work, but they are broad projects. And there’s room for other people to be contributing so I have some interest there. There’s the Vulkan drivers themselves. There’s always the possibility of getting more work done there. There’s things like WINE in general. There’s certainly a broad scope of Linux-gaming-related and graphics-related projects.

And this is the end of our discussion with Mike. Zink certainly opens up a number of exciting possibilities going forward, and you will surely keep hearing about it. We hope you enjoyed this interview! We will publish the audio version of this conversation a little later next week as well.

If you are interested to learn more about Zink, you can also catch the following presentation (albeit older) from Erik Faye-Lund at the FOSDEM 2020: