topic Hi, in Intel® Embree Ray Tracing Kernels

Memory leak in dynamic_scene sample?

Zviadi_V_ — Thu, 27 Aug 2015 00:05:59 GMT

Hello,

dynamic_scene sample seems to be leaking memory after each rtcCommit call. I tried to track down the issue and it seems that a call to recurse() from operator() in bvh_builder_sah.h, results in 0,4MB of memory leaking. Our project uses Embree with over a hundred of triangle meshes and every time we update the geometry buffers and call rtcCommit, we end up with a 4MB of memory leaking. Could you please suggest a possible fix or some workaround for this?

Thanks

Hi,

BenthinC_Intel — Thu, 27 Aug 2015 07:30:19 GMT

Hi,

Sounds like a bug in the memory allocation for dynamic scenes, I'll have a look at it.

Could give us some more information on the Embree, OS, and compiler version you are using?

Thanks.

Hi,

Zviadi_V_ — Thu, 27 Aug 2015 07:49:50 GMT

Hi,

Embree version used is 2.6.0 64 bit, but latest one (2.6.2) has the same issue.

using Visual Studio 2013 on Win8.1 64 bit

Thanks

OK, this seems to be a

BenthinC_Intel — Thu, 27 Aug 2015 09:50:53 GMT

OK, this seems to be a problem with the fast two-level BVH builder:

As a quick workaround please add the following line to bvh4_builder_twolevel.cpp (Embree 2.6.2) at line 50:

bvh->alloc.clear();

If this fixes the problem on your side please let me know.

We'll look into a more elegant/efficient solution as the current workaround and update 2.6.2 asap.

Thanks a lot for reporting this issue.

Thanks for the quick feedback

Zviadi_V_ — Thu, 27 Aug 2015 11:43:00 GMT

Thanks for the quick reply. I tested the suggested workaround in Embree 2.6.0 and this seem to fix the memory leak issue. Now the memory usage of dynamic_scene sample never goes above 150MB, but oscillates between 150.4 and 150 (debug build). I'll try to update Embree lib in our project to see if the huge memory leak issue we had is also fixed there. Will let you know how it goes

Thanks for you help!

This indeed fixed our issue.

Zviadi_V_ — Thu, 27 Aug 2015 16:13:29 GMT

This indeed fixed our issue. Thanks again!