Lyude Paul
2024-Feb-06 22:13 UTC
Future of nouveau/nova's display driver, and rvkms introduction!
Hi everyone! As I'm sure a number of you are aware, since Nvidia's release of the GSP firmware a lot of things have changed for nouveau. In particular, the interfaces which we use for controlling the hardware from nouveau have changed pretty dramatically in many areas as a result of going through the GSP instead of directly interfacing with various hardware registers. Enough so that at least outside of modesetting, there isn't much potential for codesharing between non-GSP devices and GSP devices. As such a few folks at Red Hat, myself included, have been working on writing up a new kernel driver intended solely for GSP devices known as nova: https://gitlab.freedesktop.org/dakr/nova As well, nova is a rust based driver - something we're hoping will become much more common in the kernel as a result of this project (and the efforts of other projects like Asahi!). Of course, you'll notice I mentioned earlier that most of the GSP changes have been outside of the area of modesetting. This is to say that while modesetting with nvidia hardware hasn't remained totally the same, it's mostly the same: we've only had a small number of modesetting interfaces moved into the GSP, and the evo/nvdisplay architecture remains largely identical to what it looked like pre-GSP. This of course led us to the question of whether we should try sharing a modesetting driver with nouveau, or if the effort of having a C based modesetting driver alongside a rust counterpart would be too much work. Eventually, while it would have been nice to have done code sharing here - we ended up deciding that it probably would be more work then it's worth, and that it wouldn't be a bad idea for us also to write up a new modesetting driver for nova in rust so that we don't have to maintain a Rust <-> C layer within nova. It's going to be a while before writing this driver starts though, since there's not much we can do without having nova a bit further ahead in the driver bringup-process. So? For the time being, to figure out a set of rust bindings for KMS drivers in the kernel I've been working on a small project called rvkms! https://gitlab.freedesktop.org/lyudess/linux/-/commits/rvkms The basic idea is to figure out as much of the KMS bindings as we can before we're at a point where it's possible to start writing up a modesetting driver for nova. RVKMS as you may have guessed, is intended to be a port of VKMS to rust. We choose VKMS since it's got a very small codebase, and only really implements the minimum requirements for an atomic KMS driver. Currently I'm not planning on upstreaming rvkms itself, however if there's actually enough interest in such a driver being upstreamed I certainly wouldn't be against it :). At the moment I don't have much more then a basic skeleton driver that's based off the nova development branch (currently the 6.6 branch, but I'm currently rebasing it to the latest 6.7 branch), but I hope to have more in the near future as I'm currently working on writing up KMS bindings. If anyone has any questions or comments feel free to reply :)! -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat