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

[Daniel Vetter]

On Tue, Dec 01, 2015 at 01:21:07PM +0000, Dave Gordon wrote:
> On 01/12/15 13:04, Chris Wilson wrote:
> >On Tue, Dec 01, 2015 at 12:42:02PM +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, the object should be
> >>marked dirty, to ensure that the modifications are not discarded if the
> >>object is evicted under memory pressure.
> >>
> >>This is similar to commit
> >>	commit 51bc140431e233284660b1d22c47dec9ecdb521e
> >>	Author: Chris Wilson <chris at chris-wilson.co.uk>
> >>	Date:   Mon Aug 31 15:10:39 2015 +0100
> >>	drm/i915: Always mark the object as dirty when used by the GPU
> >>
> >>in which Chris ensured that updates by the GPU were not lost due to
> >>eviction, but this patch applies instead to the multiple places where
> >>object content is updated by the host CPU.
> >
> >Apart from that commit was to mask userspace bugs, here we are under
> >control of when the pages are marked and have chosen a different
> >per-page interface for CPU writes as opposed to per-object.
> >-Chris
> >
> 
> The pattern
> 	get_pages();
> 	kmap(get_page())
> 	write
> 	kunmap()
> occurs often enough that it might be worth providing a common function to do
> that and mark only the specific page dirty (other cases touch the whole
> object, so for those we can just set the obj->dirty flag and let put_pages()
> take care of propagating that to all the individual pages).
> 
> But can we be sure that all the functions touched by this patch will operate
> only on regular (default) GEM objects (i.e. not phys, stolen, etc) 'cos some
> of those don't support per-page tracking. What about objects with no backing
> store -- can/should we mark those as dirty (which would prevent eviction)?

I thought our special objects do clear obj->dirty on put_pages? Can you
please elaborate on your concern?

While we discuss all this: A patch at the end to document dirty (maybe
even as a first stab at kerneldoc for i915_drm_gem_buffer_object) would be
awesome.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch