[Mesa-dev] [PATCH 1/4] r600g/compute: Don't leak cbufs in compute state

Michel Dänzer michel at daenzer.net
Mon Nov 17 18:48:30 PST 2014


On 17.11.2014 23:30, Aaron Watry wrote:
> On Mon, Nov 17, 2014 at 1:45 AM, Michel Dänzer <michel at daenzer.net> wrote:
>> On 14.11.2014 19:37, Marek Olšák wrote:
>>> surface_destroy should never be called directly, because surfaces have
>>> a reference counter. For unreferencing resources, use
>>> pipe_surface_reference(&pointer, NULL). It will call surface_destroy
>>> if needed.
>>
>> Indeed, if this was the right place for this, it could be done both
>> easier and more robustly:
>>
>>                 for (int i = 0; i < fb_state->nr_cbufs; i++)
>>                         pipe_surface_reference(&fb_state->cbufs[i], NULL);
>>
>
> Yeah, you're right about that.  After your (Michel/Marek) replies, I
> had come to the same conclusion about simplifying things.  I'm having
> *fun* deciding where the proper place to put this in the evergreen
> code is.  We end up calling evergreen_set_rat from multiple places,
> which is where the surfaces are created, and then we keep a list with
> a set count...  and the individual surfaces themselves get freed as
> their reference counts change.  In theory, they all get
> referenced/freed at the same point, but there's no guarantees that I
> can see.
>
> The first logical place that I saw to put the de-reference is in
> evergreen_set_global_binding and the matching
> create/delete_compute_state functions.

AFAICT it indeed needs to be handled in evergreen_set_compute_resources 
and evergreen_set_global_binding. Does the attached patch work?


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-r600g-compute-Fix-cbuf-leaks.patch
Type: text/x-patch
Size: 2890 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20141118/3bc7f90a/attachment.bin>


More information about the mesa-dev mailing list