<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Kernel memory leak using openCL ? in i.MX Processors</title>
    <link>https://community.nxp.com/t5/i-MX-Processors/Kernel-memory-leak-using-openCL/m-p/660599#M101389</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Of course, but I don't know what you mean precisely by log or app file.&amp;nbsp; The code I showed is actually the heart of a gstreamer plugin to transform bayer to downscaled rgb.&amp;nbsp; Here is the cl file, which is compiled once in the init phase of the plugin :&lt;/P&gt;&lt;P&gt;__kernel void bayer2rgb_half(__global uchar *bayer, __global uchar *rgb)&lt;BR /&gt;{&lt;BR /&gt; int id_x = get_global_id(0);&lt;BR /&gt; int id_y = get_global_id(1);&lt;BR /&gt; int bayer_width = 2 * get_global_size(0);&lt;BR /&gt; int rgb_width = get_global_size(0);&lt;/P&gt;&lt;P&gt;int r = bayer[(2 * id_y + 1) * bayer_width + 2 * id_x + 1];&lt;BR /&gt; int g = ((int)bayer[2 * id_y * bayer_width + 2 * id_x + 1] + (int)bayer[(2 * id_y + 1) * bayer_width + 2 * id_x]) / 2; // Casts from uchar to int needed otherwise risk of overflow;&lt;BR /&gt; int b = bayer[2 * id_y * bayer_width + 2 * id_x];&lt;/P&gt;&lt;P&gt;int rgb_id = id_y * rgb_width + id_x;&lt;BR /&gt; rgb[3 * rgb_id] = r;&lt;BR /&gt; rgb[3 * rgb_id + 1] = g;&lt;BR /&gt; rgb[3 * rgb_id + 2] = b;&lt;BR /&gt;}&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I notice the kernel memory leak because after some time of running a very simple pipeline :&lt;/P&gt;&lt;P&gt;gst-launch-1.0 v4l2src ! video/x-bayer ! ourbayer2rgb ! fakesink&lt;/P&gt;&lt;P&gt;the kernel starts the oom procedure and kill random programs; this does not happen when&lt;/P&gt;&lt;P&gt;I do not run this pipeline.&amp;nbsp; On our board with 500Mb free when starting the pipeline, it takes several hours (at 4 fps)&lt;/P&gt;&lt;P&gt;before the oom procedure starts.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Fri, 09 Dec 2016 17:19:41 GMT</pubDate>
    <dc:creator>phdm</dc:creator>
    <dc:date>2016-12-09T17:19:41Z</dc:date>
    <item>
      <title>Kernel memory leak using openCL ?</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/Kernel-memory-leak-using-openCL/m-p/660597#M101387</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi all,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I have a simple openCL kernel called repeatedly on a image stream.&amp;nbsp; The repeated&amp;nbsp; part is :&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;cl_int err;&lt;/P&gt;&lt;P&gt;/* Create memory buffers */&lt;BR /&gt; input_buffer = clCreateBuffer(context, CL_MEM_READ_ONLY | CL_MEM_USE_HOST_PTR, input_size, src, &amp;amp;err);&lt;BR /&gt; opencl_check(err, "Could not create the input buffer.");&lt;BR /&gt; output_buffer = clCreateBuffer(context, CL_MEM_WRITE_ONLY | CL_MEM_USE_HOST_PTR, output_size, dest, &amp;amp;err);&lt;BR /&gt; opencl_check(err, "Could not create the output buffer.");&lt;/P&gt;&lt;P&gt;/* Set OpenCL kernel arguments */&lt;BR /&gt; err = clSetKernelArg(kernel, 0, sizeof(cl_mem), &amp;amp;input_buffer);&lt;BR /&gt; err |= clSetKernelArg(kernel, 1, sizeof(cl_mem), &amp;amp;output_buffer);&lt;BR /&gt; opencl_check(err, "Could not set the kernel arguments.");&lt;/P&gt;&lt;P&gt;/* Execute OpenCL kernel */&lt;BR /&gt; size_t global_work_size[2];&lt;BR /&gt; global_work_size[0] = width;&lt;BR /&gt; global_work_size[1] = height;&lt;/P&gt;&lt;P&gt;err = clEnqueueNDRangeKernel(command_queue, kernel, 2, NULL, global_work_size, NULL, 0, NULL, NULL);&lt;BR /&gt; opencl_check(err, "Could not enqueue the kernel execution command.");&lt;/P&gt;&lt;P&gt;/* Transfer result from output buffer */&lt;BR /&gt; err = clEnqueueReadBuffer(command_queue, output_buffer, CL_TRUE, 0, output_size, dest, 0, NULL, NULL);&lt;BR /&gt; opencl_check(err, "Could not read the output buffer.");&lt;/P&gt;&lt;P&gt;err = clReleaseMemObject(input_buffer);&lt;BR /&gt; opencl_check(err, "Could not release input buffer.");&lt;BR /&gt; err = clReleaseMemObject(output_buffer);&lt;BR /&gt; opencl_check(err, "Could not release output buffer.");&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The image transformation works perfectly, but this program is plagued by a kernel memory leak, that I cannot spot.&lt;/P&gt;&lt;P&gt;I work with the g3-4.1.15_1.2.0_ga kernel and the 5.0.11.p8.6+hfp vivante libraries.&amp;nbsp; Is there an obvious mistake in the above code that could lead to a kernel memory leak ?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Alternatively, is there a way to track memory leaks in galcore driver ?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I must add that valgrind does not indicate any user memory leak.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I must also add that the kernel memory leaked is not even freed when the program terminates.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;It seems that the memory is freed when I unload (rmmod) and reload (modprobe) the galcore module.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I have estimated the leak rate, by disabling as many processes as I could, and logging 'free' answers.&amp;nbsp; My estimate is 2300 bytes leaked per iteration (= frame, = kernel call).&amp;nbsp; This is not the size of my frames (neither input_size, nor output_size)&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks in advance&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 08 Dec 2016 20:38:20 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/Kernel-memory-leak-using-openCL/m-p/660597#M101387</guid>
      <dc:creator>phdm</dc:creator>
      <dc:date>2016-12-08T20:38:20Z</dc:date>
    </item>
    <item>
      <title>Re: Kernel memory leak using openCL ?</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/Kernel-memory-leak-using-openCL/m-p/660598#M101388</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;hi Philippe,&lt;/P&gt;&lt;P&gt;Could you please add your log, and your app file?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;thanks&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 09 Dec 2016 16:53:29 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/Kernel-memory-leak-using-openCL/m-p/660598#M101388</guid>
      <dc:creator>Bio_TICFSL</dc:creator>
      <dc:date>2016-12-09T16:53:29Z</dc:date>
    </item>
    <item>
      <title>Re: Kernel memory leak using openCL ?</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/Kernel-memory-leak-using-openCL/m-p/660599#M101389</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Of course, but I don't know what you mean precisely by log or app file.&amp;nbsp; The code I showed is actually the heart of a gstreamer plugin to transform bayer to downscaled rgb.&amp;nbsp; Here is the cl file, which is compiled once in the init phase of the plugin :&lt;/P&gt;&lt;P&gt;__kernel void bayer2rgb_half(__global uchar *bayer, __global uchar *rgb)&lt;BR /&gt;{&lt;BR /&gt; int id_x = get_global_id(0);&lt;BR /&gt; int id_y = get_global_id(1);&lt;BR /&gt; int bayer_width = 2 * get_global_size(0);&lt;BR /&gt; int rgb_width = get_global_size(0);&lt;/P&gt;&lt;P&gt;int r = bayer[(2 * id_y + 1) * bayer_width + 2 * id_x + 1];&lt;BR /&gt; int g = ((int)bayer[2 * id_y * bayer_width + 2 * id_x + 1] + (int)bayer[(2 * id_y + 1) * bayer_width + 2 * id_x]) / 2; // Casts from uchar to int needed otherwise risk of overflow;&lt;BR /&gt; int b = bayer[2 * id_y * bayer_width + 2 * id_x];&lt;/P&gt;&lt;P&gt;int rgb_id = id_y * rgb_width + id_x;&lt;BR /&gt; rgb[3 * rgb_id] = r;&lt;BR /&gt; rgb[3 * rgb_id + 1] = g;&lt;BR /&gt; rgb[3 * rgb_id + 2] = b;&lt;BR /&gt;}&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I notice the kernel memory leak because after some time of running a very simple pipeline :&lt;/P&gt;&lt;P&gt;gst-launch-1.0 v4l2src ! video/x-bayer ! ourbayer2rgb ! fakesink&lt;/P&gt;&lt;P&gt;the kernel starts the oom procedure and kill random programs; this does not happen when&lt;/P&gt;&lt;P&gt;I do not run this pipeline.&amp;nbsp; On our board with 500Mb free when starting the pipeline, it takes several hours (at 4 fps)&lt;/P&gt;&lt;P&gt;before the oom procedure starts.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 09 Dec 2016 17:19:41 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/Kernel-memory-leak-using-openCL/m-p/660599#M101389</guid>
      <dc:creator>phdm</dc:creator>
      <dc:date>2016-12-09T17:19:41Z</dc:date>
    </item>
    <item>
      <title>Re: Kernel memory leak using openCL ?</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/Kernel-memory-leak-using-openCL/m-p/660600#M101390</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I have reduced my gstreamer pipeline to a simple standalone program that reproduce the problem.&lt;/P&gt;&lt;P&gt;I let it run on a otherwise inactive imx6q board, and I monitor the free ram using the following script :&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;PREVMIN=999999999&lt;/P&gt;&lt;P&gt;while true; do set -- `free | sed -n 2p`; if [ $4 -lt ${PREVMIN} ]; then echo `date` $4; PREVMIN=$4; fi; sleep 1; done&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;And I see my free mem decreasing continuously !!!&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I have attached the testcase&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 15 Dec 2016 16:40:31 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/Kernel-memory-leak-using-openCL/m-p/660600#M101390</guid>
      <dc:creator>phdm</dc:creator>
      <dc:date>2016-12-15T16:40:31Z</dc:date>
    </item>
  </channel>
</rss>

