• Dave Gordon's avatar
    drm/i915: mark GEM object pages dirty when mapped & written by the CPU · 033908ae
    Dave Gordon authored
    In various places, a single page of a (regular) GEM object is mapped into
    CPU address space and updated. In each such case, either the page or the
    the object should be marked dirty, to ensure that the modifications are
    not discarded if the object is evicted under memory pressure.
    
    The typical sequence is:
    	va = kmap_atomic(i915_gem_object_get_page(obj, pageno));
    	*(va+offset) = ...
    	kunmap_atomic(va);
    
    Here we introduce i915_gem_object_get_dirty_page(), which performs the
    same operation as i915_gem_object_get_page() but with the side-effect
    of marking the returned page dirty in the pagecache.  This will ensure
    that if the object is subsequently evicted (due to memory pressure),
    the changes are written to backing store rather than discarded.
    
    Note that it works only for regular (shmfs-backed) GEM objects, but (at
    least for now) those are the only ones that are updated in this way --
    the objects in question are contexts and batchbuffers, which are always
    shmfs-backed.
    
    Separate patches deal with the cases where whole objects are (or may
    be) dirtied.
    
    v3: Mark two more pages dirty in the page-boundary-crossing
        cases of the execbuffer relocation code [Chris Wilson]
    Signed-off-by: default avatarDave Gordon <david.s.gordon@intel.com>
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Link: http://patchwork.freedesktop.org/patch/msgid/1449773486-30822-2-git-send-email-david.s.gordon@intel.comReviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    033908ae
i915_gem_render_state.c 5.35 KB