On Mon, Dec 07, 2015 at 12:51:49PM +0000, Dave Gordon wrote: > I think I missed i915_gem_phys_pwrite(). > > i915_gem_gtt_pwrite_fast() marks the object dirty for most cases (vit > set_to_gtt_domain(), but isn't called for all cases (or can return before > the set_domain). Then we try i915_gem_shmem_pwrite() for non-phys > objects (no check for stolen!) and that already marks the object dirty > [aside: we might be able to change that to page-by-page?], but > i915_gem_phys_pwrite() doesn't mark the object dirty, so we might lose > updates there? > > Or maybe we should move the marking up into i915_gem_pwrite_ioctl() instead. > The target object is surely going to be dirtied, whatever type it is. phys objects are special, and when binding we create allocate new (contiguous) storage. In put_pages_phys that gets copied back and pages marked as dirty. While a phys object is pinned it's a kernel bug to look at the shmem pages and a userspace bug to touch the cpu mmap (since that data will simply be overwritten whenever the kernel feels like). phys objects are only used for cursors on old crap though, so ok if we don't streamline this fairly quirky old ABI. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
