[Intel-gfx] [PATCH 1/3] drm/i915: mark GEM objects as dirty when filled by the CPU

[Dave Gordon]

On 08/12/15 17:00, Chris Wilson wrote:
> On Tue, Dec 08, 2015 at 04:51:16PM +0000, Dave Gordon wrote:
>> In various places, a GEM object is filled with data by means of CPU
>> writes. In such cases, the object should be marked dirty, to ensure that
>> the data is not discarded if the object is evicted under memory
>> pressure.
>>
>> This incorporates and supercedes Alex Dai's earlier patch
>> [PATCH v1] drm/i915/guc: Fix a fw content lost issue after it is evicted
>>
>> Signed-off-by: Dave Gordon <david.s.gordon at intel.com>
>> Cc: Chris Wilson <chris at chris-wilson.co.uk>
>> Cc: Alex Dai <yu.dai at intel.com>
>> ---
>>   drivers/gpu/drm/i915/i915_cmd_parser.c | 1 +
>>   drivers/gpu/drm/i915/i915_gem.c        | 1 +
>>   2 files changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c b/drivers/gpu/drm/i915/i915_cmd_parser.c
>> index 814d894..292bd5d 100644
>> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
>> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
>> @@ -945,6 +945,7 @@ static u32 *copy_batch(struct drm_i915_gem_object *dest_obj,
>>   		drm_clflush_virt_range(src, batch_len);
>>
>>   	memcpy(dst, src, batch_len);
>> +	dest_obj->dirty = 1;
>
> There is no bug here.
> -Chris

Because the shadow batch has been page-pinned by the caller? Two 
questions, then:

1. Do we reuse the same shadow batch if the same source batch is
    resubmitted? If so, can we be sure that it has stayed pinned
    (one way or another) for the entire intervening period?

2. If the shadow batch can never be unpinned, why do we allocate
    it as a GEM object with backing store which can apparently
    never be used. We could get rid of the shmfs setup overhead by
    choosing an object type without backing store.

.Dave.