The performance degradation in immediate mode is expected. If I remember correctly, the LIC algo renders the geometry twice, once to produce the standard rendering and second time to generate projected vector fields which are then processed to generate the LIC image that is then finally blended with the original rendering.
The current implementation does not do anything special to handle parallel rendering, so artifacts are expected. The problem is cannot be simply overcome by D3 or ghost-cells, unfortunately. Utkarsh On Wed, Jun 8, 2011 at 6:00 PM, Burlen Loring <burlen.lor...@gmail.com> wrote: > Hi Utkarsh, > > The issues may be due to my misuse of your design :). I have had immediate > mode disabled for quite some time as it had greatly improved performance. > however this seams to be a major factor in the huge memory bloat when using > LIC rep. > > When I enabled immediate mode, memory usage peaks around 3GB, which still > seams a bit high, but much more reasonable than 18GB. And the growth in > memory usage is much smaller, if at all (it's been harder to examine many > steps because of the performance issue). > > The performance is so reduced in immediate mode that it's nearly impossible > to use (5+ minute for each render). > > I haven't had any success running the LIC parallel, artefacts appear at > process boundaries. I had tried running D3 on the reader which doesn't > generate ghost layer requests yet, but this was unsuccessful. > > Can the LIC work in parallel? > > On 06/07/2011 05:53 AM, Utkarsh Ayachit wrote: >> >> I doubt it's part of the design so to speak :). My suspicion is some >> OpenGL buffers are not being released or something of that nature. >> I'll try to track it down. >> >> Utkarsh >> >> On Mon, Jun 6, 2011 at 9:28 PM, Burlen Loring<blor...@lbl.gov> wrote: >>> >>> Hi, >>> >>> I am seeing some pretty astounding memory usage when using the LIC. My >>> dataset is 100MB image 2D image data. When I load it and display using a >>> slice rep. I use about 800MB of RAM, but when I turn on LIC rep. memory >>> usage goes up to 18GB!! What's worse is that as I advance through the >>> time >>> series with each new step the memory usage grows by 4GB or more, until I >>> run >>> out of RAM. I put the output from one run below, memory usage is reported >>> in >>> KB. >>> >>> Does anyone know why LIC rep. requires such a massive amount of RAM? I >>> didn't see any outright large leaks, so it must be part of this rep. >>> design? >>> And can anything be done to prevent the growth in its usage over time? >>> >>> Listen on port: 11111 >>> Waiting for client... >>> Waiting for server... >>> Client connected. >>> [0] vtkSQBOVReader::SetFileName 0.024441 >>> [0] vtkSQBOVReader::RequestData 0.571345 >>> 1 775272<------------------ memory use w/ surface rep. >>> 1 775272 >>> 0 missmarple 15193 >>> 1 776856 >>> 1 776856 >>> 1 779336 >>> 1 18480044<------------------ memory use w/ LIC rep. >>> [0] vtkSQBOVReader::RequestData 3.05736 >>> 1 18792084 >>> [0] vtkSQBOVReader::RequestData 3.1486 >>> 1 19603868 >>> [0] vtkSQBOVReader::SetFileName 2.09808e-05 >>> Client connection closed. >>> >>> >>> >>> Burlen >>> >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Please keep messages on-topic and check the ParaView Wiki at: >>> http://paraview.org/Wiki/ParaView >>> >>> Follow this link to subscribe/unsubscribe: >>> http://www.paraview.org/mailman/listinfo/paraview >>> > > _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview