[Paraview] Rendering Backend OpenGL2 & PV 5.2.0-RC4 & SurfaceLic --> Problem...

Thu Feb 9 17:16:04 EST 2017

Ken,

I tested your changes and they are working for my more complicated
"production" case.  I am currently running more tests and will update you
if anything goes wrong.

I'm still adjusting my lighting settings from 4.4.0 to 5.x.x to get similar
images between the two versions.  In the past with 4.4.0 I had noticed that
some surface LIC images would seemingly randomly get darker.
Perhaps that is what you are seeing as well.

-Andy

On Thu, Feb 9, 2017 at 11:47 AM, Ken Martin <ken.martin at kitware.com> wrote:

> Thanks so much for the example. I have a VTK topic that I believe will fix
> the issue here:
>
> https://gitlab.kitware.com/vtk/vtk/merge_requests/2463
>
> It fails three of the current paraview LIC tests but with images that
> still look reasonable (although one looks dark to me). The changes only
> impact two files. Your example no longer hangs with these changes. If you
> have a chance to test it on your real data or other cases that would help
> me feel more confident about the change.
>
> Thanks
> Ken
>
>
>
>
> On Wed, Feb 8, 2017 at 9:21 AM, Andy Smith <agsmith424 at gmail.com> wrote:
>
>> Ken,
>>
>> I've attached a small example file and script that demonstrates the
>> problem.
>>
>> The example dataset is a multiblock unstructured grid with two blocks.
>> The script attempts to create two images of slices through the dataset.  At
>> the first slice position data from both blocks are in the slice.  At the
>> second slice position only data from one block is part of the slice.  This
>> works in serial and parallel (two processors) using pvbatch when not using
>> surface LIC and in serial when using surface LIC with the latest ParaView
>> from the git repo.  In parallel, the surface LIC hangs when creating the
>> second image.  This script works in parallel with surface LIC when using
>> version 4.4.0.
>>
>> As an aside, I call the function to ensure that the surface LIC plugin is
>> loaded at the beginning of the script.  When I do this I get warnings about
>> "Replacing existing representation for key: Surface LIC".  I assume this is
>> because in my build I turned on the option to load the surface LIC plugin
>> by default.  Is there a way in Python to check if a plugin is loaded and
>> skip this step if that is the case?
>>
>> Let me know if I can provide any additional information.
>>
>> -Andy
>>
>> On Tue, Feb 7, 2017 at 8:32 AM, Ken Martin <ken.martin at kitware.com>
>> wrote:
>>
>>> Thanks Andy, just to make sure I understand the issue. Is the case that
>>> one processor has no data, or is it that it has data, but it is outside the
>>> current view?
>>>
>>> Thanks
>>> Ken
>>>
>>> On Thu, Feb 2, 2017 at 5:14 PM, Andy Smith <agsmith424 at gmail.com> wrote:
>>>
>>>> I've tested this with the latest ParaView and it does seem to run much
>>>> faster.
>>>> I am having a problem when running in parallel though.  If one
>>>> processor does not have anything to display, the rendering hangs.
>>>> Related to that, what routine actually calls
>>>> vtkCompositeLICHelper::RenderPiece?
>>>> The process that does not have anything to display never gets to that
>>>> function but the other processes do.  In that function there are MPI calls
>>>> where the rendering hangs.
>>>>
>>>> As a reply to Chuck:  I can use EGL in some instances but unfortunately
>>>> not all of our machine have GPUs so software rendering is still required.
>>>>
>>>> Thanks again for all the help.
>>>>
>>>> On Mon, Jan 23, 2017 at 12:45 PM, Ken Martin <ken.martin at kitware.com>
>>>> wrote:
>>>>
>>>>> There is a VTK topic now that should fix this regression. With this
>>>>> change OpenGL2 LIC seems to run much faster (at least 10X).
>>>>>
>>>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/2419
>>>>>
>>>>> Hopefully it will test out OK and get merged into VTK and then merged
>>>>> into ParaView.
>>>>>
>>>>> On Mon, Dec 12, 2016 at 11:38 AM, Andy Smith <agsmith424 at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Ken,
>>>>>>
>>>>>> You are correct in your assumption about my dataset; it is multiblock
>>>>>> unstructured data.  Adding a MergeBlocks filter to my slice does improve
>>>>>> the 5.2.0 with OpenGL2 significantly.
>>>>>> With that change the performance of 5.2.0 with OpenGL2 is on the same
>>>>>> order of magnitude as 5.2.0 with OpenGL and with 4.4.0, though the 5.2.0
>>>>>> variants are still slower than 4.4.0.
>>>>>>
>>>>>> I realized after posting that my comparison is not exactly apples to
>>>>>> apples - my build of 5.2.0 required updates to mesa (13.0.0) compared with
>>>>>> the version I used for 4.4.0 (11.2.0).
>>>>>> I will recompile 4.4.0 with the same mesa version I used with 5.2.0
>>>>>> and report back.
>>>>>>
>>>>>> Thank you for your input.
>>>>>>
>>>>>> -Andy
>>>>>>
>>>>>> On Fri, Dec 9, 2016 at 3:44 PM, Ken Martin <ken.martin at kitware.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I have not had time to look into this, but my quick guess is that
>>>>>>> you have a multiblock dataset with a lot of blocks. Can you try merging the
>>>>>>> blocks all together somehow into one block and see if the rendering speed
>>>>>>> improves?
>>>>>>>
>>>>>>> On Tue, Nov 15, 2016 at 5:35 AM, Stefan Melber <Stefan.Melber at dlr.de
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>
>>>>>>>> i have a problem which is there in all RCs (1-4) of current
>>>>>>>> ParaView: if i compile the RenderingBackend to "OpenGL2" and use SurfaceLic
>>>>>>>> the visualization time goes up from a few seconds (with "OpenGL") to many
>>>>>>>> minutes and the memory consumption from a few GByte to approx 100 GByte.
>>>>>>>> Switching back to OpenGL any thing is fine. Without SurfaceLIC the OpenGL2
>>>>>>>> works although fine for me.
>>>>>>>>
>>>>>>>> Has any one tested OpenGL2 with SurfaceLIC-Plugin the last time and
>>>>>>>> has (the same)  problems?
>>>>>>>>
>>>>>>>> o Kernel 4.7.6-1 / x86-64
>>>>>>>> o Quadro 4000
>>>>>>>> o NVidia driver v367.57
>>>>>>>> o PV 5.2.0 RC1 - RC4
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>>        Stefan
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>>
>>>>>>>> Search the list archives at: http://markmail.org/search/?q=ParaView
>>>>>>>>
>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>> http://public.kitware.com/mailman/listinfo/paraview
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Ken Martin PhD
>>>>>>> Chairman & CFO
>>>>>>> Kitware Inc.
>>>>>>> 28 Corporate Drive
>>>>>>> Clifton Park NY 12065
>>>>>>> 518 371 3971 <(518)%20371-3971>
>>>>>>>
>>>>>>> This communication, including all attachments, contains confidential
>>>>>>> and legally privileged information, and it is intended only for the use of
>>>>>>> the addressee.  Access to this email by anyone else is unauthorized. If you
>>>>>>> are not the intended recipient, any disclosure, copying, distribution or
>>>>>>> any action taken in reliance on it is prohibited and may be unlawful. If
>>>>>>> you received this communication in error please notify us immediately and
>>>>>>> destroy the original message.  Thank you.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>>
>>>>>>> Search the list archives at: http://markmail.org/search/?q=ParaView
>>>>>>>
>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>> http://public.kitware.com/mailman/listinfo/paraview
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ken Martin PhD
>>>>> Chairman & CFO
>>>>> Kitware Inc.
>>>>> 28 Corporate Drive
>>>>> Clifton Park NY 12065
>>>>> 518 371 3971 <(518)%20371-3971>
>>>>>
>>>>> This communication, including all attachments, contains confidential
>>>>> and legally privileged information, and it is intended only for the use of
>>>>> the addressee.  Access to this email by anyone else is unauthorized. If you
>>>>> are not the intended recipient, any disclosure, copying, distribution or
>>>>> any action taken in reliance on it is prohibited and may be unlawful. If
>>>>> you received this communication in error please notify us immediately and
>>>>> destroy the original message.  Thank you.
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Ken Martin PhD
>>> Chairman & CFO
>>> Kitware Inc.
>>> 28 Corporate Drive
>>> Clifton Park NY 12065
>>> 518 371 3971 <(518)%20371-3971>
>>>
>>> This communication, including all attachments, contains confidential and
>>> legally privileged information, and it is intended only for the use of the
>>> addressee.  Access to this email by anyone else is unauthorized. If you are
>>> not the intended recipient, any disclosure, copying, distribution or any
>>> action taken in reliance on it is prohibited and may be unlawful. If you
>>> received this communication in error please notify us immediately and
>>> destroy the original message.  Thank you.
>>>
>>
>>
>
>
> --
> Ken Martin PhD
> Chairman & CFO
> Kitware Inc.
> 28 Corporate Drive
> Clifton Park NY 12065
> 518 371 3971 <(518)%20371-3971>
>
> This communication, including all attachments, contains confidential and
> legally privileged information, and it is intended only for the use of the
> addressee.  Access to this email by anyone else is unauthorized. If you are
> not the intended recipient, any disclosure, copying, distribution or any
> action taken in reliance on it is prohibited and may be unlawful. If you
> received this communication in error please notify us immediately and
> destroy the original message.  Thank you.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20170209/0f38b378/attachment.html>