Maarten Maathuis
2009-Aug-22 23:21 UTC
[Nouveau] concern about bo "pinned'ness" after gem pushbuf is done
As far as i see, we reserve the bo in the gem pushbuf ioctl, and unreserve after the pushbuf and the fence have been emitted. This assumption holds if bo moves happen on the same channel or if a cpu copy happens and we're waiting on fences. But for nv50 it is very common for the bo move to happen on the kernel fifo, which does not guarantee anything. Is there any safety i missed? Maarten.
Ben Skeggs
2009-Aug-23 23:00 UTC
[Nouveau] concern about bo "pinned'ness" after gem pushbuf is done
On Sun, 2009-08-23 at 01:21 +0200, Maarten Maathuis wrote:> As far as i see, we reserve the bo in the gem pushbuf ioctl, and > unreserve after the pushbuf and the fence have been emitted. This > assumption holds if bo moves happen on the same channel or if a cpu > copy happens and we're waiting on fences. But for nv50 it is very > common for the bo move to happen on the kernel fifo, which does not > guarantee anything. Is there any safety i missed?Hm, access by another channel after the move will definitely be protected as we emit a fence for the move operation. However, I think we may need to wait ourselves if the buffer move is going to happen on a channel other than whatever used it last. TTM doesn't do this anymore I believe (the old ttm used to). Ben.> > Maarten. > _______________________________________________ > Nouveau mailing list > Nouveau at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau
Possibly Parallel Threads
- [PATCH] nouveau: don't emit reloc markers for bo's that are mapped
- [Mesa-dev] [PATCH try 2 2/2] gallium/nouveau: move pushbuf and fences to context
- [PATCH] nouveau: avoid running out of relocs (attempt 5)
- [PATCH] drm/nouveau: don't hold spin lock while calling kzalloc with GFP_KERNEL
- [Mesa-dev] [PATCH try 2 2/2] gallium/nouveau: move pushbuf and fences to context