--- 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
