[Intel-gfx] [PATCH] Always mark GEM objects as dirty when written by the CPU

[Chris Wilson]

On Fri, Dec 11, 2015 at 12:19:09PM +0000, Dave Gordon wrote:
> On 10/12/15 08:58, Daniel Vetter wrote:
> >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
> 
> So is pread broken already for 'phys' ?

Yes. A completely unused corner of the API.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre