Nouveau Status 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/47488 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2020315 / 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
MikroblogTheoryComputer animation
00:36
Graphics processing unitOpen sourceDevice driverKernel (computing)Asynchronous Transfer ModeTuring testAtomic numberPrime idealReverse engineeringCache (computing)Shader <Informatik>Software developerCore dumpRandomizationCompilation album40 (number)Game theorySoftware testingComputerMultiplication signMultilaterationExpected valueSet (mathematics)AreaAutomatic differentiationSoftware developerBuffer solutionTime zoneElectronic visual displayWebsiteSpacetimeSinc functionMereologyState of matterTerm (mathematics)VideoconferencingSound effectProcess (computing)Integrated development environmentRight angleVariable (mathematics)DistanceLaptopProjective planePoint (geometry)Hydraulic jumpField (computer science)Physical systemRange (statistics)Theory of relativityPower (physics)TouchscreenCartesian coordinate systemInsertion lossArmOpen sourceExtension (kinesiology)Device driverDefault (computer science)Shader <Informatik>Source codeRun time (program lifecycle phase)FirmwareKernel (computing)Asynchronous Transfer ModeReverse engineeringElectric generatorTuring testPrime idealConformal mapGraphics processing unitNormal (geometry)Mathematical optimizationComputer animation
10:01
Core dumpSoftware developerFirmwareCodeRandom numberPatch (Unix)Mountain passBuildingPhysical systemTuring testSoftware developerComputer hardwareEmailKernel (computing)FirmwareCore dumpSoftware testingDevice driverHand fanGraphics processing unitBitCodeElectric generatorData management2 (number)Negative numberRepository (publishing)Network topologyInterface (computing)Inheritance (object-oriented programming)Projective planeNumberTask (computing)Statement (computer science)Power (physics)State of matterRandomizationJava appletSemiconductor memorySoftware bugFront and back endsComputer programmingMathematical optimizationSlide ruleElectronic mailing listOpen sourceReading (process)IterationMultiplication signLevel (video gaming)MathematicsShader <Informatik>Different (Kate Ryan album)Distribution (mathematics)Scripting languageGoodness of fitOpen setHypermediaVery-high-bit-rate digital subscriber lineWordAddress spaceReverse engineeringVideoconferencingSet (mathematics)Shape (magazine)Computer clusterProcess (computing)Group actionCuboidMereologyRow (database)SoftwarePatch (Unix)MetreView (database)Electronic visual displayComputer animation
19:10
Mountain passBuildingPhysical systemTuring testKernel (computing)Task (computing)MultiplicationDevice driverContext awarenessData recoveryReverse engineeringProjective planeStress (mechanics)Software testingMetreTheory of relativityOrder (biology)InformationPlanningBasis <Mathematik>Touch typingSoftwareDecision theoryCartesian coordinate systemMultiplication signInterface (computing)Crash (computing)Event horizonWell-formed formulaCASE <Informatik>Compilation albumDevice driverDifferent (Kate Ryan album)SpacetimeWater vaporProcess (computing)ResultantContext awarenessElectric generatorOnline helpView (database)Physical systemBitGroup actionLaptopForcing (mathematics)Level (video gaming)Power (physics)Computer hardwarePoint (geometry)GoogolData managementWebsiteInstallation artBuildingGame controllerValue-added networkInstance (computer science)Direction (geometry)Real numberFirmwareCodeAreaFreewareMultiplicationSoftware developerKernel (computing)PCI ExpressVirtual machineTuring testRandom matrixInheritance (object-oriented programming)Graphics processing unitRun time (program lifecycle phase)Software bugBridging (networking)Repository (publishing)PasswordBootingBranch (computer science)Computer animation
28:12
MultiplicationDevice driverData recoveryContext awarenessTask (computing)SpacetimeComputer hardwareCompilerGraphics processing unitFood energyDirection (geometry)Software testingFigurate numberArc (geometry)Uniform resource locatorDevice driverCASE <Informatik>Power (physics)Level (video gaming)FreezingGodLoop (music)Acoustic shadowElectronic mailing listGame theoryMultiplication signData recoveryContext awarenessVideo gameSpacetimePhysical systemVirtual machineStudent's t-testSet (mathematics)Order (biology)Latent heatState of matterShift operatorAreaProjective planeFingerprintPoint (geometry)MathematicsProcess (computing)Annihilator (ring theory)Functional (mathematics)Hand fanGroup actionOpen sourceLie groupView (database)Computer clusterPressureArmOpen setTask (computing)CompilerAdditionRandomizationShared memoryMathematical optimizationCartesian coordinate systemControl flowComputer programmingForcing (mathematics)Graphics processing unitGoodness of fitBitRight angleCrash (computing)CodeShader <Informatik>Run time (program lifecycle phase)Kernel (computing)Performance appraisalReverse engineeringCore dumpInterface (computing)Near-ring1 (number)Pattern languageThread (computing)Artistic renderingComputer animation
37:14
InformationWhiteboardSoftware bugWhiteboardTask (computing)Link (knot theory)Touch typingCuboidComputer animation
37:52
InformationWhiteboardDoubling the cubePoint (geometry)Software developerDevice driverRun time (program lifecycle phase)FirmwareAxiom of choiceCore dumpMultiplication signComputer hardwarePlastikkarteGame theoryVirtualizationSoftwareLevel (video gaming)Stack (abstract data type)Game controllerGraphics processing unitRevision controlAdditionProcess (computing)Right angleTelecommunicationPort scannerTrailForcing (mathematics)Film editingLie groupPosition operatorFLOPSVideoconferencingCausalityBlock (periodic table)Open setStiff equationSoftware testingComputer animation
42:52
InformationWhiteboardSpeicherschutzPoint (geometry)Dressing (medical)Service (economics)Arithmetic meanElectric generatorComputer architectureBitInformation securityProcess (computing)Software testingShooting methodFood energyCrash (computing)Musical ensembleContext awarenessMonster groupData managementElectronic signatureComputer clusterExtension (kinesiology)Moment (mathematics)CoprocessorState of matterKernel (computing)WeightSemiconductor memoryBootingProduct (business)Core dumpAddress spaceComputer hardwareDevice driverPower (physics)FirmwareBacktrackingMultiplicationCausalityComputer animation
47:52
InformationWhiteboardPoint cloudOpen sourceComputer animation
Transcript: English(auto-generated)
00:07
Okay, hi. Is the sound okay? Okay, cool. So, I want to give a status update on Novo. We kind of missed last year, so we are really sorry about that.
00:25
Luckily, it worked out this year, even though we missed the CFP and everything. So, yeah, let me just start.
00:40
That's still our goal. I mean, we are sure we can't really promise performance expectation users might have from a normal open source OpenGL driver, but at least we are really trying hard to make it reliable. And we know that we have a lot of places where we still have a lot of issues, especially about reliability,
01:07
but at least that's where we want to be in the future, and hopefully we get there at some point. So, but what actually happened since the last time we gave this update,
01:26
and I guess the most important feature for newer systems is that we finally support mode setting on Turing GPUs. So, if you have a recent GPU, there's a high chance that you can use your displays with the Novo driver.
01:47
I think it's still missing for really new GPUs, like some newer chipsets coming, which were released some months ago or something. That might still be missing, but at least for most of the Turing GPUs, it should be fine now.
02:05
There was also some atomic mode setting support, which is essentially for user space. If you want to change the resolution, but something happens, like the cable is not reliable or something,
02:21
the kernel can automatically detect certain problems with that, and that you don't get to a state where you have a black screen. So, that's quite important. I think there are a lot of X compositors which are buggy, so we kind of disable it on the kernel side,
02:41
but hopefully we get there as well. Lut was working on a lot of reverse prime improvements. When I'm looking at this, two years ago or something, there were a lot of issues with reverse prime. The HDMI audio was not working, or the GPU wasn't powered on anymore,
03:05
so there were a lot of random failures. Lut did a good job to work on all of those and get it to a state where I think we can say it's good enough now, and there shouldn't be many issues left.
03:22
If you know of some, just... Yes? What is reverse prime? Reverse prime is if you have a laptop, and usually your desktop is rendered on an Intel GPU, but some of the laptops have external display ports, like HDMI or display port, wired to the Nvidia GPU.
03:45
So, reverse prime is kind of the X term for it, so you kind of have to display it on the Nvidia GPU and copy the buffers and all that kind of stuff. I don't know how it's in detail, but yeah, that's kind of the thing.
04:01
Yeah, Optimus is the marketing term for it. Taito Nvidia, I don't know how it's called on Radeon GPUs, but yeah, that's kind of the thing. I was also working on having a near-backend for Novo,
04:22
so right now we can, compared to the old one where we used TGSi for the shader compilation, today we can also use near. It's still turned off by default, and at least I hope we can turn it on by default if it's reliable enough.
04:43
I know that there are some regressions, but supporting near is required, not technically, but how we do stuff in MISA right now, it's kind of required for OpenCL, for Vulkan, and for OpenGL 4.6, and that's, I think, also one of the reasons why Radeon SI moved to near by default,
05:03
because it gives them display support, which is required for OpenGL 4.6. It would be cool if people would start testing it, like running it with games or their normal desktop or something, and we have an environmental variable for that. You can set and then near is used.
05:25
For my testing I've done, I usually saw higher performance than with the TGSi perf, but I didn't spend time on any kind of performance optimizations. So if you test it and you see, oh, that one application is much slower than with the TGSi perf,
05:47
then I would be really interested in knowing about this. And also updates on OpenCL, I was working on that quite a lot last year.
06:03
The initial support was merged quite recently, and it's right now, I think, kind of supported on firmware newer. I only really tested it on Pascal, so there might be a lot of issues on other chips as well. I think Pierre is working on enabling it on Tesla as well,
06:24
which is the generation before for me. And if somebody really, really wants to play around with that, we also have an environmental variable to enable it as well. I'm sure that none of the applications work right now,
06:41
because the kernel compilation isn't really finished at this point. But if anybody's interested in it and thinks, yeah, maybe I want to do some OpenCL driver stuff, there's this nice OpenCL conformance test suite, which is testing most of the OpenCL features.
07:09
I would say it's much easier to fix those issues than, for example, jump into an OpenGL driver and figuring out what's wrong there. Because the runtime is way more simpler,
07:24
and it's more easy to follow what's actually going on there. I kind of called it staffing, because as an open source project, we don't really do staffing, but we have a few paid developers.
07:42
Besides myself, there's also Ben Skaggs working for Red Hat on the nouveau driver full-time. And we also have, for example, Lute, which is also part of the same team inside Red Hat, working a lot of fixing mostly display-related nouveau issues as well.
08:06
I'm also, how do I phrase it, in the same team, but I can't really spend that much time on the actual issues I would like to work on. But, I mean, it's still paid developers.
08:22
And we also have an intern at Red Hat, which is right now working on the nouveau shader cache, which kind of helps with, especially loading times of games and so on. And I think we did some testing, we saw improved speedups of three to four times faster
08:45
over shader compilation, because we can skip a lot of that in this area. I don't know how much relevant it is for games or something, but I hope that at least some games needing like four or five minutes won't take as long.
09:01
Yes? Nobody knew at the year working on a nouveau? I will come to that later. Oh, yeah, it was asked if there's anybody in NVIDIA working on nouveau. NVIDIA will be a topic for later.
09:23
Yeah, so we have also community members working on a nouveau driver. I think the most present one is Elia, which is doing a lot of, well, maybe not a lot, but he's doing quite some OpenGL stuff. He's implementing some new extensions,
09:43
fixing random issues. He's also working on some display-related stuff. Yeah, I mean, big thanks to him, because he's still working on a nouveau driver.
10:08
Quite a few of developers two or three years ago, most of them essentially moved on either by being hired by other companies and working on other drivers now,
10:20
or maybe just lost interest or something. Which makes it really hard for us right now, because we have a lot of issues to work on, or, for example, also want to implement a Vulkan driver, but we really don't have time for anything big anymore, essentially.
10:45
I mean, there are random contributions from random developers doing some stuff, but it's never something where I would say, oh, yeah, this really stands out, or there is this new guy putting a lot of work or a lot of time into it.
11:04
Yeah, it would be nice if I could get more people interested into the project. I know that it's difficult to work with, and I know that a lot of people are kind of feared about doing hardware stuff,
11:22
but I think if one is interested enough, they are able to work on that. Like, for myself, before I actually started to work on Novo, I was a Java backend developer, so I really did something completely different. I had no experience in hardware programming at all,
11:43
and I kind of just jumped into the project because I was thinking, yeah, I have this NVIDIA GPU, and I really want to have an open source driver for that, and there are issues, so I just started to work on that.
12:03
Yeah? Yeah, I mean, yes, Martin is right.
12:23
There are a lot of low-hanging fruits. I have a slide later on where I kind of list some tasks people could work on, but yeah, I want to talk about this later. What's also interesting is, like,
12:42
working together with NVIDIA, negative stuff first, and I think that's the most annoying part, or most of the most annoying thing for us right now is that getting firmware, because it has to be signed, otherwise the hardware doesn't execute it, and we needed to kind of access some states on the GPU.
13:06
We are not allowed with unsigned firmware, and it's required, for example, for OpenGL, and what we would like to have is that if new hardware is released, that we get on the same day the firmware
13:23
for using those GPUs. I don't really have numbers on how long it takes, an average, but I think we had a situation where it took around one and a half year for some generation, but might be less, might be more.
13:41
I really didn't look it up, so I don't want to make a concrete statement there. What's also annoying is, and it's true for power management as well, is we also need special firmware. The most annoying thing is
14:01
on the second generation of Maxwell, we could re-clock the GPU, and we know enough to do it, but what needs signed firmware is controlling the fans. You can have high speed, but the GPU would overheat because we can't make the fans faster.
14:23
That's annoying because we are so close, but we still can't do it. It's even worse on newer generations where even bits of the re-clocking itself, like changing the voltage, is essentially locked unless you have signed firmware.
14:45
There were thoughts about doing the same. We do also for the video acceleration where you're essentially extracted from the individual driver, but it's kind of really annoying because that would mean, yeah, distributions or user have to manually execute a script
15:00
every time they install their distribution, then it has to be extracted, and then we have to reverse engineer the interfaces, and those change essentially every driver version, so it would be super annoying, and a lot of work we also don't have time for.
15:20
There are also good things in regards to NVIDIA, is that overall, at least myself, I get the feeling that it's improving over time. It might be not that obvious to others because we also... I have to be a little bit careful
15:41
what I'm talking about because we have some partnership with NVIDIA from a retro perspective, so I know a little bit more, but I can't really tell about much. But at least what we're working on with NVIDIA is getting documentation out,
16:00
and they actually have a Git repository on GitHub, and you can essentially see the commit history, and there is some useful stuff going in there, especially documentation for the displays, interfaces of how do we program the GPU to drive the display,
16:22
and how to program the MMU as well for doing memory-related stuff. So that's super helpful, and I hope that there will be more useful documentation, also for different areas, but we just have to wait and see what's happening there.
16:43
Terry is employed by NVIDIA, and he also works on Tegra code mostly. He's doing upstreaming of a lot of Tegra bits for the core kernel, like just using the Tegra devices,
17:00
and it's not that much novel-related, but there's also some novel contributions to fixing random issues or having this Tegra Galium driver as well. So that's also cool, and it's really good to see that there's at least some people at NVIDIA really dedicated to this.
17:23
Also, there is on the mailing list, if you scroll through it or search for people with an NVIDIA email address, there are some patches from NVIDIA people, which is also quite cool, and I hope there will be more in the future.
17:42
Some stuff we are currently working on is the biggest thing, most likely, getting OpenGL 4.4 and 4.5 ready. There's this kind of requirement to pass the official kernel's conformance test read.
18:01
I think on some GPUs, we are at a stage where we pass every test, but there are random failures if we run the full thing, because the full thing does, I don't know, 30 iterations of the test with different parameters, and last time I did this, the first failure was after 10 hours of running it,
18:23
and it's super painful to debug, and it's probably some random issue of not initialized memory or something random. We have no idea. Also, I'm not really in the mood of having to wait for 10 hours to hit a bug just to debug it,
18:41
so that's a little bit annoying, but we are getting there, and earlier I was also fixing a lot of issues, and myself as well. Hopefully, soon as we get official OpenGL 4.5 support. We also would like to improve the performance.
19:01
There are sometimes random shader optimizations landing in the tree. For example, also the near work could lead to improved performance, but sadly, we really can't do really, really big reworks to improve the performance in a way
19:21
like the Intel guys or Radeon guys are doing where they essentially use different interfaces of VISA or rework certain other areas. Building a CI system, we would also have something wired up to the free drive stop GitLab CI system.
19:44
I don't know if all of you heard about this, but right now we have a CI pipeline on the Git repository whenever somebody opens an MR or somebody pushes to the master branch that we have this software and hardware pipeline
20:02
testing if commits request something. We do test the software vendors, but there are also instances really testing it on hardware, and I would want to have the same for NuVAR as well. I kind of have to see how much time it consumes because maintaining such a system
20:22
can be very time consuming, but let's see how that goes. OpenCL support is also what we are still working on, and I hope I will be done with it soonish.
20:45
There are a few shaded kernel compilation stuff that we still have to figure out. And what we are also working on is
21:00
getting OpenCL support for Volta and Turing. Volta isn't really relevant to any users because I don't think anybody has this super expensive Volta GPU, but it's kind of similar to Turing, so it's essentially the same work. And once we get the firmware
21:21
for hardware acceleration for those as well, we want to have this be done inside Mesa as well, so users can finally use OpenCL on Turing GPUs as well.
21:44
Important things we really want to fix is, I think the most prominent issue is the runtime power management issue. There are a lot of laptops where you have an NVR GPU, and when we turn it off, then it fails to turn on.
22:02
And usually it leads to the system crashing or people not being able to boot the Linux installer, and then they have to disable the runtime power management stuff. What's kind of annoying about this issue is that I have no idea what's wrong there,
22:23
and nobody else was able to help as well. So I was talking with AppSim developers about this issue, and there was no real conclusion on that either. We also have no idea if it's a driver bug inside NuVu
22:43
or maybe it's a hardware bug, or maybe it's a kernel bug. What's kind of interesting is that it only happens with a certain internal bridge controller and not with any else. So maybe it's a hardware bug.
23:00
The biggest problem is just that the firmware code involved with turning off the GPU is accessing undocumented registers, so we don't even know if what we are doing is even correct or maybe we have to do some things before doing so, but there's also no public documentation on that, so that's super annoying to fix.
23:22
Is it coming up from NVIDIA? Some serious help? Excuse me? Is some serious help in that direction? So the question is if there's any help from NVIDIA from that direction.
23:40
Kind of. Kind of? I can't really... No real information here. No, there's not anything useful coming out. What I kind of hoped what would happen because the official NVIDIA driver supports this on the latest driver for tiering GPUs as well, so they have no support for turning off and on the GPU,
24:02
but if we do it on tiering with NuVu, it works. So I can't really say. I would like to reverse engineer it with older GPUs, but if the driver doesn't support it, I can't do it as well. I tried to request information from NVIDIA on this,
24:20
but they... Don't get it. I really don't know. I didn't get anything useful. Let's put it this way. Does a similar issue happen if you put a hardware passcode to virtual machine to have a key event, for example? So just a comment or a question?
24:43
Does the decision happen when you do that? So the question kind of was that a similar thing happens with device passcode as well, and if it's kind of related or not,
25:03
now it's a different thing. I mean, it's totally unrelated. The runtime power management is usually something which is only implemented in laptop firmware, so it's really a firmware-level feature of cutting the power on the PCIe device. I remember a few issues with device passcode,
25:23
but no, it's a different thing. What might also be relevant in the future is that right now devices are not hot unplugable. This is mostly relevant for eGPU cases where users have their case, and they are unplugging the device, and then the kernel just crashes right now.
25:43
I noticed that on a few generations, it doesn't crash, but user space is still screwed up. It's one of the bigger rework we would like to do because it essentially touches all of the driver because at any point the device can just vanish,
26:03
and you kind of have to deal with it in the kernel driver. kernel drivers for GPUs are quite huge, and if you lose the assumption of, yes, my device is always there, a lot of things you can't really rely on anymore
26:24
because right now, if you want to access device memory, we just do it. There's no check for is the device still there or not. That is a little bit bigger rework,
26:40
but if somebody is interested in fixing this, the biggest advantage is that there's no hardware knowledge required at all. It's essentially just unplugging it, and you see this kernel crash, and then you try to figure out how to fix it. It's kind of straightforward, but it's a lot of work.
27:01
What we also really would like to fix in user space or work on is multi-threading. That's mostly an issue which comes up with Chromium, for example, because they're doing multiple context, OpenGL context in the same different-
27:24
Given more Chromium, one new file, there's no hardware acceleration there. If it turns it on, I get problems on various websites. That's for humanity now. That's one of the reasons. There are also other reliability issues
27:42
because rendering can fail or there can be random corruptions, but I think what really drove the decision from Google was that the multi-threading thing really causes the GPU to just crash.
28:03
What's also happening is there are a lot of Chromium-based applications which also have to maintain their own blacklist, I think, so there are other applications having the same issue and essentially just crashing. There are also a few games, I think, doing multi-threaded rendering or OpenGL,
28:24
and the core issue is that you just corrupt the application state or the Mesa state as well, so we send invalid commands to the GPU, and then the GPU might also just crash. Sometimes the Mesa just crashes, so it's really annoying,
28:41
but we would like to work on or fix that. We also would like to have a Vulkan driver. I think right now the main reason why we can't do that is because we would like to have a new kernel interface for the Novo drive in order to properly implement Vulkan as well,
29:01
which also would require us to revert the Mesa driver at some point as well, but it would lead to a more reliable driver. Context recovery is also kind of something a lot of drivers are implementing as well, is that sometimes it can happen that the GPU context
29:23
or the GPU just crashes, and we would like to recover from that. In the past, what I saw and some users as well is that it could happen that the GPU context crashes, user space never knows about this, and X just freezes.
29:42
So the user is not able to do anything. They can't even switch to the TTY in order to restart X or something, so they just have their machine, nothing happens anymore, and they have to essentially force reboot. There are some improvements with that, with the 5.6 kernel,
30:01
and hopefully most applications will now just crash if that happens, but if anybody of you have this case with the updated kernel, or you still have a freeze and your system just doesn't do anything anymore, then just contact us, and we will see what's the reason for this.
30:23
But hopefully that doesn't happen anymore. Question? Do you have any kind of guesstimate of how many years away a reliable Vulkan driver would be? So the question was,
30:40
how many years are we away from a reliable Vulkan driver? I don't know. I mean, Vulkan driver is usually less work than an OpenGL driver, but there are also a lot of additions to Vulkan happening. I really don't know. I mean, hopefully it's not that far away.
31:03
Combined forces together with Intel and AMD that also want a Vulkan driver. Yes, but we are already having shared stuff
31:20
with Intel and AMD on the Visa driver. So there are some common things, especially the SPIRVE compiler stuff, because Vulkan requires SPIRVE, and we have the SPIRVE to NEAR thing inside MISA, which is shared by all the Vulkan drivers. So at least in this area, we can just make use of what's already there.
31:43
There's also dispatching stuff, like if you call a Vulkan function, then the runtime has to check, oh, does it actually is implemented by the driver or not? So there are also shared code in this area. I think there are other bits as well. But yeah, I mean, there is stuff like this,
32:01
and I think the main goal is to get to a point where drivers really only have to implement their hardware-specific bits. What we also would like to work on is mainly debugging features.
32:21
Right now, if we encounter a bug, it's usually always a lot of work to figure out what's actually happening there. For example, we can't debug a shader, which is super annoying, so we can't see, oh, what's the value of this register? Or why did this shader loop forever or something?
32:41
It's really painful to debug right now such issues because it usually means, oh yeah, I have to adjust the GLSL code to figure out why does something happen? That usually takes more time than, for example, let's say just turn on a debugger and see what the shader is doing. We can't do that. We would like to do that.
33:02
There was some reverse engineering in this direction done already a lot of years ago, but yeah, it's not implemented yet. If anybody is interested to help us out on that
33:21
and has, essentially, NVIDIA GPUs and has these issues or something, it's always a good idea to try to look into that themselves. I mean, that's how I started to work on Nuvo. I just had issues related to reclocking,
33:40
and I was looking into it and figure out what's wrong. If there are some issues which really annoys you and you would like to get it fixed, you could try to look into this as well. We can always help with stuff, so if you're interested,
34:01
just try to do this, please. Being interested and motivated also is kind of a huge thing, of course. If you are not motivated, then nothing will come out of it. Especially for students, if they also want to get some money while doing that,
34:20
we would be happy to do also GSoC or EVOC programs, which is essentially kind of, you get money to work on open source project as an intern, like kind of intern life. I mean, can't really say it. It's not an internship, but it's essentially, there is some evaluation going on,
34:43
and we say, okay, this person is skilled enough to work on that, and then they get paid for, I think, GSoC is three months. I don't know the details of EVOC, but yeah. So there's money, and you're working on open source projects.
35:01
What's also kind of good entry-level task is compiler optimizations. Most of you, or some of you might have been, oh, but that sounds super complicated, but a lot of optimizations are just simple math. So you have special patterns and shaders,
35:22
which you can reduce to a simpler set of instructions just by applying some math to it, essentially. There are also more complicated compiler optimizations, but that's kind of the more trivial ones where you just see, oh, maybe there's a shift
35:40
in the left direction and in the right direction. Maybe I can also just apply an and if it's by the same amount of bits. What's also kind of fun project would be to use some GPIOs.
36:00
There are several of them on NVIDIA GPUs. Some of them just control the LEDs on GPUs, for example. Some of them get triggered when you don't have the external power connected to the GPU, and there are a lot of random stuff like this.
36:23
Maybe if some is more akin to work on hardware-level stuff, that's also something cool to work on. And we also have some fan-controlling issues where we actually got documentation for as well, and it's still a thing on our to-do list,
36:42
but if somebody else has a GPU where the fan-controlling is really odd, like if you have more load, the fans could get slower. I have a GPU like that myself as well, which is something which shouldn't happen, but if you find such odd issues with your GPU as well,
37:05
maybe if you want to look into it, that would also be a cool thing to look into. I think I'm done. There are a few links you can always look into as well.
37:26
Mostly we are on the IRC channel around talking with users if they have complaints or bugs or something. And we also have the Trello board where a lot of tasks are listed.
37:43
Maybe I can open it. But I think that's essentially it. Yeah, so I don't have anything anymore. Any questions or comments or maybe even suggestions?
38:09
I thought it's on the wiki. Yeah, I'm sure it's there, but if it's not, then yeah.
38:34
The question was if we have to do anything special for virtual GPUs. No, we don't.
38:41
It's essentially the same GPU. I think there are some virtual cards which have certain hardware features enabled, like double floating point precision performance. Usually on GeForce cards, you have really slow double precision performance,
39:01
but it doesn't matter because games are not using it. But besides that, I'm not really aware of anything. I mean, what I was actually working on is that in the past, if you used the NVIDIA driver only on virtual cards, you got the power consumption. And I've implemented it for GeForce cards as well.
39:23
Because it was just really a software check to turn it on or off in the NVIDIA stack. But yeah, generally it's the same. Yes? So I was curious about the version of OpenCL
39:42
that you were using. So the question was what OpenCL version we are targeting. Right now, the OpenCL runtime in MISA is implemented on a 1.1 level.
40:01
And at least that's what we are trying to match. But I was also working on some OpenCL 2.0 features, or Pierre was also working on consuming SPIRV, which is an OpenCL 2.1 feature.
40:21
So yeah, I mean, there are interested features in OpenCL, one which are cool to implement. But yeah, I mean, right now we are trying to get it to work first, and then look into implementing more features.
40:50
Any choice. But I never managed to, is there still development for those old cards?
41:03
So the question was if there's still development for old cards. Yes, if somebody has time to look into it. So I mean, the kind of the bad and the good thing is we are not a company, so we can just take care
41:21
of issues on older hardware because we don't have the pressure on only supporting the newest thing because we want to sell hardware. But on the other hand, we also don't have enough people to look into all the issues. If there's a bug on like 10 years old GPU and somebody fixes it, then we also would like to merge it, yes.
41:43
Yes? So I saw that you have some paid core developers. Who pays for his work and why? What is the interest of these companies? So Red Hat is paying for all of them, and the reason for doing so is just because of RAL.
42:01
RAL, Red Hat Enterprise Linux. And I mean, it supports the desktop, and because you want to make use of the GPU as well, you need the Novo driver because Red Hat doesn't want to ship any proprietary blobs, so Novo is the only thing.
42:22
I see the same firmware from NVIDIA for the clocking and the fun control. Does that require any additional work in Novo itself? The question was if using the firmware provided from NVIDIA causes additional work.
42:42
Yes, the firmware is executed on core processes on the GPU, and you also need a communication channel to the chips as well, to the CPUs as well. So that's one thing we have to work on. Also, the signature stuff,
43:00
because they are signed, requires a booting process which gets more complicated by the generation. So you have a core security chip which has to get booted, and then it boots the other processors with other firmware, and the signature stuff is different again,
43:21
and you have to allocate secure memory so the driver can tamper with it while the boot process is ongoing and stuff like that. So that's kind of the thing. The advantage of getting the firmware is we don't have to implement the firmware ourselves.
43:42
That's what we've done on older generations where we have the firmware for power management, especially useful on Tesla and Kepler because we do the memory with clocking on the PMU, which is one of the core processors,
44:02
but we also have firmware for context switching. So if you have multiple hardware contacts on a GPU, they have to get switched at some point, and on NVIDIA GPU, that's also done on those core processors. Yes?
44:20
Now that Red Hat belongs to that, to put more weight behind that. I mean... Can you repeat the question? Yeah. The question is if now that Red Hat got bought by IBM, if they are able to put more money into it.
44:42
I mean, they certainly could because it's a bigger company with more money than the Red Hat, but even if I would know about plans, I wouldn't be allowed to talk about it. So, yeah. I mean, the most obvious thing is yes, they could because they have more money.
45:04
I don't know. Yes? When you talk about debugging, you mentioned that there is problems in memory production going on. Is it possible to have an other site or something like that to build a kernel module?
45:22
No. The question was that, because I was talking about debugging, if it's memory corruptions, why we can't use address sanitizer? I was talking about GPU debugging. Like, all the sanitizers don't work with GPU memory. So...
45:40
So it's memory corrupts from GPU or not? Yeah. Yes. I mean, for example, the multi-threading issues we can fix with the address sanitizer. The problem is just that the cause is much more complicated than just throwing in some logs. Because if you throw in too many logs,
46:00
then the performance goes down. So there's no benefit of doing multi-threading. Sure, we could, but also kind of the architecture of how we're doing things make it really annoying to do so. Yeah. To make a log of what's driven into the GPU
46:23
and then when it dies, have at least a backtrack of what happened before. So you cannot read state anymore when it's crashed, but then you can at least see what was the last thing that happened. So the question was... Slow down things, of course, but...
46:42
So the question was if we could throw in a log so we know what happened last on the GPU before it crashed. Yes, we have that. With 5.6, Ben added a feature where... I don't even know... No, it's a kernel feature where
47:01
if you send commands to the GPU, you can do it in a synchronous way. And if the GPU crashes, we know what command submission was done last. It helps a bit, but a command submission can also be like 100 or 1000 commands.
47:21
But yeah, I mean, we could also do the command submission smaller then and then figuring out what's happened. So yeah, we have something like this now.
47:43
Okay, then I think I'm done.