On Tue, Mar 10, 2015 at 04:14:14PM +0000, Chris Wilson wrote: > On Tue, Mar 10, 2015 at 04:06:19PM +0000, Chris Wilson wrote: > > @@ -1235,12 +1257,20 @@ int __i915_wait_request(struct drm_i915_gem_request *req, > > if (ring->id == RCS && INTEL_INFO(dev)->gen >= 6) > > gen6_rps_boost(dev_priv, file_priv); > > > > - if (!irq_test_in_progress && WARN_ON(!ring->irq_get(ring))) > > - return -ENODEV; > > - > > /* Record current time in case interrupted by signal, or wedged */ > > trace_i915_gem_request_wait_begin(req); > > before = ktime_get_raw_ns(); > > + > > + /* Optimistic spin before touching IRQs */ > Perhaps iff timeout == NULL, or pass it along and add a > > if (timeout && timeout_after_eq(jiffies, timeout)) > break; > > before the cpu_relax()? I guess the answer for that is asking how many apps use short opportunistic waits in the frame rendering loop, e.g. to wait for query results and fall back to the ones from the previous frame if they're not available? Also do you have microbenchmark numbers for something midly ridiculous like a loop of very short batches (enough ofc to cause a bit of delay) and immediately stalling for them? It's definitely an awesome idea given that every other lock and sync primitive does it too. -Daniel > > > + ret = __i915_spin_request(req); > > + if (ret == 0) > > + goto out; > > -- > Chris Wilson, Intel Open Source Technology Centre > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
