Getting xserver patches reviewed

[pcpa at mandriva.com.br]

Quoting Keith Packard <keithp at keithp.com>:

> 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.

  While I don't like much the idea of moving certain things to the
kernel, maybe this is the natural movement, and there are things
that can only be done in kernel mode. But there is hardware, well, at
least my ATI 9250, that may lock and only work again after a hard reset,
as it will lock the computer shortly if I patch the "locking" busy loop
to stop after a small counter. Maybe it is just the driver that cannot
"fully" reset the card.

>>   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.

  I agree it isn't something that important. Events are already asych
by default with the X library. And threads would somehow let the kernel
scheduler distribute cpu time among processing descriptors and hardware
access.

>>   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.

  The example is an extreme case (but not hard to achieve if you
let -1 be cast to unsigned :-) and on software rendering, that is
interruptible. An ancient hardware it could take several minutes
to finish.

>>   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 problem is that there ins't demand for documentation. If it were
like processors, some decades ago, where people could pretty much only
write assembler programs, things would be different. Maybe the reason
is to allow more freedom on "completely changing things on a new
review", or it is to avoid someone cloning the card, or maybe just so
that competition cannot have easy access to it. Hopefuly this will
change in a not distant future, and "advanced" video chips could be
widely used in a "standard way" for more than gaming, i.e. scientific
applications that needs massive computations, etc; well, visualization
of real time simulations is a reality, for some specific hardware
combinations, but overall still very unstable on open source software.

>>  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.

  Agreed. The usefullness would not be worth the huge amount of work,
and would be unlikely to fully emulate. But could be interesting for
ancient hardware that a developer doesn't have access, to make sure
a driver still works.

> --
> keith.packard at intel.com
>

Paulo