LPC: The future of Linux graphics

On the final day of the Linux Plumbers Conference, Keith Packard ran a microconference dedicated to future displays. A number of topics were discussed there, but the key session had to do with the near-term future of Linux video drivers. Longtime LWN readers will be more than familiar with the story: Linux has multiple subsystems charged with managing graphics hardware, the user-space driver model adopted by XFree86 leads to all kinds of problems, support for 3D graphics is not what it should be, etc. That whole story was recounted here, but with a notable difference: solutions are in the final stabilization stages, and these problems will soon be history.

There are two major components to the work which is being done: graphics memory management and kernel-based mode setting. A contemporary graphics processor (GPU) is really a CPU in all respects, including the possession of a sophisticated memory management unit. Managing the sharing of memory between user space, the kernel, and the GPU is fundamental to the implementation of correct, high-performance graphics. One year ago, the TTM subsystem looked like the solution to the memory management problem, but TTM grew increasingly unworkable as the understanding of the problem improved. So now the Graphics Execution Manager (GEM) code looks like the way forward; it is currently being prepared for merging into the mainline kernel.

Kernel-based mode setting, instead, is meant to get user-space code out of the business of messing around directly with the hardware. Putting the kernel in charge of the configuration of the video adapter has a long list of advantages. Suspend and resume have a much better chance of working, for example. Once the X server stops accessing hardware directly, it no longer needs to run as root; having that much untrusted code running with full privileges has made people nervous for many years. In the current scheme, the kernel cannot change the graphics mode if it needs to; that means that, for example, if the system panics, a graphical user will never see the message. With kernel-based mode setting, the kernel can switch to a different mode and allow the user to frantically try to read the message before it scrolls off the screen. Kernel-based mode setting will also make fast user switching work much better, without the need to use a separate virtual terminal for each user session.

One of the first topics of discussion was: how does the kernel decide when to switch to the panic screen to show the user an important message? There are quite a few different paths by which the kernel can indicate distress; should a kernel message be presented every time a WARN_ON() condition is encountered? There would appear to be a need to unify the error paths in the kernel to help simplify this kind of decision. Linus Torvalds Jesse Barnes suggested that the kernel could simply switch on every message emitted with printk(), on the theory that such a policy would lead to a rapid and welcome reduction in kernel verbosity.

The real debate in this session, though, had to do with development process. As has been discussed previously on LWN, much of the video driver work is done outside of the mainline kernel tree. We are now seeing a big chunk of that work being prepared for a merge. But the new mode setting interface is a big API change which will require adjustments from user space; a new kernel expecting to handle mode setting may not give the best results when run with an older user space X server. So there will be a big flag day of sorts when everything changes and all of the new code gets run for the first time.

Linus is not pleased with the notion of a video graphics flag day; he made a long appeal for a more incremental approach to fixing the video driver work. In his opinion, the flag day will lead to a whole bunch of untested code being made active all at once; there will certainly be design mistakes which show up, and the whole thing will fail to work properly. At which point another flag day will be required. Linus was not impressed by the claim that Fedora users have selflessly been testing this code for everybody; in his view, the kernel developers are not doing this testing. He sees the whole thing as a recipe for disaster.

The real problem - and the reason for the out-of-tree development - is that all of this work requires the creation of a number of new, complex user-space ABIs. That is true for both mode setting and memory management, and the two cannot be easily separated from each other. Until the combination as a whole is seen to work, the video driver developers simply cannot commit themselves to a stable user-space interface - and that means that their code cannot be merged.

As an example, TTM was cited. Had that code been pushed when it looked like the right solution, there would now be even bigger problems to solve.

In summary, the graphics developers believe that the approach they are taking is as incremental as they can make it. Whether they convinced Linus of that fact is unclear, but he eventually seemed to accept the plan. He did ask for them to push the mode setting code upstream first, but that code cannot work without memory management support. So GEM will go into the mainline ahead of kernel-based mode setting. Once everything is in the kernel, it will be possible to boot a system with either kernel-based or user-space mode setting, so both new and old distributions will be supported. Someday, in the distant future, support for mode setting in user space can be removed. Much sooner than that, though, we should all be running much-improved graphics code and will have long since forgotten how things used to be.

---

(Log in to post comments)