Re: Intel TTM superioctl / execbuf deadlock.

[Eric A. <er...@an...>]

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                             anholt@FreeBSD.org
er...@an...                         eri...@in...