search

TACC / pvOSPRay

Other
9 stars 4 forks source link

memory leak in polydatamapper #16

Open carsonbrownlee opened 9 years ago

carsonbrownlee commented 9 years ago

polydatamapper has local mallocs that need to be properly managed.

snkrs commented 8 years ago

I love to see ospray & embree in paraview, but the memory leaks make it unusable!! After a few frames I have 64GB exhausted. And the results look so much better! There seems to be almost no activity on this front, is the project dead?

carsonbrownlee commented 8 years ago

hello, We are actively working on development and appreciate feedback, for static data using the git repo memory leaks should be fairly minimal. Are you using the binaries released with 5.0 by any chance? There is a known bug introduced in the binary ParaView release that does not show up in the latest git repo, we are actively working with ParaView to get that updated in their build system for ParaView. For static data, frame to frame memory leaks should be very small. There are known memory leaks for dynamic data that we are working on. also note that there is significant memory overhead due to memory copies of geometry over to ospray, and acceleration structure builds so there will be some memory overhead just from using ospray. Carson

On Feb 10, 2016, at 3:05 PM, snkrs notifications@github.com wrote:

I love to see ospray & embree in paraview, but the memory leaks make it unusable!! After a few frames I have 64GB exhausted. And the results look so much better! There seems to be almost no activity on this front, is the project dead?

— Reply to this email directly or view it on GitHub https://github.com/TACC/pvOSPRay/issues/16#issuecomment-182581944.

snkrs commented 8 years ago

Hi, ok thanks for the reply. I am using the one shipped with 5.0. Unfortunately I have a changing iso-surface (contour) of a vtkUnstructuredGrid, I guess that qualifies for dynamic data. But I will try tomorrow to compile the latest version. Do you recommend master or dev branch? Thanks for the great work, Christian

carsonbrownlee commented 8 years ago

the version that paraview released had a bug in it that recreated the frame buffer every frame, which unfortunately makes a poor initial presentation of pvOSPRay. Building from source will help significantly, though you may still see a lot of memory usage when using a changing isosurface. You should also hopefully be able to wait for the next paraview binary update which I believe they are putting together this week. Carson

On Feb 10, 2016, at 3:26 PM, snkrs notifications@github.com wrote:

Hi, ok thanks for the reply. I am using the one shipped with 5.0. Unfortunately I have a changing iso-surface (contour) of a vtkUnstructuredGrid, I guess that qualifies for dynamic data. But I will try tomorrow to compile the latest version. Do you recommend master or dev branch? Thanks for the great work, Christian

— Reply to this email directly or view it on GitHub https://github.com/TACC/pvOSPRay/issues/16#issuecomment-182588636.

carsonbrownlee commented 8 years ago

Master branch should work. Carson

On Feb 10, 2016, at 3:34 PM, Carson Brownlee carsonsbrownlee@gmail.com wrote:

the version that paraview released had a bug in it that recreated the frame buffer every frame, which unfortunately makes a poor initial presentation of pvOSPRay. Building from source will help significantly, though you may still see a lot of memory usage when using a changing isosurface. You should also hopefully be able to wait for the next paraview binary update which I believe they are putting together this week. Carson

On Feb 10, 2016, at 3:26 PM, snkrs notifications@github.com wrote:

Hi, ok thanks for the reply. I am using the one shipped with 5.0. Unfortunately I have a changing iso-surface (contour) of a vtkUnstructuredGrid, I guess that qualifies for dynamic data. But I will try tomorrow to compile the latest version. Do you recommend master or dev branch? Thanks for the great work, Christian

— Reply to this email directly or view it on GitHub.

markstock commented 6 years ago

I am seeing this with version 5.4.0 with OSPRay built on CentOS 7.3.

My python script loops over multiple frames, in each loop iteration is loads a state file, replaces the data with the proper data for that frame, saves a screen shot rendered with OSPRay, and then calls Delete and del for everything, AND uses the ResetSession function from Utkarsh (here: https://www.mail-archive.com/paraview@paraview.org/msg24237.html). Memory increases to fill up my machine (30 time steps out of >1000) before crashing. When I turn OSPRay off, memory fluctuates but is bounded.