On Fri, 2007-12-14 at 05:45 +0000, Dave Airlie wrote: > >From my POV this would make doing a proper GPU scheduler a bit harder as > we wouldn't have all the info in-kernel to schedule operations, we would > be doing a lot of app blocking..
True GPU scheduling would require that we be able to interrupt a batch buffer and restart it. With kernel relocations, you could move buffers, re-evaluate the relocations and restart the batch buffer. That seems like a fairly cool possibility. I can imagine trying to make this work with user-space relocations, but I have to admit it sounds painful and error prone. > the bigger problem as I see it is live-lock, 2 apps hammering would stop > each other from ever going anywhere, which means we would need a lot of > smarts (possibly said scheduler) to decide which app to get set going and > which to block.. I can just imagine races if you block the X server while > moving windows around, as you can't always let the server win otherwise 3D > apps would never draw, but 3D apps would needs to talk to the X server > etc.. it just seems to be a larger problem than just handwaving "a while". Yeah, having an API which was guaranteed to make progress is a nice property. I'll continue to poke at ways to reduce the cost of relocations; there are additional opportunities to reduce the cost of providing relocation data to the kernel. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
