[Intel-gfx] [PATCH 3/4] drm/i915: Allow userspace to hint that the relocations were known
Daniel Vetter
daniel at ffwll.ch
Sat Nov 10 21:17:05 CET 2012
On Sat, Nov 10, 2012 at 7:08 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Sat, 10 Nov 2012 18:16:16 +0100, Daniel Vetter <daniel at ffwll.ch> wrote:
>> - Can we abolish the pending_read/write_domains and just go with a
>> per-object GPU_WRITE flag? Afaik that's all we need with the
>> flushing_list gone. To avoid a massive rewrite of the code I'm thinking
>> of just keeping around a pending_gpu_write bool (since reads are
>> implicit) and then using that to fill out generic gpu domains in
>> i915_gem_execbuffer_move_to_active. E.g. set all gpu read domains if
>> there is no write, otherwise just set the render domain in both.
>
> Just a quick comment. I started with just a WRITE flag, then realised I
> needed to mark the read domains as well (for GPU activity tracking). So
> I concluded that just passing along the domains was easy enough for
> userspace and better for future-proofing. That is definitely one of the
> places where we need to be careful with designing the API - more ideas
> are welcome.
Hm, I've thought we could get away for the gpu activity tracking by
unconditionally assuming that any passed-in object is in is in all
read domains. For cache flushing it doesn't matter what we set anyway
since we invalidate/flush unconditionally all caches before/after each
batch. And for activity tracking we unconditionally put all objects in
a given execbuf to the front of the active list (with updated
ring/seqno). The only important thing is to keep the write tracking to
not break our various read/read optimizations. Since we allow in-batch
write domain changes already (and hence more than one write domain
set) we could even do a simple
obj->base.read_domains = GPU_DOMAINS;
if (obj->pending_gpu_write) obj->base.write_domain = GPU_DOMAINS;
For ring-sync/semaphores we already do an unconditional call to
i915_gem_object_sync. So what do I miss?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
More information about the Intel-gfx
mailing list