Keith Packard wrote:

>On Wed, 2007-12-05 at 18:24 +0100, Thomas Hellström wrote:
>
>  
>
>>I have nothing against wrapping the drm_bo_kmap() function with a
>>wait 
>>for fence and another function name, but the current version is just a 
>>convenience function to find the right pages to map and map them in the 
>>right way, instead of using ioremap etc. directly. It relies on the 
>>driver writer knowing what to do and doing it.
>>    
>>
>
>Yes, of course -- new semantics would use a different function; each
>time a buffer is used, the proper invariants would need to be verified
>by using the right function. One invariant that seems relevant in most
>drivers is that any object dispatched to the hardware (i.e. referenced
>by the command queue, directly or indirectly) should not be modified by
>the CPU until the hardware has finished using it. 
>  
>
Agreed.

>  
>
>>There are cases for example in the poulsbo driver where one needs to 
>>access a buffer in the middle of command processing while it's fenced 
>>and obviously waiting for the fence to expire here would cause a 
>>deadlock.
>>    
>>
>
>Are you writing to the object in the middle of command processing? Or
>just reading? Seems like writing to it without some kind of locking will
>cause unpredictable behaviour, but reading should work fine, especially
>if the GPU is not writing to it either.
>
>  
>
It depends on the definition of "command processing" and what the fence 
is protecting. User space sees it all as a single operation that is 
terminated when the fence signals. Kernel space sees it as a sequence of 
operations in between which it has to shuffle tasks and perhaps patch 
buffers, and after the last operation it signals the fence.

So basically the Poulsbo kernel task scheduler does part of what's 
traditionally done by the GPU, and fences really only have a meaning 
outside the task scheduler itself.

I don't expect this to be a typical usage pattern, however.

/Thomas






-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to