Messages in this thread | | | Date | Wed, 25 Feb 1998 20:26:23 +0100 (CET) | From | MOLNAR Ingo <> | Subject | Re: GGI, EGCS/PGCC, Kernel source |
| |
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 majordomo@vger.rutgers.edu
| |