Getting xserver patches reviewed

[Keith Packard]

On Sun, 2007-11-25 at 02:37 -0200, pcpa at mandriva.com.br wrote:

>   It's biggest problem is that any failure will usually
> only allow remote access to the computer. And there isn't
> any way to enter some kind of fallback/failsafe mode
> without at least a server restart (this may be a cool
> project to work on).

Kernel mode setting will help a lot here -- the ability to switch away
from graphics mode without needing the overt cooperation of the X server
should make this kind of DoS less possible.

>   A multi threaded X Server isn't mandatory, but for modern
> cpus, the extra cpu time cost isn't a problem, and frequently
> negligible, and allowing code to manage/wait the hardware
> while the server is processing events or whatever would be a
> "good thing" (other cool project).

We already have asymmetrical multi-processing -- the CPU queues requests
to the graphics hardware which executes it asynchronously. Most of the
time, you should see your system simply waiting for the graphics
hardware to execute requests. From what I know, graphics hardware today
is single threaded. So, there's not a huge benefit in multi-threading
the X server so that many threads can all sit waiting for the single
threaded hardware.

>   Nowadays there are fewer needs for something like this, but
> there should be a way to cancel X requests, but multi threading
> is an alternate solution. I remember one of my first experiences
> with XFree86 and doing a wrong call to fill a rectangle of size
> 65535x65535, software rendering on a 386 with 8M ram...

You'll still get stuck today, at least on Intel hardware where you
cannot interrupt the graphics hardware while it operates on a single
primitives.

>   I find the hardest code to work on is hardware support,
> because usually documentation isn't easily accessible.

I'm working on this for Intel hardware (and have managed to release some
internal hardware specs under NDA to a few people), and I know people at
AMD who are working on this for their hardware. With luck, at least
these two platforms will see documentation finally available. Given the
complexity of graphics hardware, and the speed of mutation, attempting
to program these systems without documentation is close to impossible.
This seems to me the single most important issue limiting community
involvement in the lowest levels of the X environment.

>  One
> interesting project could be software emulation of video
> chips, to allow easier development and debugging of drivers
> (not a cool project, hardware vendors would love to
> know you are reverse enginering theirs products...)

Having a stable hardware-based environment is really a lot better;
faster, and it reproduces hardware dependent issues more accurately.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20071124/03d341ee/attachment.pgp>