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.
So the idea will be for the execbuf ioctl to back off if it encounters a
mapped buffer, something like the following "pre-validate" functionality
to make sure all buffers are unmapped before we run the full validation
cycle.
block_other_validators();
while (1) {
for (i=0; i<num_buffers; ++i) {
if (buffer[i]->mapped)
goto backoff;
buffer[i]->validated = 1;
}
break;
backoff:
for (j=0; j<i; ++j) {
buffer[j]->validated = 0;
}
unblock_other_validators();
err = wait_for_unmapped(buffer[i]);
if (err)
return err;
block_other_validators();
/*
* Restart from the beginning.
*/
}
Unfortunately, pre-validation won't work unless post-relocs are used,
which means the full validation cycle needs to be aborted and rerun if
we encounter a mapped buffer; Typically if a DRI client needs to wait
for the X server to unmap the front buffer after a software fallback.
I'll at least try to fix this up in the post-reloc case.
/Thomas
-------------------------------------------------------------------------
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
