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
