Messages in this thread | | | Date | Thu, 26 Mar 1998 19:18:01 +0100 | From | Andrej Presern <> | Subject | X & GGI [long] |
| |
Hello,
I'd just like to state a few opinions of mine regarding the current state and the future of the graphics subsystem. There are a number of alternatives that address the graphics subsystem issue. The X-Windows servers and SVGAlib being the two most widely used today, I will focus on these two with respect to the new GGI.
The features that I believe most people would like to see in their graphics subsystem are (in no particular order): 1. High performance 2. Flexibility 3. Stability
It is common knowledge that the highest performance can only be achieved by directly interfacing with the hardware. The lower you go, the higher speed you can achieve. As there is an always increasing number of applications that require high speed graphics (I prefer to think of 3D modelling and rendering tools, image manipulation programs, video production and post production software and multimedia presentation software, even though games may seem as the most appealing and obvious), a low level graphics interface that will perform sufficiently well and thus at least allow those applications to be built is a must.
Because not all of these applications will want to do everything on the lowest possible level, a higher level user interface will have to be provided as well. Currently, the application designer must chose between the two most common alternatives - the lower level SVGAlib one, which allows for better performance but lacks support for even remotely modern graphics hardware; or the X-Windows one, which has the support, but lacks the performance and demands quite a bit of resources. Neither one is a 'better' solution. It would be extremely appreciated if the programmer could choose the high performance of the low-level SVGAlib and the support of the variety of graphics adapters of the X-Windows implementations.
Currently, though, this is not possible, because the two efforts are indeed two separate ones, so the code and the work are essentially duplicated. By having a one low level interface, both sides would benefit: 1. Less time and work would be spent on the developement of graphics drivers for new hardware, which would lead to 2. More time could be dedicated to improving the performance and stability of the existing graphics drivers 3. X-Windows server developers could focus on developing a ONE single stable high performance X server (instead of n) based on the accepted low level interface [4. Windowing systems other than X-Windows could be built with instant support for a large number of graphics adapters]
Besides the developers, the users would benefit also: 1. They can choose, which user interface suits their needs better (the extremely flexible X, the high performance SVGAlib, the not so flexible but faster than X but not so high performance but more flexible than SVGAlib not-yet-developed-windowing-interface) 2. More and faster support for new graphics devices 3. Better performance of the graphics devices 4. A wider variety of graphics applications
Since a graphics adapter is just another hardware device (the same as a sound device, a network device, a disk device, ...), the kernel MUST know about it and should provide at least the most basic resource management, such as that of the memory subsystem - to at least provide boundaries between processes so that unrelated processes cannot uncontrolably interfere with each other, and to provide basic resource locking and control access mechanisms, including regaining the control of the resource by resetting the device to a known state. Currently, though, the graphics hardware is an exception to this rule. I have yet to see any good arguments, why the kernel should not provide any support for network adapters, which are also a hardware device that must be shared among a number of processes in a pretty much the same fashion as a graphics adapter.
By implementing the support in the kernel, the users and the developers would thus also benefit in: 1. Improved security, and 2. Improved stability
I am NOT saying that the GGI in its current state is the ideal model for a low level graphics subsystem. What I AM saying is that such a subsystem IS needed, and if the GGI project has already begun work in this direction and is widely supported by a number of platforms, GGI SHOULD be given support. Subsystems HAVE changed in the history of Linux. They may not be exactly what their authors first imagined them to be when finished but are actually BETTER, because a large developer audience has provided constructive input so that these subsystems could be improved. The GGI project should not be considered AS IS, but as a project that will incorporate new concepts and code should they prove to be superior to what is currently believed to be the best, in the same fashion that, for example, dentries have found their place in the kernel.
The question is therefore not "Do we like GGI as it is now?" because GGI can be changed, but rather "Do (and if we do, why) we need a graphics adapter support in the kernel?". I believe I at least partly answered the last question: performance, flexibility and stability (again, in no particular order). Most of the stuff that the Linux kernel performs can be done in user space. The answer why they are NOT implemented in user space can in most cases be found in (at least one of, usually more) the above three words.
Andrej
PS: The X people are aware of the performance problem of the X-Window system and are trying to address it with XAA. I think though that what XAA will provide would be provided by GGI as a side product.
-- Andrej Presern, andrejp@luz.fe.uni-lj.si
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |