Hi all, This patch-set prevents stalls due to bo reuse in libdrm. After having tried to fix the set_tiling stall both in libdrm and the kernel, I think fixing this in the kernel is the better option: This way gem nicely abstracts away the execution semantics. The only place where the asynchronous nature of the gpu leaks is in the busy ioctl, which userspace should call to check whether a mmap of the bo would stall.
Performance gains are minimal, but strictly positive (neglecting a 1% noise level). cairo perf traces on my i945: old: without-patches new: with-patches Speedups ======== xlib-rgba firefox-planet-gnome-0 62418.67 (64895.61 1.98%) -> 57833.66 (61105.65 2.92%): 1.08x speedup A few traces more have small speedups ranging 1%-5%. I expect this to perform better when all the other tiling related problems are fixed - unfortunately I can't benchmark this because fixing tiling needs portions of my pipelined fencing work (the exact fence lru accounting), which is not (yet) ported to current drm-next. Please review and consider merging for -next. Patches apply to current drm-next. Thanks, Daniel Daniel Vetter (4): drm/i915: don't allow tiling changes on pinned buffers drm/i915: introduce i915_gem_object_adjust_fencing drm/i915: adjust fence register asynchronously on tiling changes drm/i915: report all active objects as busy drivers/gpu/drm/i915/i915_drv.h | 8 +++- drivers/gpu/drm/i915/i915_gem.c | 88 ++++++++++++++++++++++++++------ drivers/gpu/drm/i915/i915_gem_tiling.c | 29 +++------- drivers/gpu/drm/i915/intel_display.c | 16 ++---- 4 files changed, 92 insertions(+), 49 deletions(-) _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
