We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Zink Update

00:00

Formal Metadata

Title
Zink Update
Subtitle
OpenGL on Vulkan upstream in mesa
Title of Series
Number of Parts
490
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
A short update on the state of Zink, and OpenGL implementation on top of vulkan, now that it's upstream in Mesa.
33
35
Thumbnail
23:38
52
Thumbnail
30:38
53
Thumbnail
16:18
65
71
Thumbnail
14:24
72
Thumbnail
18:02
75
Thumbnail
19:35
101
Thumbnail
12:59
106
123
Thumbnail
25:58
146
Thumbnail
47:36
157
Thumbnail
51:32
166
172
Thumbnail
22:49
182
Thumbnail
25:44
186
Thumbnail
40:18
190
195
225
Thumbnail
23:41
273
281
284
Thumbnail
09:08
285
289
Thumbnail
26:03
290
297
Thumbnail
19:29
328
Thumbnail
24:11
379
Thumbnail
20:10
385
Thumbnail
28:37
393
Thumbnail
09:10
430
438
CollaborationismProjective planeSelf-organizationBitRight angleComputer animation
PrototypeOpen setSoftware testingNumberCollaborationismInterface (computing)Cartesian coordinate systemSoftware testingImplementationComputer animation
Open setCollaborationismDevice driverMereologyPoint (geometry)PrototypeComputer animation
Open setFeedbackSinguläres IntegralArtistic renderingControl flowAlpha (investment)Software testingPlane (geometry)CollaborationismTransformation (genetics)Game controllerShader <Informatik>Point (geometry)Software testingProgrammschleifeFeedbackInstallable File SystemComputer animation
Open setFeedbackSinguläres IntegralArtistic renderingControl flowPlane (geometry)Software testingAlpha (investment)CollaborationismCASE <Informatik>Computer animation
Software testingOpen setBit rateCollaborationismBit rateSoftware testingNumberBitExtension (kinesiology)Different (Kate Ryan album)Line (geometry)Device driverMessage passingComputer animation
Open setFocus (optics)NumberCollaborationismPersonal digital assistantVirtual machineBenchmarkInstance (computer science)Game theoryPoint (geometry)BitEndliche ModelltheorieResultantTranslation (relic)Software testingNumberFocus (optics)CASE <Informatik>Computer animation
Open setCollaborationismArtistic renderingData bufferTexture mappingObject (grammar)FeedbackSinguläres IntegralInstance (computer science)Slide ruleMultiplication signFeedbackElectronic mailing listSoftware bugTerm (mathematics)Object (grammar)Software testingTexture mappingArtistic renderingComputer animation
Computer configurationOpen setCollaborationismPatch (Unix)Inheritance (object-oriented programming)Point (geometry)CASE <Informatik>Projective planeMultiplication signClient (computing)Proper mapComputer animation
CollaborationismWindowProjective planeRaster graphicsRevision controlFunctional (mathematics)Device driverImplementationPrinciple of maximum entropyExtension (kinesiology)Physical systemSoftwareShader <Informatik>INTEGRALTheoryHypothesisComputing platformPlanningSoftware developerFlagInstance (computer science)Software testingComputer animation
CollaborationismComputer animation
CollaborationismDevice driverBenchmarkPoint (geometry)Extension (kinesiology)Computer hardwareBitResultantComputer animation
CollaborationismComputer animation
CollaborationismComputer animation
CollaborationismComputer animation
CollaborationismExtension (kinesiology)Device driverInterface (computing)MereologySerial portVolumenvisualisierungCompilation albumGraphics processing unitRevision controlNetwork topologyShader <Informatik>Semantics (computer science)Multiplication signTrailPoint (geometry)BitMessage passingMathematicsInstance (computer science)Computer animation
Point cloudFacebookOpen source
Transcript: English(auto-generated)
All right. Hi, everyone. I'm, first of all, sorry about the delay. Sorry to the FOSTA organizers for making them look bad. It's all my fault. I'm also
happy that I have a pretty short talk right now, because I think we'll still manage on time, and if not, we'll run a little bit over maybe with questions if people have any. So yeah, my name is Eric. I work at Collabora, and I'm going to talk to you about what's happened in the last year of the Zinc project.
So yeah, I'll just start. So one year ago, I was here at FOSTA and I presented about Zinc. For those who don't know the Zinc project, it's an OpenGL implementation on top of Vulkan, using Mesa 3D and the Galium interface.
What we had was running OpenGL 3.0, or at least exposed that. Turns out that there's some more test running and stuff. We were kind of far off on a bunch of the details. So yeah, we were failing a whole lot of piglet tests,
and I don't have the numbers, but it wasn't great, but it was kind of working for some applications. Yeah. So this fall, Zinc got upstreamed in Mesa and became a part of Mesa 19.3.
So it's no longer living in a branch. It's now shipping. It's not compiling by default, but you can enable it the same way as you enable any Galium drivers. And we've started getting some contributions from other people.
So now I think five people have contributed to Zinc. I think last year there was two. So this is interesting, and yeah. And now everything happens upstream in the upstream issue tracker and stuff like that. So no point in filing issues in my fork any longer.
We've sadly had to revert away from the OpenGL 3.0 stuff. So we're now only exposing OpenGL 2.1. There's two major features missing that were in the last prototype that need some re-engineering. Yeah. So since last year we've added some, I think,
like some features that are quite nice. We now properly support control flow, and the shaders so you can do all of your ifs and switches and loops and stuff like that. We properly forward point sizes
if they're not written from the vertex shader. We do alpha testing and transform feedback and conditional rendering support because we re-engineered some of the way things are emitted
and some, yeah, how curious way it works because, yeah, the old thing kind of failed in a lot of cases. Yeah. So I'm currently doing quite more structured
testing than before. So these numbers are actually a little bit out of date. They were up to date three days ago, but now I've improved some stuff. But, yeah, so we have about 3,000-something tests passing. I think we're down to almost half of the failures now.
Yeah, and even less crashes. So that's, yeah, probably closer to 80% pass rate right now. And most of the failures right now, or at least a big bulk of them,
has to do with unsupported edge flags, which we need to do something more clever about. Right now we just fail, throw an error and give up. Yeah, and also some stuff due to unsupported line stipple. Line stipple we have an easy way forward with
because there's an extension for better lines in Vulkan now that it's exposed by, I think, both the ANV and RADV drivers that allow us to forward line stippling. Last time, like I tried implement, I have some experimental patches for it. There seems to be some differences
in how this works in Vulkan and OpenGL. So it didn't really pass a whole lot of tests. It started stippling, but there's some more stuff to it. So yeah, performance is something I keep getting asked about. I keep trying to avoid the question a bit.
It's not great, but it's also not really the main focus of the project. I'm not saying that we don't care about performance, but this zinc is kind of like, I'm trying to prepare us for a future
where we don't need OpenGL anymore. So hopefully machines will, I don't think this is going to be super relevant for the next five years, and then machines will be a little bit faster and OpenGL, like more high end stuff will be ported and I think we will not care that much.
But of course, it's nice to get the performance we can. Yeah, so not much has changed there. I don't really do any systematic numbers here, but Phoronix did a benchmarking of radvi or zinc on top of radvi versus radium si. And I'm kind of surprised by the results.
Some of the tests are almost on par. I'm guessing those are cases where we're GPU bound, and for some reason we happen to do things that are OK for the GPU. But some are pretty far off, and then we're talking about maybe 25% to 33% ish of the performance.
So still usable, but not anything you want to game on, for instance. So yeah, and just from how zinc is engineered, I think there's quite a lot that can be done for performance.
We're doing a very simple kind of translation model where we're not trying to be terribly clever. And yeah, I think at some point we're probably going to have to start being a bit more clever. Yeah, so some about the stuff I'm working on.
Next on my to-do list here is crossing off OpenGL 3.0 again. Yeah, and these slides are out of date, or this already, because I added back instance rendering and texture for objects over the weekend.
Or not over the weekend, but the last couple of days. But yeah, the conditional rendering and the transforms feedback stuff needs some more work. I also want to start testing for OpenGL ES 2.0.
I suspect that we're already there, but in terms of features, probably fail some tests and some bugs there. But I think we should have all of the stuff that's required. But I haven't spent any time on it. But I think after I've landed GL 3.0, I think this might be what I will look into next.
Yeah, and then it's the cool, like this is moving kind of slowly currently because I'm working on zinc as a part-time R&D project at work, and I'm kind of super busy with some other paid client work at the time.
So I kind of don't have a great way out of that. There's not gonna, this is gonna be the case for some months going forward. But if you need zinc to move faster, I think there's kind of two options. You can either work on it yourself, or you could hire Collabra to work on it for you.
So yeah, I think we're at the point where I think to move this faster and more robustly, we need to find some paying customers or something to spend some proper time on it. All right, that was my talk.
So I managed, didn't I? Oh, one minute over. Yeah, sure. I have many questions actually. Yeah? I've already got over the years. So I'm curious, what is your meet-to-long-term goal? Like, do you aim to support all versions of OpenGL
or only like the modern ones? Yeah, okay, sorry. So the question was if I plan on supporting only old or new OpenGL versions or like what the long-term plan for zinc is. And the long-term plan, from my perspective,
this is gonna take a while, but it is full OpenGL support all the way as much as we can. I don't care too much about hypothetical Vulkan drivers, for instance. So I'm pretty happy to kind of use extensions where that gets me out of a problem.
But I don't see anything in the way for, for instance, if someone has a driver and they won't hire OpenGL version, we might have to implement some lowering to some master stuff. I, for instance, foresee quite a lot of
fixed function stuff being lowered to geometry shader stuff in the future for, for instance, stuff like the edge flags. So yeah. Long-term goal, I think, I don't see a reason why not to go for a full OpenGL 4.6 compatibility profile,
but it's gonna take a while. Anyone else? All right. So two topics at the same time,
like you're talking about how much work it is and how you would like to be hired to work on it. Is this Linux only, or is it usable on other platforms? One platform you can think of would be the Mac where the OpenGL support has been completely dropped and something like that could actually help developers,
even corporate developers to save quite some work. Okay, so the question was about platform support and if it's Linux only or if it works on other platforms as well. It works on Linux and on Mac OS.
So I have not, I don't have a Mac, I don't test on Mac, but we have users who use it on top of Molten VK, on top of Metal to run on Mac. So there are people who do this
and there's some interesting people trying this for some kind of big projects. I don't think anyone is doing this in production, but yeah. I don't, so right now the implementation is kind of tied to Mesa
and the Windows system implementations there. And Mesa doesn't, to my knowledge, have any Windows, Windows integration apart from the software rasterizer stuff. Zinc has the ability to hook in as a software rasterizer, basically as a mem copy into a frame buffer.
And I guess in theory that could be wired up, but I think it's gonna be pretty terrible for performance reasons, so I kind of, I'm not planning on going down that road.
Features that you are missing from Vulkan which prevent you from. Right, so the question is if there's any,
I don't see a reason why we can't add extensions, especially not, I'm primarily targeting the Intel ANV driver because that's the hardware I have.
And that driver happens to live in the same tree, which is super convenient. So at some point I might look into that. I'm more interested in this for compatibility than for features though, because there's some things that are just a little bit too crazy to implement without any extensions.
But I think the answer is yes, we could go down that road. We're not actively pursuing it yet. This could very well change, for instance, if we get a paying customer who does care about performance. I think that's probably a likely outcome at some point
that we get some benchmark results or goals that we need to reach. All right. How hard do you think it would be?
Things. It could be useful for some compatibility stuff there.
Basically just OBDL called maps, almost straight to a Vulkan call, how many of them are like, but what really? API translates more or less directly to the Vulkan API.
And I think to answer that question kind of truthfully will be kind of a long answer because we're not implementing OpenGL, we're implementing the Gallium interface. The Gallium interface is much closer to something like the dark 3D 10.
We're taking a pretty naive approach where we're kind of like just pulling the handbrake whenever semantics break if we don't. So right now we're going pretty directly, I would say. We're doing stuff like, for instance, Vulkan has the concept of render passes,
and we're just starting and stopping them whenever commands aren't allowed inside a render pass. So we're not trying to reorder anything and track dependencies, for instance. That is a horrible idea, and that's definitely gonna have to change, but for now it works much better than I feared.
I think one of the reasons for that is probably that I'm currently targeting desktop GPUs largely, and they don't really benefit from render passes as much as tile-based renderers do.
Shaders, yeah, so the question is how I deal with shaders, and this, I think, is one of the more interesting parts of Zinc, at least for me. So we take shaders, for Mesa we get shaders. Okay, I have to wrap up soon.
We get shaders as GLSL or ARB Vertex Program. They get converted into some IR and then into NIR, which is a general IR in Mesa, and NIR gets translated finally to SPIR-V, which gets handed over to the, yes?
Probably, so yeah, the question is
if going from NIR to SPIR-V and back again could be avoided, because the driver, the Vulkan driver will, if it's a Mesa-based Vulkan driver, will translate back to NIR, so we're gonna do a little bit of a dance there. Yes, I think that could be avoided. This, I think, is an interesting point
to look into making an extension. That being said, NIR isn't really made for serializing. There is a NIR serialization level, but it needs to serialize to the exact same version,
so you can't have, because NIR changes over time. So you would have to either guarantee that the drivers are built from the exact same tree. I think it would be possible to negotiate like NIR and the Mesa-Sha version
and try to avoid it in that case. And yeah, I think that would be interesting. It would maybe save us some time. I haven't seen any profiling data indicating that currently shader compilation is a problem, but I'm guessing that might become a problem
once we fix some of the other worst problems. All right, time is up, so thank you all for all the questions.