On Thu, 2008-04-24 at 11:30 +0200, Thomas Hellström wrote: > There is a possibility of a deadlock in the current Intel superioctl path, > which can be illustrated by two contexts rendering simultaneously from > the same textures, > One context using fallback rendering, the other using the GPU. > > Context 1 will start mapping the texture buffers, Context 2 will take > the cmdbuf mutex and start validating the same texture buffers. > Now if they end up having the buffer lists reversed, context 1 might end > up waiting to map a buffer that context2 has validated for the GPU, > while context2 will wait for a buffer that context1 has mapped => deadlock. > > One way around this is to use the hardware lock around all buffer > mapping (including client buffer object mapping) and command submission, > I believe the old i915tex driver did this to a large extent. I'm not > sure what the current i915 driver does. Anyway, we need a more > fine-grained approach.
In master we hold the lock around execbuffer. Is getting multiple cpus in the validate path a bottleneck, really, where a finer-grained approach is needed? -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
