Future of nouveau/nova's display driver, and rvkms introduction!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]<

 



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





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux