[Mesa-dev] EXTERNAL: Re: R600/OpenCL - kernel_param resource

Dorrington, Albert albert.dorrington at lmco.com
Fri Apr 11 11:08:51 PDT 2014


I think that is the case. I added the following to evergreen_delete_compute_state() to clean it up, and it seems to have helped.

  if (shader->kernel_param) {
    pipe_resource_reference((struct pipe_resource**)&shader->kernel_param, NULL);
  }

I discovered the functionality of the GALLIUM_REFCNT_LOG environmental variable and some of the associated scripts/tools and am tracking down a few other leaks with the reference counts and objects not being released/destroyed due to the ref-counts not reaching zero.

Hopefully I'll be able to test some of these changes out on real Mesa source code soon, rather than our highly modified version and start contributing some updates back to the baseline.
I've been able to go from running 4 or 5 kernels in a row - to over 3000, before I start hitting some segfaults due to over-allocation of resources

> -----Original Message-----
> From: Tom Stellard [mailto:tom at stellard.net]
> Sent: Friday, April 11, 2014 11:35 AM
> To: Dorrington, Albert
> Cc: mesa-dev at lists.freedesktop.org; Aaron Watry
> Subject: EXTERNAL: Re: [Mesa-dev] R600/OpenCL - kernel_param resource
> 
> On Thu, Apr 10, 2014 at 03:24:32PM +0000, Dorrington, Albert wrote:
> > I am having an issue with a memory leak in an OpenCL program I am
> testing.
> > In the program I call the same kernel repeatedly, for every pixel in
> > an image. (Probably not the most efficient code, but it is a
> > learning/testing thing.)
> >
> > One thing in particular I have not yet been able to figure out, is what
> releases the reference counts for the shader->kernel_param resource
> created in evergreen_compute_upload_input().
> >
> > Tracing through the calls:
> >                 evergreen_compute_upload_input()
> >                 evergreen_cs_set_constant_buffer()
> >                 r600_set_constant_buffer()
> >
> > I can see that if r600_set_constant_buffer() is passed a null
> pipe_constant_buffer input, that it would reset the stat masks and make the
> call to pipe_resource_reference() with a NULL, to decrement the count.
> >
> > But I don't see where that would happen.
> >
> > I am thinking that perhaps there should be something to release the
> reference count for that buffer, either after the evergreen_launch_grid()
> call, or perhaps as the last thing within that call, after the compute_emit_cs()
> call.
> >
> > Or, is this call happening somewhere else that I haven't found?
> >
> 
> kernel_param is probably the source of the leak, it doesn't look like we are
> destroying it anywhere.
> 
> -Tom
> 
> > Thanks,
> > Al Dorrington
> > Software Engineer Sr
> > Lockheed Martin, Mission Systems and Training
> >
> 
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev



More information about the mesa-dev mailing list