Re: GGI, EGCS/PGCC, Kernel source

Wed, 25 Feb 1998 20:26:23 +0100 (CET)

On Wed, 25 Feb 1998, Alan Cox wrote:

> > protocol, it gets thousands of calls per second. The accelerator of most
> > cards is a different beast though. It usually has a limited queue depth
> > (8, 16, 32), where a command can take up 1-5 queue entries. So certain
> Yes but you dont have to go back to user space each time you fill the hardware
> queue.

so what will do in the kernel? eat cpu cycles while polling? schedule to
other processes (much too heavyweight)? XFree86 does not wait after
queuing a command, it continues and prepares parameters for the next one,
and waits only if the queue is full.

> > possibly millions of accelerated operations per second. Smallish
> > accelerated operations finish within 10-100 cycles, this is why almost no
> > GX card has IRQ-driven acceleration, they have an engine status/depth
> > register that can be polled. If you let users access the framebuffer as
> > well then 'delayed syncing' (a technique in XFree86 XAA that has almost
> > doubled acceleration performance ...) can not be done safely.
> Now that depends on two things
> 1. If you only allow one user to have the frame buffer a time and keep
> context on switches.
> 2. If you dont pull MMU stunts to fault/block other tasks touching
> the memory during such events. Also note most operations take so
> few cycles a non scheduling spin is no big deal (SMP needs the mmu
> stunt always alas).

you can not pull such MMU stunts for the _same_ process. The problem is
framebuffer access from the _same_ process. You can not touch _any_ of the
framebuffer when an accelerated command is running (on most cards). You
can touch it shortly after it's finished. XFree86 + XAA has no such
problems, as all of X's code is behaving 'nicely'.

look at how Win95 and NT has solved this problem: Win95 allows hardware
access in user-space, NT has basically put X into it's kernel (well, not
really X, but much more than GGI ever has planned to put into the kernel).

-- mingo

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