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

Well I'd assume thats how we'd handle it - I queue 50 operations, thats
what 5000 clocks. Its not worth rescheduling for that.

> 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'.

Firstly if its short operations then I'll have finished the ops before
I get back. Secondly if its not I can flip the mmu state of those pages
and block on fault the task.

Alan


-
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.951 / U:0.784 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site