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

Daniel Vetter daniel at ffwll.ch
Thu Dec 10 00:58:22 PST 2015

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 Vetter
Software Engineer, Intel Corporation

More information about the Intel-gfx mailing list