lkml.org 
[lkml]   [1999]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Thread-private mappings and graphics (was Re: Per-Processor DataPage)
Chris Meadors wrote:
> James Simmons wrote:
> > Thanks for the suggestion on the userland chossing when to flush commands
> > to the accel engine.
>
> Two other things to think about:
>
> What happens when the userland program waits too long before flushing?
> It just keeps writing command after command.

Userland writes to a memory buffer, not to the hardware. Eventually the
program asks the kernel to flush the buffer, and the kernel complies by
verifying and translating the buffer contents (e.g. DMA addresses) and
passing instructions to the hardware however it deems best (e.g.
splitting large buffers to give other tasks a go). The kernel portion
cal run in parallel with further execution of userland -- on a good card
it might be done entirely with card DMA.

If the userland program waits for a long time, the hardware isn't locked
so there is no problem.

> Since one of the goals of this conversation was to figure out how to get
> away from requiring X for display. I assume you are leaning towards
> frame buffer consoles. What happens when there is a virtual console
> switch before the program flushes its buffer?

See above; no problem. The VC switch may have to wait for currently
executing commands or DMA to complete (unless the hardware allows this
to be interrupted), but it doesn't have to wait for userland.

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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