On Thursday 17 March 2005 16:17, Attila Kinali wrote: > On Tue, 15 Mar 2005 23:28:59 -0500 > > Daniel Phillips <[EMAIL PROTECTED]> wrote: > > Hmm, and force the command ringbuffer to be physically contiguous? > > In that case, I'd say don't bother with the 8 entry lists, just let > > the ringbuffer be a huge thing that can only initialize at boot. > > Because after a Linux kernel has been running for a while, you > > can't be sure of successfully getting even 2 physically contiguous > > pages, let alone a whole bunch. Reducing the problem by a factor > > of 8 doesn't make it go away. > > Not true. Even after some time, you'll be able to do order-1 > allocations (at least on linux, don't know about other > OS, but i guess every OS with a somewhat intelligent VM will > be similar).
I assure you, order 1 allocations sometimes fail. So what do you do then, put your allocator in a loop and hope the kernel sorts it out after a potentially unbounded amount of time? > It's even possible to do order-2 or order-4 allocs. > But the possibility of a failure increases. > On linux you can check the amount of availble pages ordered > by their oder in /proc/buddyinfo It is far better to make a problem go away completely than to just reduce the probability. > > In my opinion, we only have to solve this problem on paper - we > > have to show how the card won't always be a contiguous memory pig. > > But there is no practical need to implement the solution in the > > initial release. > > Yes, definitly. Best in a way where it is possible to do direct > DMA (ie w/o a second stage) for the simple cases and > s/g or 2-stage DMA for all those who need to transfere a lot of > pages. My proposal at this point is to _always_ do two stage DMA so that drawing commands are only ever submitted via indirect DMA. I did see Timothy's PIO idea for indirect DMA setup, which needs to be looked at. As a kneejerk reaction, I would think that setting up each command/texture DMA fragment with PIO would lose a lot of goodness that the ringbuffer scheme has, for no obvious benefit. Regards, Daniel _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
