Op 11-01-16 om 20:06 schreef John Harrison: > On 08/01/2016 22:08, Chris Wilson wrote: >> On Fri, Jan 08, 2016 at 06:47:25PM +0000, John.C.Harrison@xxxxxxxxx wrote: >>> From: John Harrison <John.C.Harrison@xxxxxxxxx> >>> >>> The request structure is reference counted. When the count reached >>> zero, the request was immediately freed and all associated objects >>> were unrefereced/unallocated. This meant that the driver mutex lock >>> must be held at the point where the count reaches zero. This was fine >>> while all references were held internally to the driver. However, the >>> plan is to allow the underlying fence object (and hence the request >>> itself) to be returned to other drivers and to userland. External >>> users cannot be expected to acquire a driver private mutex lock. >> It's a trivial issue to fix to enable freeing requests without holding the >> struct_mutex. You don't need to even add any new lists, delayed freeing >> mechanisms and whotnot. >> -Chris >> > > As the driver stands, it is not trivial to free a request without holding the mutex. It does things like unpinning buffers, freeing up contexts (which is a whole other bundle of complication), releasing IRQs. It may be possible to re-organise things to make those operations safe to do without the mutex but it certainly does not look trivial! Those things could be done as soon as the fence is signaled, doing it on free() is slightly too late.. ~Maarten _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
