On Sunday 12 May 2002 01:15 pm, Leif Delgass wrote: > this working, I've used buffer aging rather than interrupts. What I > realized with interrupts is that there doesn't appear to be an interrupt > that can poll fast enough to keep up, since a VBLANK is tied to the > vertical refresh -- which is relatively infrequent.
Depends on what you're trying to do with it. If you're polling for completion of a pass for a given caller, it may be problematic. Should we be doing that with this chip, though? I had envisioned a scheme in which the clients didn't drive DMA, they simply submitted things to be rendered out by the chip's DMA and the DRM managed details of keeping track of completion, etc. The first pass of the code I was working towards was going to rely on a lack of free buffers to throttle the clients accordingly. If that didn't work as I had hoped, I was looking to use async notifications to tell clients the request had been processed. In that model, the only things needing to deal with locks are the DRM engine code submitting the DMAable buffers or blits (ran by a seperate group of code...) and any clients/code directly manipulating the chip. All DMA engine clients do is ask for buffers, fill them, and then queue them up for submission to the chip's gui-master engine. The interrupt handler takes care of the rest. In that picture, you're not submitting one group of buffers for one client to the chip, you're submitting as many buffers as you think you can get away with at 60+ Hz (something like 1-2Mb, from prior experience with the Utah-GLX code...) from the queue submitted by all clients. The DRM lock scheme would give enough flexibility to allow the X server to squeeze in against the DRM DMA handler and vice-versa so that screen updates and other stuff could be managed. Unfortunately, my lack of available time precluded me from coding in more than the base framework for that scheme. -- Frank Earl _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
