 Okay. Hi. Is the sound okay? Okay. Cool. So, I want to give a status update on Nouveau. We kind of missed last year, so we are really sorry about that, but luckily it worked out this year, even though we missed the CFP and everything. Yeah, but let me just start. 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, open GL 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, 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 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-transert. You can use it at this place with the Nouveau driver. 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. 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 that 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, but hopefully we get there as well. Lute 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, so there were a lot of random failures. Lute 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. If you know of some, just yes? What is reverse-prime? Oh, 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 via to the NVIDIA GPU. 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, or maybe, I don't know how it's in detail, but yeah, that's kind of the thing. It's called optimus. Yeah, optimus is the marketing term for it. 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 back end for Novo, so right now we can compare to the old one where we used TGSI for the shader compilation. Today we can also use the nearer. It's still turned off by default, and at least I hope we can turn it on by default if it's reliable enough. I know that there are some regressions, but supporting is required, not technically, but how we do stuff in Mesa 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 because it gives them this movie support which is required for OpenGL 4.6. It's what we call 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 as used. For my testing I've done is I usually saw higher performance than with the TGSI path, but I didn't spend time on any kind of performance optimizations. So if you test it and you see all that one application is much slower than with the TGSI path, then I would be really interested in knowing about this. Also updates on OpenCL. I was working on that quite a lot last year, the initial support was merged quite recently, and it's right now I think kind of supported on Fermi and newer. I only really tested it on Pascal, so there might be a lot of issues on other chips as well. I think Pia is working on enabling it on Tesla as well, which is the generation before Fermi, 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 application work right now, because the kernel compilation isn't really finished at this point, but if anybody is 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. I would say it's much easier to fix those issues than, for example, jump into an OpenCL driver and figuring out what's wrong there. Because the runtime is much more, way more simpler 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 I mean, we have a few paid developers. Besides myself, there's also Ben Skaggs working for Redhead on the Novo driver full-time, and we also have, for example, Lude, which is also part of the same team inside Redhead, working a lot of fixing mostly display-related Novo issues as well. 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 like paid developers. And we also have an intern at Redhead, which is right now working on the Novo 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, like, speed-ups of three, two, four times faster over, like, shader compilation because we can skip a lot of that in this area. I don't know how much relevant it's for games or something, but I hope that at least some games needing, like, four or five minutes won't take as long. Yes? Nobody knew at NVIDIA working on a Novo? I will come to that later. Okay. Oh, yeah, it was asked if there's anybody in NVIDIA working on Novo. I will, NVIDIA will be a topic for later. Yeah, so we have also community members working on a Novo driver. I think the most present one is Ilja, 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, fixing random issues. He's also working on some display-related stuff, but, yeah, I mean, thanks to him because he's spending, like, still working on a Novo driver. What's kind of... 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 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 really don't have time for anything big anymore, essentially. And 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. So, yeah, would be nice if I could kind of 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, but I think if one is interested enough, they are able to work on that. Kind of 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 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. Yeah, I mean, yes, Martin is right, there are a lot of low-hanging foods. 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 the working together with NVIDIA, negative stuff first and I think that's the most annoying part or 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, 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 hardware at the firmware for using those GPUs. I don't really have numbers on how long it takes in 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. 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 on the second generation of Maxwell we could reclock the GPU and we know enough to do it but what needs signed firmware is controlling the fans so you can have high speed but the GPU would overheat because we can't make the fans faster and that's annoying because we are so close but we still can't do it and it's even worse on newer generations where even bits of the reclocking itself like changing the voltage is essentially locked unless you have signed firmware and there were thoughts about doing the same we do also for the video acceleration where you're essentially extracted from the driver but it's kind of really annoying because that would mean distributions a user have to manually execute a script every time they install a 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. But 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 like I have to be a little bit careful what I'm talking about because we have some partnership with NVIDIA from a better perspective so I know a little bit more but I can't really tell much right but at least what we're working on with NVIDIA is getting documentation out 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 how do we program the GPU to drive the display and what we do 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 Terry is employed by NVIDIA and he also works on Tecra code mostly I mean he's doing upstreaming of a lot of Tecra Brits for the core kernel like just using the Tecra devices and it's not really not that much novel related but there's also some novel contributions to fixing random issues or having this Tecra gallium driver as well so that's also cool and really good to see that there's at least some people at NVIDIA really dedicated to this 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 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 I think on some GPS we are at a stage where we pass every test but there are random failures if you want the full thing because the full thing does like I don't know 30 iterations of the test with different parameters and last time I did this was like the first failure was after 10 hours of running it 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 and I'm also I'm not really in the mood of having to wait for 10 hours to hit a bug just to debug it so that's a little bit annoying but we are getting there and NVIDIA was also fixing a lot of issues and myself as well so hopefully soon as we get official OpenGL 4.5 support we also would like to improve the performance there are sometimes random shader optimizations landing in the tree for example also the NVIDIA work could lead to improve performance but sadly we really can't do really really big revokes to improve the performance in a way like the Intel guys or Radeon guys are doing where they essentially use different interfaces of MISA or we work certain other areas building a CI system we would also have something wired up to the FreeJoyStop GitLab CI system 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 testing if commits regress something so we do test the software but there are also instances really testing it on hardware and I would kind of want to have the same for Nuvorus well I kind of have to see like how much time it consumes because maintaining such a system can be very time consuming but let's see how that goes right OpenGL support it's also what we are still working on and I hope I will be done with it soon there are a few shade kernel compilation stuff we still have to figure out but and what we also right now working on is getting OpenGL 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 of hardware acceleration for those as well we want to have this be done inside Mesa as well so users can finally use OpenGL on Turing GPUs as well important things we really want to fix is I think the most prominent issue is the one time power management issue there are a lot of laptops where you have an NVIDIA GPU and when we turn it off then it starts to turn on and usually it goes to the system crashing or people not being able to put the Linux installer and then they have to disable the run time power management stuff what's kind of annoying about this issue is that I have no idea what's wrong there and nobody else was able to help as well so we were talking with AppSim developers about this issue and there was no real conclusion on that we also have no idea if it's a driver bug inside Nuvo or maybe it's a hardware bug or maybe it's it's a kernel bug what's kind of interesting that it only happens with a certain Intel bridge controller and not with any else so maybe it's a hardware bug 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 it's coming up from NVIDIA some serious help in that direction so the question is if there's any help from NVIDIA from that direction kind of kind of no real information 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 Turing GPUs as well they have no support for turning often on the GPU but if we do it on Turing with Nouveau it works so I can't really say maybe like 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 or I try to request information from NVIDIA on this but they I really don't know I didn't get anything useful let's put it this way so the question kind of was that a similar thing happens with device pass through as well and if it's kind of related or not now it's a different thing it's totally unrelated the one-time 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 of a few issues with device pass through yeah but no it's a different thing what might also be relevant in the future is that right now devices are not hot unpluggable this is mostly relevant for each GPU cases where users have their case and they are unplugging the device and then the kernel just crashes right now so I noticed that on a few generations it doesn't crash but user space is still screwed up the most annoying 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 and you kind of have to deal with it in a kernel driver and kernel drivers for GPUs are quite huge and if you have this assumption that like if you lose the assumption of yes my device is always there a lot of things you can't really rely on anymore because right now if there is if you want to access device memory we just do it there's no check for is the device still there or not so yeah that is a little bit bigger rework but if somebody is interested in fixing this the biggest advantage is that there's no hardware knowledge required at all and 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 so so what we also really would like to fix in user space of work on is multi-threading that's mostly in issue which comes up with Chromium for example because they are doing multiple contexts OpenGL context in the same like different this is the reason that Google turned it off hardware acceleration if there's a Chromium on Nouveau there's no hardware acceleration so if it turns it on I have problems on Nouveau that's what you mentioned that's one of the reasons I mean there are also other reliability issues because rendering can fail or it 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 you know or the application to just crash and what's also happening is there are a lot of Chromium based applications which also have to maintain their own blacklist I think having the same issue and essentially just crashing there are also a few games I think doing multi-threaded rendering or OpenGL and kind of the core issue is that we 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 but yeah we would like to work on 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 driver in order to properly implement Vulkan as well which also would require us to rework 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 implement as well is that even sometimes it can happen that the GPU context 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 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 and hopefully most applications will now just crash if that happens but if anybody of you have this case with the updated kernel that 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 but hopefully that doesn't happen anymore um question do you have any kind of estimate of how many years are we away from a reliable Vulkan driver so the question was how many years are we away from a reliable Vulkan driver I don't know I mean Vulkan driver is usually less worth than an OpenGL driver but there are also a lot of additions to Vulkan happening so I really don't know I mean hopefully it's not that far away combined forces together with Intel and AMD that also want the Vulkan driver yes but we are already having shared stuff with Intel and AMD on the Mesa driver so there are a lot there are some common things especially the Spurvy compiler stuff because Vulkan requires Spurvy and we have the Spurvy Tunea thing inside Mesa which is shared by all the Vulkan drivers so at least in this area we can just make use of what's already there there's also like this patching 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 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 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 what's the value of this register or why did this shader loop forever or something 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 there was some reverse engineering in this direction done already like a lot of years ago but yeah it's not implemented yet so and if anybody is interested to help us out on that 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 Nouveau I just had random or I had issues related to clocking and I was looking into it and figure out like what's wrong and if there are some issues which really annoys you and you would like to get it fixed you could also you could try to look into this as well we can always help with stuff so if if you're interested 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 and especially for students if they also want to get some money while doing that we would be happy to do also GSOG or EVOC programs which is essentially kind of you get money to work on an open source project as an intern like kind of intern life I mean can't really say it's not an internship but it's essentially there's some evaluation going on and we say okay this person is skilled enough to work on that and then they get paid for I think GSOG 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 what's also kind of good entry level task is compiler optimizations most of some of you might think oh but that sounds super complicated but a lot of optimizations are just simple math so you have you know special patterns and shaders which you can reduce to a simpler set of instructions just by applying some math to it essentially they're also like more complicated compiler optimizations but that's kind of the more trivial ones where you just see or maybe there's a shift in the left direction and in the right direction maybe I can also just apply an end if it's by the same amount of bits um what's also kind of fun project would be to use some GPU GPIOs there are several of them on NVIDIA GPUs some of them just control the LEDs on GPUs for example some of them gets triggered when you don't have the external power connected to the GPU and there are a lot of random stuff like this 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 still like thing on our to-do list 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 that shouldn't happen but if you find such odd issues with your GPU as well 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 mostly we are on the IRC channel around and 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 maybe I can open it yeah but I think that's essentially it yeah so I don't have anything anymore any questions or comments or maybe even suggestions I thought it's on the Wiki yeah I'm sure it's there but if it's not then the question was if we have to do anything special for quadro GPUs no we don't it's essentially the same GPU I think there are some quadro cards which have certain hardware features enabled like double floating point precision performance usually on GeForce cards you have really slow double precision performance but it doesn't matter because games are not using it but besides that I'm not really aware of anything I mean there was what I was actually working on is that in the past if you used the Nvidia driver only on quadro cards you got the power consumption and I implemented it for GeForce cards as well for Innova really a software check to turn it on or off in the Nvidia stack but generally it's the same yes yeah so the question was what OpenCL version we are targeting right now the OpenCL runtime in MISA is implemented on a 1.1 level 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 SpeoV which is an OpenCL 2.1 feature so yeah I mean there are interested features in OpenCL 1 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 any still developments for those old cards so the question was if there is still development for old cards yes if somebody has time to look into it I mean the kind of the bad and the good thing is we are not a company so we can just take care of the 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 is a bug on like 10 years old GPU and somebody fixes it then we also would like to merge it yes so I saw that you have some paid core developers who paid more and why what is the interest so Wetted is paying for all of them and the reason for doing so is just because of well well Wetted Enterprise the Nox 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 Wetted doesn't want to ship any proprietary blobs so it's the only thing the question was if using the firmware provided from Nvidia causes additional work yes the firmware is executed on co-processors on the GPU and you also need a communication channel to this chips to the CPUs as well so that's one thing we have to work on also the signature stuff like because they are signed requires booting process which gets more complicated by the generation so you have like a core security chip which has to get booted and then it boots the other processors with other firmware which stuff is different again and you have to allocate secure memory so the driver can't temper with it while the boot process is ongoing and stuff like that so that's kind of the thing which the positive like the advantage of getting the firmware is we don't have to implement the firmware ourselves that's what we've done on older generations where we have the firmware for power management especially useful for on Tesla and Kepler because we do the memory we're clocking on the PMU which is one of the co-processors 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 co-processors yes now that Rathad belongs to IBM is it possible to put more weight behind I mean the question is if now that Rathad got spot by IBM if they are able to put more money into it I mean they certainly could because it's a bigger company with more money than Rathad but even if I would know about plans I wouldn't be allowed to talk about it so I mean the most obvious thing is yes they could because they have more money I don't know no the question was that because I was talking about debugging if there are memory corruptions why we can't use address sanitizer I was talking about GPU debugging all the sanitizers don't work with GPU memory for example the multi-ferring 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 then the performance goes down so there's no benefit of doing multi-ferring sure we could but also kind of the architecture of how we're doing things make it really annoying to do so yeah so not you cannot read state anymore when it's crashed but then you can at least see what was the last thing that happened so so the question was so the question was if we could throw in a log so we know what's happened last on the GPU before it crashed yes we have that we're 5.6 Ben added a feature where I don't even know no it's a kernel feature where 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 comments but yeah I mean we could also do the command submission smaller then figuring out what's happened so yeah we have something like this now okay then I think I'm done