summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/nouveau/nv84_fence.c
diff options
context:
space:
mode:
authorDave Gordon <david.s.gordon@intel.com>2015-12-10 18:51:23 +0000
committerDaniel Vetter <daniel.vetter@ffwll.ch>2015-12-11 18:11:53 +0100
commit033908aed5a596f6202c848c6bbc8a40fb1a8490 (patch)
treedc5a1bcdb3e9a00329791c51a64933e65b51d1cf /drivers/gpu/drm/nouveau/nv84_fence.c
parentc5baa566db793cbd931f64d265cdc7d744c6169a (diff)
drm/i915: mark GEM object pages dirty when mapped & written by the CPU
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: Dave 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.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Diffstat (limited to 'drivers/gpu/drm/nouveau/nv84_fence.c')
0 files changed, 0 insertions, 0 deletions