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. > 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. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- 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
