The Kernel Graphics Interface (KGI) Is Effectively Dead

While the FreeBSD Foundation is now paying for Linux kernel mode-setting and GEM/TTM memory management to be ported to BSD -- and they are making some progress -- this isn't the first attempt at moving major parts of the graphics stack into the kernel. Pre-dating Linux KMS/DRM is the KGI Project, which still is technically around, but it's pretty much dead in terms of new development and any hope of the Kernel Graphics Interface reaching its goals.

I hadn't even thought of KGI (or the connected GGI) in years until late last month when a user asked how DRM differs from KGI. KGI stands for the Kernel Graphics Interface and it's basically an attempt like Linux KMS to move mode-setting into the kernel, and then to also push hardware acceleration into the kernel and other bits. The Kernel Graphics Interface is part of GGI, the General Graphics Interface, and tries to provide an API for high-level graphics clients (KGIDevice), low-level graphics back-ends (KGIDisplay), a graphics driver framework (KGIM), an input system (KII), and a console (KGC).

The introduction from the KGI project site reads:

KGI (Kernel Graphics Interface), is a project that aims for a portable framework providing a means for fully accelerated, secure, stable & portable GPU drivers to be implemented and used across multiple different platforms supporting KGI, with only needing a re-compile at most.

The basic driver functionality (including mode setting) is preformed in kernel space, this allows for a powerful console system.

KGI provides a flexible console system, which allows the user to map any input to any virtual console on any display. Multiple display support has been designed and implemented at the core of the KGI system since its initial design.

Together with GGI (General Graphics Interface) the two projects provide a full featured accelerated system to the console without the need for additional drivers. KGI handles the minimum required for safe acceleration and mode switching, while GGI operates from user space without loosing stability or security.

With the stable system of KGI & GGI users can make use of XGGI for a X11 environment. This setup moves X11 away from kernel space and leaves the hardware management up to KGI

However, if the user chooses so, there is no need for a heavy X11 based environment. Applications can run in a full screen graphics mode directly on the console.

It's an interesting concept in what it provides and at least planned out prior to Linux DRM picking up kernel mode-setting and moving full-steam ahead.

The KGI Framework also sought to be more portable across other operating systems, where as most of the X/Mesa/DRM developers these days don't care about anything but Linux. But the KGI developers never tried to engage with the Linux graphics developers years ago when there was potential for collaboration. With the complexity of modern GPUs, it doesn't make too much sense to now design their own framework and then write their own drivers too, when they could support the necessary Linux components and then port those more feature-rich drivers.

FreeBSD was of greater focus by the KGI developers with the Linux port of the code still being for the Linux 2.4 kernel with the Linux 2.6 kernel (and now Linux 3.0) support being just another item on their TODO list.

Beyond supporting the Linux 2.6 kernel, other work not yet done within KGI but found in the Linux DRM/KMS world is a memory allocation API, multi-head management, monitor hot-plugging, and support for PCI Express.

The KGI developers, however, seem to have pretty much thrown in the towel. The KGI WIP CVS tree hasn't been touched in a while with most of the files not being touched in a number of years (KGI has been around for more than a decade). In the main CVS tree, most files also haven't been touched in years, but there's at least one file that was touched six weeks ago.

Beyond their CVS trees, their project news area has its most recent news item from October of 2009 when they made a patch available so that KGI would work against FreeBSD 8.0-RC1. The KGI development mailing list also hadn't been posted to since 2009.

Of more interest now is how the DRM/KMS porting to BSD is going, which will be saved for another Phoronix news story.