Re: Graphics performance under linux

[Paul Gearon <pag@PISoftware.com>]

On Mon, 14 May 2001, Timur Tabi wrote:

> ** Reply to message from Erik Mouw <J.A.K.Mouw@ITS.TUDelft.NL> on Sun, 13 May
> 2001 23:20:45 +0200
> > And if we're speaking about Unix systems in general: no PC video system
> > comes even *close* to the performance of an sgi Infinite Reality 3. And
> > yes, it runs X windows (with OpenGL extensions)
>
> I don't think that's addressing his issue.  Yes, different cards can have
> vastly different performance, but that's true under any operating system.  I
> think his point was that given the same hardware and the same quality drivers
> (i.e. drivers fully optimized to the OS and the hardware), X runs slower than
> other PC operating systems (like OS/2 and Windows) because of the client/server
> nature of X.  I don't know if that's true or not, but it does make sense to me.

IMHO it's not the client/server nature of X at all, but rather the
communications mechanism.

I'll just consider graphics running on a local system for the moment.  In
a sense all windowing systems are client/server in that a program (the
client) makes a request to the windowing environment (the server) to draw
some stuff for it.  In the bad old days of DOS then each program did its
own rendering to the screen.  While this is fast, it has a list of
problems so long that I'm not going into it here, and I'm sure everyone
here already knows about it anyway.  The real difference between windowing
systems is in how the client/server requests get made.

In Windows (and I'm assuming OS/2) these requests are made via function
calls to an API, which in turn directly calls functions on the graphics
driver.  This mechanism is obviously pretty quick.

In X the requests are made via communication on a socket.  At the other
end of the socket the graphics server calls functions on the graphics
driver (at which point it's similar to MSWindows).

The problem is the communication via sockets.  Even when connecting to
localhost the mechanism is not as efficient as a direct API call.  This is
partly due to the parsing of the datastream, but mostly due to the fact
that even a simple message requires a write() system call, copying of data
(maybe zerocopy extensions would help here), waiting for the scheduler to
schedule the recipient, a copy during the recipient's read() system call
and then return from this read() before the recipient can do anything with
the data.  (This assumes that the recipient was blocked on a read() and
not doing asynchronous io, which I suspect that an Xserver does.  That
would result in a little overhead).

This is obviously going to be a little slower than calling functions in
GDI.DLL which in turn calls functions in a graphics driver.  However, it
is also more reliable (since the process context of the Xserver is
seperate to that of the client program) and has the major advantage of
being transparent over a network.  I'd rather not see this system
abandoned, but maybe sockets to localhost could be sped up in some way.

Alternatively, a CORBA like approach which detects connections to
localhost and uses direct function calls instead may make things quicker.
Unfortunately, this would interfere with the independence of the XServer
from the clients, though there's probably a way around it.

Regards,
Paul Gearon

Software Engineer                Telephone:   +61 7 2876 2188
Plugged In Software              Fax:         +61 7 3876 4899
http://www.PIsoftware.com        PGP Key available via finger

Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum
immane mittam.
(Translation from latin: "I have a catapult. Give me all the money,
or I will fling an enormous rock at your head.")


-
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/
IRC Channel:   irc.openprojects.net / #kernelnewbies
Web Page:      http://www.kernelnewbies.org/