On Tuesday 31 January 2012, Alan Swanson <swan...@ukfsn.org> wrote: > As discussed back in 2003, sched_yield() on Linux is no longer > equivalent to other POSIX variations. From a LWN article; "This call > used to simply move the process to the end of the run queue; now it > moves the process to the "expired" queue, effectively cancelling the > rest of the process's time slice. So a process calling sched_yield() now > must wait until all other runnable processes in the system have used up > their time slices before it will get the processor again." > > However its use on Linux has sneaked back in causing suboptimal > performance such as reported by Simon Farnsworth on r600g. Use sleep on > Linux instead. > > Signed-off-by: Alan Swanson <swan...@ukfsn.org> > I should note that I'm running my 3D app real-time (SCHED_RR) - the performance pain I was facing is that I got to hog one CPU core waiting for the GPU, while having several (three or four, typically) other processes (SCHED_OTHER priority) waiting for free CPU time. As the E-350 is not overblessed with CPU time in the first place, this hurt.
I've fixed my problem by a different route (in other patches sent to the list); I no longer spin at all when waiting for fences to complete, instead waiting for an interrupt from the GPU. Having said that, I'll rebase your patch on top of my changes, and confirm that it doesn't break things for me. -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
