On Thu, Mar 19, 2015 at 12:30:56PM +0000, [email protected] wrote: > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c > b/drivers/gpu/drm/i915/intel_ringbuffer.c > index 6f198df..c7dcabd 100644 > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c > @@ -2205,21 +2205,27 @@ int intel_ring_alloc_request_extras(struct > drm_i915_gem_request *request) > return 0; > } > > -int intel_ring_reserved_space_reserve(struct intel_ringbuffer *ringbuf, int > size) > +int legacy_ring_reserved_space_reserve(struct drm_i915_gem_request *request) > { > - /* NB: Until request management is fully tidied up and the OLR is > - * removed, there are too many ways for get false hits on this > - * anti-recursion check! */ > - /*WARN_ON(ringbuf->reserved_size);*/ > + /* > + * The first call merely notes the reserve request and is common for > + * all back ends. The subsequent localised _begin() call actually > + * ensures that the reservation is available. Without the begin, if > + * the request creator immediately submitted the request without > + * adding any commands to it then there might not actually be > + * sufficient room for the submission commands. > + */ > + intel_ring_reserved_space_reserve(request->ringbuf, > MIN_SPACE_FOR_ADD_REQUEST); > + > + return intel_ring_begin(request, 0);
This feels a bit convoluted tbh, and would fall aparat if we start adding sanity checks to _begin/advance functions. Can't we instead directly call ring_wait_for_space? This forgoes the intel_wrap_ring_buffer call, but otoh we just need to factor that into our estimates. Wrapping the ring for the entire reservartion right away is a) way too much - we only wrap individual ring_being calls anyway b) not doing any good since all the intermediate intel_ring_emit calls might very-well push us into a wrap anyway. In the end we just need to increase our reservation with the biggest intel_ring_begin we have in the add_request code - that's the worst-case of ring space we might waste due to wrapping. Same for the lrc path ofc. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
