Messages in this thread | | | Date | Mon, 20 Dec 1999 22:50:12 -0500 (EST) | From | James Simmons <> | Subject | Re: Thread-private mappings and graphics (was Re: Per-Processor DataPage) |
| |
On Mon, 20 Dec 1999, Jamie Lokier wrote:
> 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/
| |