[Intel-gfx] [PATCH 2/3] drm/i915: mark GEM objects as dirty when updated by the CPU
david.s.gordon at intel.com
Tue Dec 8 10:43:33 PST 2015
On 08/12/15 17:00, Chris Wilson wrote:
> On Tue, Dec 08, 2015 at 04:51:17PM +0000, Dave Gordon wrote:
>> In various places, one or more pages of a GEM object are 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.
>> Ideally, we would like to mark only the updated pages dirty; but it
>> isn't clear at this point whether this will work for all types of GEM
>> objects (regular/gtt, phys, stolen, userptr, dmabuf, ...). So for now,
>> let's ensure correctness by marking the whole object dirty.
>> Signed-off-by: Dave Gordon <david.s.gordon at intel.com>
>> Cc: Chris Wilson <chris at chris-wilson.co.uk>
>> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 ++
>> drivers/gpu/drm/i915/i915_gem_render_state.c | 1 +
>> drivers/gpu/drm/i915/i915_guc_submission.c | 1 +
>> drivers/gpu/drm/i915/intel_lrc.c | 6 +++++-
>> 4 files changed, 9 insertions(+), 1 deletion(-)
>> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
>> index a4c243c..bc28a10 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
>> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
>> @@ -281,6 +281,7 @@ relocate_entry_cpu(struct drm_i915_gem_object *obj,
>> + obj->dirty = 1;
> Nak. CPU dirtying is a per-page interface.
That's what my commit message said. But let's at least have /correct/
behaviour while we work out which object types we (can) support here.
ret = relocate_entry_cpu(obj, reloc, target_offset);
else if (obj->map_and_fenceable)
ret = relocate_entry_gtt(obj, reloc, target_offset);
else if (cpu_has_clflush)
ret = relocate_entry_clflush(obj, reloc, target_offset);
both the other routines parallel to relocate_entry_cpu() [i.e.
relocate_entry_gtt() and relocate_entry_clflush()] mark the whole object
dirty. Why be inconsistent?
Can we be sure that the object in question actually has per-page
tracking of dirty pages. shmfs objects do, but not phys, which only has
object-level dirty tracking. Can we guarantee that only the right sort
of objects will be handled here? And when stolen objects are exposed to
More information about the Intel-gfx