Zink Update
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| 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 | 10.5446/47367 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2020438 / 490
4
7
9
10
14
15
16
25
26
29
31
33
34
35
37
40
41
42
43
45
46
47
50
51
52
53
54
58
60
64
65
66
67
70
71
72
74
75
76
77
78
82
83
84
86
89
90
93
94
95
96
98
100
101
105
106
109
110
116
118
123
124
130
135
137
141
142
144
146
151
154
157
159
164
166
167
169
172
174
178
182
184
185
186
187
189
190
191
192
193
194
195
200
202
203
204
205
206
207
208
211
212
214
218
222
225
228
230
232
233
235
236
240
242
244
249
250
251
253
254
258
261
262
266
267
268
271
273
274
275
278
280
281
282
283
284
285
286
288
289
290
291
293
295
296
297
298
301
302
303
305
306
307
310
311
315
317
318
319
328
333
350
353
354
356
359
360
361
370
372
373
374
375
379
380
381
383
385
386
387
388
391
393
394
395
397
398
399
401
409
410
411
414
420
421
422
423
424
425
427
429
430
434
438
439
444
449
450
454
457
458
459
460
461
464
465
466
468
469
470
471
472
480
484
486
487
489
490
00:00
CollaborationismProjective planeSelf-organizationBitRight angleComputer animation
00:45
PrototypeOpen setSoftware testingNumberCollaborationismInterface (computing)Cartesian coordinate systemSoftware testingImplementationComputer animation
01:30
Open setCollaborationismDevice driverMereologyPoint (geometry)PrototypeComputer animation
02:37
Open setFeedbackSinguläres IntegralArtistic renderingControl flowAlpha (investment)Software testingPlane (geometry)CollaborationismTransformation (genetics)Game controllerShader <Informatik>Point (geometry)Software testingProgrammschleifeFeedbackInstallable File SystemComputer animation
03:08
Open setFeedbackSinguläres IntegralArtistic renderingControl flowPlane (geometry)Software testingAlpha (investment)CollaborationismCASE <Informatik>Computer animation
03:33
Software testingOpen setBit rateCollaborationismBit rateSoftware testingNumberBitExtension (kinesiology)Different (Kate Ryan album)Line (geometry)Device driverMessage passingComputer animation
05:14
Open setFocus (optics)NumberCollaborationismPersonal digital assistantVirtual machineBenchmarkInstance (computer science)Game theoryPoint (geometry)BitEndliche ModelltheorieResultantTranslation (relic)Software testingNumberFocus (optics)CASE <Informatik>Computer animation
07:14
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
08:24
Computer configurationOpen setCollaborationismPatch (Unix)Inheritance (object-oriented programming)Point (geometry)CASE <Informatik>Projective planeMultiplication signClient (computing)Proper mapComputer animation
09:17
CollaborationismWindowProjective planeRaster graphicsRevision controlFunctional (mathematics)Device driverImplementationPrinciple of maximum entropyExtension (kinesiology)Physical systemSoftwareShader <Informatik>INTEGRALTheoryHypothesisComputing platformPlanningSoftware developerFlagInstance (computer science)Software testingComputer animation
13:33
CollaborationismComputer animation
13:49
CollaborationismDevice driverBenchmarkPoint (geometry)Extension (kinesiology)Computer hardwareBitResultantComputer animation
14:53
CollaborationismComputer animation
15:26
CollaborationismComputer animation
15:44
CollaborationismComputer animation
16:00
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
20:00
Point cloudFacebookOpen source
Transcript: English(auto-generated)
00:07
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
00:22
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.
00:42
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.
01:03
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,
01:21
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.
01:42
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.
02:00
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.
02:21
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,
02:44
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
03:00
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
03:24
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
03:40
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.
04:05
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,
04:21
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
04:41
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
05:02
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.
05:26
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
05:41
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.
06:01
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.
06:22
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.
06:44
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.
07:00
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.
07:21
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.
07:41
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.
08:00
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.
08:25
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.
08:43
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.
09:04
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.
09:21
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
09:41
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,
10:00
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.
10:24
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
10:40
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,
11:04
but it's gonna take a while. Anyone else? All right. So two topics at the same time,
11:21
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,
11:44
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.
12:03
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
12:22
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
12:40
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.
13:02
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.
13:22
Features that you are missing from Vulkan which prevent you from. Right, so the question is if there's any,
13:50
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.
14:02
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.
14:26
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
14:42
that we get some benchmark results or goals that we need to reach. All right. How hard do you think it would be?
15:26
Things. It could be useful for some compatibility stuff there.
15:44
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.
16:04
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.
16:22
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,
16:41
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.
17:02
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.
17:21
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.
17:41
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?
18:15
Probably, so yeah, the question is
18:20
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
18:41
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,
19:04
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
19:23
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
19:43
once we fix some of the other worst problems. All right, time is up, so thank you all for all the questions.