Kepler ( Nvidia GTX 770M) + Wayland = No Go

loveydovey

loveydovey

The GTX 770M is based on NVIDIA's Kepler architecture. Kepler support was officially dropped after the 470.xx legacy driver series. It cannot use the modern 5xx series drivers.

Modern Wayland compositors (Sway, Hyprland, Wayfire, Labwc, modern GNOME/KDE) require GBM (Generic Buffer Management) and modern KMS (nvidia-drm modeset=1). NVIDIA did not implement generic GBM support until driver 495.xx.

The 470.xx series relied on NVIDIA’s proprietary EGLStreams protocol, which almost all modern Wayland compositors have completely dropped. Furthermore, FreeBSD’s port of nvidia-drm.ko (needed to run Wayland directly on proprietary NVIDIA) is tailored toward modern driver branches.

In summary, the only way to use Nvidia GTX 770M on FreeBSD is to use X11. Let this be an obituary for Nvidia Wayland support for this card. In its good days in 2010 it even mined something like a quarter of a bitcoin or something.
 
loveydovey one viable option is to bring nouveau+nvk to the drm tree. That would cover both OpenGL and Vulkan (Kepler and above, +OpenCL but no CUDA). The performance differences are reducing with each upstream release. NetBSD supports at least the nouveau driver and has a similar approach to FreeBSD to DRM (but different implementation of LinuxKPI) and can be used as reference.

Open issues with this solution:
  • Deciding which is the cutoff point:
    • for a modesetting only solution the starting support is G80+ (i.e. X11+Wayland)
    • for cards older than G80 the target would have to be X11 only and it would also need re-importing on the X11 tree the DDX driver
  • nouveau's licence should be compatible with FreeBSD, but I'm not sure about the nvk code
  • the gpu blobs (for Kepler+) will also need coordination with the current maintainers, maybe some package spliting is needed
  • nouveau covers a lot of hardware, how will validation work be done?
  • the Foundation sponsorship on DRM updates will probably not cover this work
I tried doing this but it had to leave it due to lack of time for both doing the initial work as well as the ensuing maintenance that would be required.
 
Nouveau was once tried to be ported and been in ports tree as x11-drivers/xf86-video-nouveau for a while, but soon abandoned. As far as I know (lost track of the sources), it never become stable and usable on FreeBSD while in ports tree.
And even if it's running on NetBSD, unless LinuxKPI (or alike) on both are almost the same, porting it would require non-trivial works.
 
T-Aoki said:
Nouveau was once tried to be ported and been in ports tree as x11-drivers/xf86-video-nouveau for a while, but soon abandoned. As far as I know (lost track of the sources), it never become stable and usable on FreeBSD while in ports tree.
And even if it's running on NetBSD, unless LinuxKPI (or alike) on both are almost the same, porting it would require non-trivial works.
Click to expand...
yeah, that previous work would probably be thrown out of the window now. It was for more simple times :p
As far as I understood from the netbsd code that I looked at their approach was similiar in terms of how to handle drm code, i.e. leave it as close to upstream as possible. The differences are mostly on the KPI glue which is different.
 
fahrenheit said:
yeah, that previous work would probably be thrown out of the window now. It was for more simple times :p
As far as I understood from the netbsd code that I looked at their approach was similiar in terms of how to handle drm code, i.e. leave it as close to upstream as possible. The differences are mostly on the KPI glue which is different.
Click to expand...
At best, macro to override different function names in glue codes would be what's needed, but maybe not and far more complexed. I can't be optimistic here.
 
You must log in or register to reply here.
Back
Top