On 05/03/2015 16:14, Daniel Vetter wrote:
On Thu, Mar 05, 2015 at 03:06:42PM +0000, John Harrison wrote:
On 05/03/2015 14:44, Daniel Vetter wrote:
Imo reserving a bit of ring space for each add_request should be solid.
Userspace uses the exact same reservation logic for adding end-of-batch
workarounds. The only thing needed to make this solid is to WARN if
add_request ends up using more ring space than what we've reserved (not
just when it actually runs out, that obviously doesn't happen often
enough for testing).
The problem is that there could be multiple requests being processed in
parallel. This is especially true with the scheduler. Userland could submit
a whole stream of batches that all get queued up in the scheduler. Only
later do they get submitted to the hardware. The request must be allocated
up front because there is no other means of tracking them. But reserving
space at that point won't work because you either end up reserving massive
amounts of space if the reserve is cumulative, or not enough if only one
slot is reserved.
At least with execlist we don't have that problem really since writing the
ringbuffer is done synchronously and directly.
For the legacy scheduler I expect that we won't do any of the ringbuf
writes directly and instead that's all done by the scheduler
asynchronously.
So this should just be an issue while we are converting to the scheduler
or on platforms that will never have one. And imo the request ringbuf
reservation is the solution with the simplest impact on the design.
I don't understand what you mean here. The scheduler decouples the
submission of a batch buffer to the driver with the submission of that
batch buffer to the hardware. The submission code path itself is
identical. The scheduler does not do any hardware writes - it merely
adds an extra layer between the user interface code and the hardware
access code. The request creation must be done at driver submission
time. The hardware submission could be an arbitrary amount of time
later. In the intervening time, any number of new batch buffers may be
submitted to the driver and thus new requests be created. This is true
for both legacy and execlist mode.
The space reserve would have to be done at the start of the hardware
submission process not at driver submission time. I.e. it would need to
be a separate and new i915_gem_request_reserve_space() call at the start
of the back half of the exec buffer code. It could not be done during
request creation.
Everything else just readds olr through the backdoor, which is kinda what
we wanted to avoid from an accounting pov. Because then you have again
some random request outstanding which scoops up everything it encounters.
Not quite. The difference is that with something like an outstanding failed
request rather than a lazy one, there is still the segregation of work. The
failed request will be posted and added to the request list in its entirety
before a new request is allocated and used for the new work.
Well history lesson, but that's exactly how olr started out. Then the
hydra grew heads to no end. That's why I don't want to go down this road
again, since I've been on that trip the past 3 years ;-) And since your
motivation for olr light is exactly the one I provided 3 years ago to get
my patch in I think history repeating is likely.
-Daniel
Fair enough. Let's stay away from the evil hydra.
John.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
