> > 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
'sorry'.
> 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 majordomo@vger.rutgers.edu