Re: Fwd: Re: GGI, EGCS/PGCC, Kernel source (fwd)

Thu, 26 Feb 1998 11:13:00 +0100 (CET)

On Thu, 26 Feb 1998 wrote:

> > not something like this:
> >
> > - ioctl() [... sloooow]
> > - page fault [... sloooow]
> > - soft-queueing of GX commands [... latency problem]

> If you want non-root-graphics on badly designed PC hardware which doesn't
> have a "safe" register set that can be exported directly to userspace

IMO thats not an excuse. 90% of the (non-video) hardware in most PC boxes
is actually 'badly designed' in one or another way. We cant just say

> Surely performance could be improved by directly banging on the hardware,
> but this would OTOH allow me to hang the system, too.

could you give us a measure, what percentage of currently used Linux boxes
is considered to have 'non-broken' video hardware?

> We could enhance performance a slight bit, by using something more direct
> than an ioctl, yes, but that wouldn't cut it. [...]

the real problem is not the ioctl(). The problem is that we cant use
neat features like retry-PCI or delayed sync. Again, these two features
alone have _doubled_ X's performance on my box.

> Yes. Drivers for these cards either :
> - enforce blocking mode acceleration, i.e. accel calls only return when
> they have done their job (in the cases where double-sided-access
> hangs the card) or
> - synchronize mmaped buffer and running accelerator using the ggiFlush()
> call (when nothing really bad happens, if some jerk doesn't do it
> right).

some cards (Cirrus?) are known to hang if 'some jerk' accidentally mixes
framebuffer access and accelerator usage. S3 Virge cards AFAIR corrupt the
whole framebuffer.

> And it is the hardware that is actually braindead/broken. KGI handles it
> just right - it prevents that these misdesigns cause system instability.

are you aware of the fact that these 'misdesigns' are actually running on
the majority of today's desktops?

> I have _measured_ XGGI performance. It is exactly up to XFree86 except for
> the accelerated parts, that are not implemented in XGGI.

'except'?? You are running an S3 card. 90% of the pixels moved in XFree86
3.3 are done by the accelerator. And the framebuffer access part, well,
exactly the same thing happens in both cases (the linear framebuffer is
mmap()-ed into user-space), so i cant see how it could be any different
from 'exactly up to XFree86'.

> The reason why acceleration in XGGI (only in the server, the drivers _are_
> accelerated) is not implemented is simple :
> The guy maintaining XGGI is - as he himself says - pretty clueless about X
> and X servers. Noone that really knows X servers has yet bothered to help
> us putting the accelerated commands of LibGGI in the right places.

oh well.

-- mingo

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to