lkml.org 
[lkml]   [1998]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectX & 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

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.041 / U:1.484 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site