On Fri, 2004-08-20 at 22:29, Jon Smirl wrote: > The delay is very large because this routine is waiting for the > graphics coprocessor to finish an operation. Some of the operations can > take many ms to complete; for example telling the chip to copy 64MB of > memory somewhere. I would think the question should be, how do we wait > on the GPU without killing both audio and video latency. > > The problem here is that most graphics commands are very short in > duration. Some of these commands can be issued a million of times per > second. A few commands are much longer running. I don't believe there > is an easy way to tell how long the commands will run. > > A better solution might be to loop twenty times to pick up the very > short commands. After 20us switch to a loop that allows the kernel to > schedule. You don't want to immediately schedule since that will kill > graphics performance.
As Ingo comments in another email I don't think that is necessarily the case [but then again I'm not an expert in the schedulling code]. You want to test whether a schedule is needed (a conditional reschedule, if I'm correct). If it is not then nothing happens and the code keeps feeding comands to the graphics processor. If one is needed then I don't see why the graphics code should keep holding the processor. Ok, if there is something else that needs the processor graphics performance could be affected, but that is because there is something else that needs the processor (and will suffer a performance problem if ignored). -- Fernando ------------------------------------------------------- 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
