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.harri...@intel.com wrote: >>> From: John Harrison <john.c.harri...@intel.com> >>> >>> 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
