FreeBSD Will Pay For Some KMS & GEM Love

Chris Wilson of Intel back in July had written a branch of the Intel X.Org display driver (xf86-video-intel) that added back user-space mode-setting support to their open-source driver that did not need the Graphics Execution Manager (GEM) within the kernel to function. This code was previously stripped away from the driver previously since KMS+GEM is the future they wanted to head in, but for those with vintage Intel i8xx-era graphics hardware using these newer code paths frequently resulted in lock-ups and other problems. Rather than trying to solve the actual problem at hand of GEM and KMS for this old hardware, the easier solution was viewed to just add back non-GEM UMS support.

This user-space mode-setting support without any dependence on the kernel code didn't end up fixing the problems it was meant to solve for i8xx owners and resulted in a greater burden for the Intel developers with an extra ~40,000 lines of code to maintain and support. This didn't go over too well. But at the same time, this work had the nice side effect of helping out those on OpenSolaris, the *BSDs, and other Unix-like operating systems that don't yet have kernel support for KMS or GEM, as this driver then worked again on those platforms and thereby provided support for newer Intel IGPs and features added after the UMS support was dropped almost two years ago.

This UMS code-path though didn't end up being integrated back into the mainline xf86-video-intel driver, but instead another alternative came about and that is Intel's solution for i8xx owners. This other solution was to use kernel mode-setting, but rather than providing any hardware acceleration, just use a shadow frame-buffer with the CPU. All 2D acceleration can now be done in software with the system memory using a shadow buffer rather than touching GEM and potentially hitting the i8xx bugs. Using this path though also makes it not possible to have 3D hardware acceleration, but the maintenance burden is much lower than dealing with renewed UMS code. With still relying upon KMS, however, those operating systems whose kernels lack support for the KMS infrastructure are still out of luck.

Kris Moore of PC-BSD/FreeBSD wrote to the Intel mailing list this morning (here's the message) asking about whether the UMS Intel legacy branch will be maintained. FreeBSD/PC-BSD lacks KMS and GEM support at present, but this UMS driver allows their Intel users to run a newer DDX driver without the said requirements. However, as is the case, this branched legacy driver will not receive anymore work and Intel's OSTC X developers really don't have much interest in non-Linux platforms.

The good news, however, is that the FreeBSD Foundation is willing to finance a developer to work on bringing kernel mode-setting and Graphics Execution Manager support over to the FreeBSD kernel.

Also I'll mention that the FreeBSD foundation is looking to sponsor a developer who would be interested in working on our GEM/KMS support here soon. If anybody who could use some extra $$ and would be interested in working on this, then feel free to let us know.

Intel's Chris Wilson recommended that they get in contact with Owain Ainsworth for possibly doing this job. Owain has been working towards porting this code to OpenBSD. The security-focused OpenBSD project has been interested in utilizing KMS since they then could run the X.Org Server without root privileges. There's also been work towards driving KMS in Solaris, but who knows the state of that outside of Oracle.

Besides providing a virtual terminal experience and the ability to run the X.Org Server as a non-root user, it also presents the possibility of running the Wayland Display Server on non-Linux platforms, better debugging capabilities, the possibility to have a cleaner boot process, and other benefits. Better memory management support can also ultimately result in better performance and being able to take advantage of DRI2 / Gallium3D.

Let's hope that we see KMS and GEM/TTM support come to FreeBSD (and other operating systems) soon, which then would allow these *BSD users to finally take advantage of the open-source Nouveau driver for NVIDIA hardware (as it too now is KMS-only) and inevitably the ATI/AMD Radeon driver will eventually be working in that direction.