lkml.org 
[lkml]   [1998]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.046 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site