On Thu, Jul 14, 2016 at 10:12:17AM +0200, Daniel Vetter wrote: > On Thu, Jul 14, 2016 at 08:04:19AM +0100, Chris Wilson wrote: > > vGEM buffers are useful for passing data between software clients and > > hardware renders. By allowing the user to create and attach fences to > > the exported vGEM buffers (on the dma-buf), the user can implement a > > deferred renderer and queue hardware operations like flipping and then > > signal the buffer readiness (i.e. this allows the user to schedule > > operations out-of-order, but have them complete in-order). > > > > This also makes it much easier to write tightly controlled testcases for > > dma-buf fencing and signaling between hardware drivers. > > > > v2: Don't pretend the fences exist in an ordered timeline, but allocate > > a separate fence-context for each fence so that the fences are > > unordered. > > v3: Make the debug output more interesting, and so the signaled status. > > > > Testcase: igt/vgem_basic/dmabuf-fence > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Sean Paul <seanpaul@xxxxxxxxxxxx> > > Cc: Zach Reizner <zachr@xxxxxxxxxx> > > Cc: Gustavo Padovan <gustavo.padovan@xxxxxxxxxxxxxxx> > > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx> > > Acked-by: Zach Reizner <zachr@xxxxxxxxxx> > > One thing I completely forgotten: This allows userspace to hang kernel > drivers. i915 (and other gpu drivers) can recover using hangcheck, but > dumber drivers (v4l, if that ever happens) probably never except such a > case. We've had a similar discusion with the userspace fences exposed in > sw_fence, and decided to move all those ioctl into debugfs. I think we > should do the same for this vgem-based debugging of implicit sync. Sorry > for realizing this this late. One of the very tests I make is to ensure that we recover from such a hang. I don't see the difference between this any of the other ways userspace can shoot itself (and others) in the foot. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
