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.
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.
Latest Linux Hardware Reviews
Latest Linux Articles
Latest Linux News
Latest Forum Discussions