On Wednesday 24 April 2002 11:32 am, you wrote: > Regardless of security concerns, the idea was to use this primary buffer > for storing the state update emitted from the DRM. The first entry of > the descriptor table would point to this primary buffer, and the > followings to the client submitted buffer. Anyway, I agree that for the > time being this can stay as MMIO.
Yep. > Initially I thought of this too, but since the amount of changes would > be almost the same I preferred to investigate a little further how to do > it definitively. You're wasting memory with that one- all you need is a 16k aligned block for the descriptor table for spaces as large as 2Mb per submission. > Do you think that the interrupt is necessary? Wouldn't it be possible to > use a scratch register for doing buffer aging as it's done in the other > cards? To do things the way I've envisioned them, yes. To do basic DMA with what it sounds like you've got going, no. You'd kind-of need it for detecting the completion of the blit operations and it's nice for periodically checking for a failure in FIFO discipline or a lockup and doing a reset. As for buffer aging, yes, you can do it with a scratch register, but it'll perform MUCH better with doing it with interrupts keeping track of completion. > Could you share with us what you had in mind before? Now that Leif and I > have been studying a little this subject I think we are able to follow > and discuss your ideas. Picture a function that is intended to handle dispatch of DMA-able buffers. It's woke up by a periodic call via interrupt or timer. In this case it's by the VBLANK interrupt. It monitors the current state of affairs (DMA submitted- busy with the same, DMA submitted- completed, etc.) and acts accordingly to handle blocks up to a given size, perform resets of the engine, etc. You have a DMA queue that handles all gui-master operations (Blits are a different story, while I'd love to manage a scheme to queue them up, etc. that works nicely with the gui-mastering operation, writing it up is a lot more complex and may/may not buy us much) as requestors place their requests, they submit a block of operations they wish to do (state info, blank/swap, vertexes to be drawn, etc.) and go on about their way- they really don't need the lock for this since the caller isn't the one managing the DMA pass. When the interrupt wakes up the function, it checks to see if it's supposedly in the middle of a DMA pass or not. If not, it checks the queue and submits up to 1 or 2 Mb of buffers to the DMA. If so, it checks for completion. If the DMA is completed, the function then pushes the used buffers back into the freelist (No keeping track of aging...). If not completed, it increments a timeout counter. If the timeout is reached, it resets the engine and pushes the failed buffers to the freelist. In the design I have in mind, you can have as many requestors submitting DMA requests simultaneously as you want up to the 1-2Mb size range that is realistic for this chip. With it, you know implicitly when something is aged out and could concievably handle throttling of the client easier. The only real sticking point is handling the lock from the DMA function instead of the callers. I was going to hold off on that because it's not obvious how to do it and the code would be needing to wait until the engine was idle anyhow. Right now, I've had another bit of fun keeping me from finishing it earlier this week, but unless more fun comes my way I am still anticpating having something in place that can be looked at if not used by the end of the week. -- Frank Earl _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
