On Mon, 22 Sep 2003, Ian Romanick wrote:
Mark Vojkovich wrote:
Can we export to the drivers some function that yields the CPU?
Currently alot of drivers burn the CPU waiting for fifos, etc...
usleep(0) is not good for this because it's jiffy based and usually
never returns in less than 10 msec which has the effect of making
interactivity worse instead of better. I'm not sure which platforms don't export sched_yield() and which will need alternative implementations.
There was a thread about this on the dri-devel list some months ago. The short answer is DON'T DO IT! :) I don't think that sched_yield will give the desired results in the 2D driver any more than it does in the 3D driver. I *believe* that there is another function for this purpose, but I can't recall what it is called.
http://marc.theaimsgroup.com/?l=dri-devel&m=105425072210516&w=2 http://lwn.net/Articles/31462/
Currently, sched_yield() *does* give the desired result and I have used it with great success in many places, XvMC drivers in particular. Issues with specific implementations of sched_yield() with recent Linux kernels does not change the need to yield. Driver yields will not be random and usleep is unusable because of it's jiffy nature.
I was never challenging the idea that the driver should yield the CPU. On the contrary, I believe that is a good and necessary thing. However, I am a firm believer that on 2.5 (and presumably 2.6 as well) Linux kernels using sched_yield has some very undesirable side-effects.
It sounds like the Linux 2.5 implementation is less desirable than
the Linux 2.4 implementation, however, in lieu of an alternative,
it is still better than burning the entire slice waiting for the
fifo to drain. The ability to yield is essential with DMA based
user-space drivers. These drivers can queue up alot of work and
often have to wait a long time before they can continue.
With pure user-space drivers this is a difficult problem to solve. With user-space drivers with a kernel component the problem is a bit easier. The user-space part can wait on a semaphore of some sort and the kernel part waits on an interrupt. When the kernel receives the interrupt, it kicks the semaphore.
BEFORE THE FLAME WAR BREAKS OUT, I FULLY UNDERSTAND WHY THE DRIVERS ARE IMPLEMENTED THE WAY THAT THEY ARE. THIS IS *NOT*...I repeat...*NOT* A CALL TO START MOVING STUFF INTO THE KERNEL OR ANYTHING LIKE THAT. :)
However, for quite a few of the drivers there already exists a kernel component, either through fbdev or DRI, or both. Some of the drivers, like the Radeon and Rage 128 use this mechanism for DMA in the DDX driver. Perhaps *part* of the sollution is to better leverage that?
The fact that there may be different best implementations with various kernels only further supports that XFree86 should
export a xf86Yield() function which "does the right thing" on
that platform. For Linux <= 2.4 that appears to be sched_yield().
I don't know about the other OSes though, which is why I brought
this up on this list.
Having xf86Yield as a wrapper is a very good idea. We just have to be careful how it's implemented (irony intentional). :)
_______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
