[PATCH 3/4] drm/i915: Allow userspace to hint that the relocations were known

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux