Search the Community

I'm noticing a memory leak every time I make a call to several of the new Viewport::render* calls. These are the functions I've tested and experienced the issue with: void render (Camera camera) void renderImage2D (Camera camera, Image image) void renderImage2D (Camera camera, Image image, int width, int height, int hdr = 0) More details: My application creates a Unigine-Qt window (subclasses Unigine::App), then creates additional rendering windows to show other views (much like the old RenderQt sample which no longer appears to be part of 2.2.1). Each view is updated continuously during the run loop, so every time a paint event is requested, Viewport::render is called (once per additional window). I've recreated the issue by porting the old RenderQt example to 2.2.1 (attached). I've narrowed the leak down to the single Viewport::render call -- with this line in, the program leaks, but when this line is commented, no memory is leaked. I'm building in release/x64/single precision on Windows. Am I forgetting something in order to prevent such leaking? Even more details: In my program (which uses 6 external 1280x800 windows for rendering to projectors), the leak happens rapidly. I assume because I'm rendering fairly large textures (1280x800 x 6), Unigine quickly reaches 15-20+ GB of RAM, then crashes. What's strange is that I only notice this rapid leaking when the Unigine::App is minimized (perhaps because drawing happens faster when the the app is minimized, leading to more rapid Viewport::render calls?). However, in the attached example, I'm noticing leaking no matter if the main app is shown or minimized. Thanks for your help! Kevin RenderQt-viewport.zip

Hi, I've got some feature request concerning how memory heap allocations are done in Unigine, and more precisely on how one can switch from the Unigine heap allocator to a different one (such as dlmalloc for instance, or the default Windows allocator which is not so fast but is pretty good at keeping memory fragmentation low). Important thing before going on: I'm using the source-code version of the SDK, and Unigine is linked statically to my project (so not as a separated DLL). So here are the requests: 1) At first glance, it seems pretty straightforward to switch from the Unigne allocator to the default system one. The way it's meant to be done is by removing the #USE_MEMORY and everything should be fine. Well it's not, and the reason for that is (obviously) the SSE variables that need to be 16 bytes aligned. So here is the first problem with the memory management in Unigine: the entire code relies on the assumption that new and delete use a default 16 bytes alignement for any allocation. Switching back to an alternative allocator makes the engine crash. An easy way to go around this problem is to override the new/delete operators from the user side, and plug all allocations to a pretty regular _mm_malloc(size, 16) and _mm_free(ptr). Specifying a special alignment for *ALL* allocations is really not the recommanded way to allocate memory... But anyway, that works *almost* fine. There is still one place in the code that is not using the new/delete but uses directly malloc/free instead, which make the engine crash at startup (have a look at Allocator.h line 60 and 67). So the request is pretty simple: could you please remove this direct call to malloc/free and use new/delete instead ? Doing that will ensure that all allocations are redirected to the user-defined new/delete routines. 2) As mentionned earlier, requesting a specific 16 bytes alignment for all allocations is really not recommanded. So the second suggestion would be to identify all the engine allocations that really need this alignment, and use a specific allocation/deallocation routine for those. By doing this, the user would be able to know wich allocations need an alignment and redirect to the appropriate alloc/dealloc function. 3) Ideally, it would be great if the engine could expose a set of function pointers to the memory allocations methods (ie: one pointer to allocate(), one pointer to alignedAllocate(), one pointer to deallocate() and one pointer to alignedDeallocate()). The user would then be able to replace these functions with custom ones and redirect all unigine allocations to his own heap allocator. That's pretty much it. Thanks a lot for your time ! Alessandro Di Meco