> 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.
It is better to allow that _as an option_. Of course you have to
allow explicit flushes. But you also need to have implicit flushing for
the sake of performance. The nice thing about the page fault method is
that it allows you to tune the size and faulting behavior of the ping and
pong buffers on the fly as needed. This is a wonderful way to get the
most out of those fifo watermark interrupts I mentioned before. If the
high watermark IRQ fires, your driver code is pushing the hardware fifo
too hard. Usually that means that userspace code is pushing the driver
too hard, so you can throttle back the userspace command buffer filling
code by faulting more often and then raise the ping/pong buffer size so
faults occur less often. If the low watermark IRQ fires, you are starving
the hardware and should fault more often unless scheduling priorities
prevent this or your buffer size == PAGE_SIZE.
> > 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.
Correct.
James Simmons (o_
fbdev/gfx developer (o_ (o_ //\
http://www.linux-fbdev.org (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net
-
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/