--- Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Jon Smirl <[EMAIL PROTECTED]> wrote: > > > --- Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > the cleanest and highest performing solution would be to have an > > > interrupt source for 3D completion - do you have such an interrupt > > > handler handy? If yes then you can sleep precisely up to completion: > > > > Interrupts are not a good solution. The hardware would generate > > millions of them per second. This is the same problem network cards > > have, you can interrupt the machine to death. > > you'd only have to enable interrupt generation when you are not > busy-polling. In 99.9% of the cases (when !need_resched()) you could > busy poll as much as you want, and keep IRQ generation off. Very likely > IRQ generation can be turned on/off via a single PCI write on most 3D > hardware. Anyway, IRQ generation would just be a 'nice' thing. But the > following property is a must: > This lookes like a great idea. We turn on interrupt generation just after we drop our spinlock(in the if need_resched() block). This would greatly improve system proformance as IRQs would only be used when we wait for long periods.
> > I would expect the best solution is to make a few passes through the > > loop delaying a couple usec to catch the common case of quick > > completion. Then switch to doing need_resched(). > > no. If need_resched() is set then the code *must* try to schedule ASAP. > There is no excuse for not doing so - 'performance will suffer' is not a > correct argument becase _if_ need_resched() is true then the system (and > the user) doesnt want the 3D app to run right now. There will be no > performance difference to the 3D app, since by having high latencies the > DRI code does not give any extra performance to 3D apps, it only > increases the scheduling latency! The timeslices of the 3D app are used > up depending on how long the 3D app runs - so if it burns cycles > busy-polling it will in fact get less CPU time on average. (if the CPU > is contended.) > I see jerky ness alot with Q3, where frame rate spikes for one frame. This lookes like a good explination, as the frame b4 and after would have many of the same GL calls. End Of Line. > Anyway, need_resched() set is not a common condition, and if it happens > then kernel code _must_ react. (In fact most kernel code will be > preempted right away - but the DRI code runs under spinlocks.) > > So the correct solution is to add something like this to _at least_ the > busy-polling code: > > if (need_resched()) { > ... drop locks ... > cond_resched(); > ... reacquire locks ... > } > > or, if there's a single spinlock held (the BKL doesnt count) then: > > cond_resched_lock(&driver->lock); > > (but the locking obviously has to be correct and safe.) > > ok? > > Ingo > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > -- > _______________________________________________ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel