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. > >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 -- 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
