On Thu, Jul 02, 2015 at 10:30:43AM +0100, Tvrtko Ursulin wrote: > Well.. I the meantime why duplicate it when > i915_gem_validate_context does i915_gem_context_get and deferred > create if needed. I don't see the downside. Snippet from above > becomes: > > ring = &dev_priv->ring[HAS_BLT(dev) ? BCS : RCS]; > ctx = i915_gem_validate_context(dev, file, ring, > DFAULT_CONTEXT_HANDLE); > ... handle error... > /* Allocate a request for this operation nice and early. */ > ret = i915_gem_request_alloc(ring, ctx, &req); > > Why would this code have to know about deferred create. This one is irrelevant. Since the default_context is always allocated and available via the ring, we don't need to pretend we are inside userspace and do the idr lookup and validation, we can just use it directly. > >>Why is this needed? > > > >Because it's a requirement of the op being used on those gen. Later gen > >can keep the fence. > > > >>Could it be called unconditionally and still work? > >> > >>At least I would recommend a comment explaining it. > > It is ugly to sprinkle platform knowledge to the callers - I think I > saw a callsites which call i915_gem_object_put_fence unconditionally > so why would that not work here? That's access via the GTT though. This is access via the GPU using GPU instructions, which sometimes use fences and sometimes don't. That knowledge is already baked into the choice of command. What I would actually support would be to just use CPU GTT clearing. That will run at memory speeds, only stall for a small fraction of the second, and later if the workloads demand it, we can do GPU clearing. It's much simpler, and I would say for any real workload the stolen objects will be cached to avoid reallocations. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
