On Wed, Apr 27, 2016 at 01:51:38PM +0100, Tvrtko Ursulin wrote: > > On 26/04/16 21:06, Chris Wilson wrote: > >In the next patches, we want to move the work out of freeing the request > >and into its retirement (so that we can free the request without > >requiring the struct_mutex). This means that we cannot rely on > >unreferencing the request to completely teardown the request any more > >and so we need to manually unwind the failed allocation. In doing so, we > >reorder the allocation in order to make the unwind simple (and ensure > >that we don't try to unwind a partial request that may have modified > >global state) and so we end up pushing the initial preallocation down > >into the engine request initialisation functions where we have the > >requisite control over the state of the request. > > > >Moving the initial preallocation into the engine is less than ideal: it > >moves logic to handle a specific problem with request handling out of > >the common code. On the other hand, it does allow those backends > >significantly more flexibility in performing its allocations. > > Could add _free_request_extras which would only be allowed to be > called from _alloc_request? That would enable not-polluting the > engine with common code I think. If you look at where I think it should be placed inside lrc, then we need multiple phases. Not that isn't much of a big deal: request_alloc: engine->pin_request() /* prep */ engine->init_context() are more or less what we need, it will take a bit of organisation to align legacy / execlists. But it can be done. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
