[vtk-developers] Why is BuildShaders() continuously being called?

Wed Sep 14 13:02:41 EDT 2016

On Wed, Sep 14, 2016 at 12:59 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> @Dave, no I'm not using transparency at all. I had around 50-60 totally
> opaque objects moving at the same time though, although the triangle counts
> were not huge. This is somewhat unrelated, but why would different shaders
> be needed for different passes? Or is it because it renders with multiple
> passes, which calls rebuild shaders?
>

There are different passes that do different things in the fragment shader
to extract / blend translucent geometry. It will initialize depth buffers
in one pass, peel geometry the next set of passes, and optionally do simple
alpha blending in a final pass.

Dave

> ------------------------------
> *From:* David Lonie [david.lonie at kitware.com]
> *Sent:* Tuesday, September 13, 2016 9:45 AM
> *To:* Ken Martin
> *Cc:* Milef, Nicholas Boris; vtk-developers at vtk.org
>
> *Subject:* Re: [vtk-developers] Why is BuildShaders() continuously being
> called?
>
> Are you rendering any translucent geometry with depth peeling enabled? The
> dual depth peeling passes call BuildShaders multiple times (2-3, IIRC) per
> frame since different shaders are needed for different passes.
>
> Dave
>
> On Mon, Sep 12, 2016 at 2:52 PM, Ken Martin <ken.martin at kitware.com
> <http://redir.aspx?REF=CEOyXTolh-4P2D-iEonQ2IxokEL2ZZjgiza5K3c2WtWVnH-TvtzTCAFtYWlsdG86a2VuLm1hcnRpbkBraXR3YXJlLmNvbQ..>
> > wrote:
>
>> I committed a change in the past couple weeks to improve that. So if you
>> are using an older VTK updating may help.
>>
>> On Mon, Sep 12, 2016 at 2:49 PM, Milef, Nicholas Boris <milefn at rpi.edu
>> <http://redir.aspx?REF=IkNIosyEmsnLhMNAADfPrVIBZPo_Hnc4ZT0JaDo0lsmVnH-TvtzTCAFtYWlsdG86bWlsZWZuQHJwaS5lZHU.>
>> > wrote:
>>
>>> Thanks, that's very helpful! During my performance analysis, I also saw
>>> in the UpdateShader() method, updating the shader uniforms took up a lot of
>>> CPU time as well (at least 40% of the total CPU time). Is it possible to
>>> add more aggressive modification checks to this? For instance, some of the
>>> uniforms such as color may never change.
>>>
>>> Thanks,
>>> Nick
>>> ------------------------------
>>> *From:* Ken Martin [ken.martin at kitware.com
>>> <http://redir.aspx?REF=CEOyXTolh-4P2D-iEonQ2IxokEL2ZZjgiza5K3c2WtWVnH-TvtzTCAFtYWlsdG86a2VuLm1hcnRpbkBraXR3YXJlLmNvbQ..>
>>> ]
>>> *Sent:* Monday, September 12, 2016 9:55 AM
>>> *To:* Milef, Nicholas Boris
>>> *Cc:* vtk-developers at vtk.org
>>> <http://redir.aspx?REF=77gOhYDGaJONRKJZVSyinhENqvLqts2nnbZNrVFlG62VnH-TvtzTCAFtYWlsdG86dnRrLWRldmVsb3BlcnNAdnRrLm9yZw..>
>>> *Subject:* Re: [vtk-developers] Why is BuildShaders() continuously
>>> being called?
>>>
>>> Thanks. I need to make that test more conservative. I'll try making a
>>> topic soon to update it. Probably what it needs is
>>>
>>> (actor->GetProperty() && actor->GetProperty()->GetMTime() > ...) ||
>>> (actor->GetTexture() && actor->GetTexture()->GetMTime() > ...) ||
>>>
>>> as opposed to the
>>>
>>> actor->GetMTime() > ...
>>>
>>> line
>>>
>>> Thanks
>>> Ken
>>>
>>> On Fri, Sep 9, 2016 at 6:20 PM, Milef, Nicholas Boris <milefn at rpi.edu
>>> <http://redir.aspx?REF=EBeZB359llDrjd-nwo3MM-Xzz_a5SWpZGMi3KrAIdp6VnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9bDNlQ252LWZYZnVyQmZVY3JCTkhxQ0tsUmU3MnFRM25hZ1Ftcm02cTNob2hFbkQzTzl2VENBRnRZV2xzZEc4NmJXbHNaV1p1UUhKd2FTNWxaSFUu>
>>> > wrote:
>>>
>>>> Thanks Ken. I was moving a few cone sources around (about 50) with
>>>> SetPosition() and I see that they called Modified() which I'm guessing
>>>> changes MTime? It was mostly for debugging because I can actually get
>>>> around some of this in shaders to avoid going through the rendering
>>>> pipeline. But, there are times when I need to move actors in real time, so
>>>> this can sometimes be a bottleneck for me.
>>>>
>>>> Thanks,
>>>> Nick
>>>> ------------------------------
>>>> *From:* Ken Martin [ken.martin at kitware.com
>>>> <http://redir.aspx?REF=FYnPTePbI0oUN9yrk5e5gJMlFpmxUnh2Muh7Mr_VnyyVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9N05LWld2MktSckN4MUFnTXctQUtEMkVCRU9aX3lITHd1V1lDN2E1WXl1T0NjM0wzTzl2VENBRnRZV2xzZEc4NmEyVnVMbTFoY25ScGJrQnJhWFIzWVhKbExtTnZiUS4u>
>>>> ]
>>>> *Sent:* Friday, September 09, 2016 5:58 PM
>>>> *To:* Milef, Nicholas Boris
>>>> *Cc:* vtk-developers at vtk.org
>>>> <http://redir.aspx?REF=4k8Yz64tdln9TkQdZJIZLZ2a_k8z1aC8dwH_5Qkyw4iVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9OHRVSFV0N0VtNk91b0RMUDBJWFRFbldBa1l0QmltRW1kaVVnU3RzTnJyZUNjM0wzTzl2VENBRnRZV2xzZEc4NmRuUnJMV1JsZG1Wc2IzQmxjbk5BZG5SckxtOXlady4u>
>>>> *Subject:* Re: [vtk-developers] Why is BuildShaders() continuously
>>>> being called?
>>>>
>>>> When  GetNeedToRebuildShaders returns true. Which roughly is
>>>>
>>>>   if (cellBO.Program == 0 ||
>>>>       cellBO.ShaderSourceTime < this->GetMTime() ||
>>>>       cellBO.ShaderSourceTime < actor->GetMTime() ||
>>>>       cellBO.ShaderSourceTime < this->CurrentInput->GetMTime() ||
>>>>       cellBO.ShaderSourceTime < this->SelectionStateChanged ||
>>>>       cellBO.ShaderSourceTime < renderPassMTime ||
>>>>       cellBO.ShaderSourceTime < this->LightComplexityChanged[&cellBO])
>>>>     {
>>>>     return true;
>>>>     }
>>>>
>>>> So if the main points are if you are modifying the actor, mapper, or
>>>> your data. If one of those is being modified every frame then let me know
>>>> the use case and we can see if the current test is being too aggressive etc.
>>>>
>>>> Thanks
>>>> Ken
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Sep 9, 2016 at 5:47 PM, Milef, Nicholas Boris <milefn at rpi.edu
>>>> <http://redir.aspx?REF=gpnYISvvDOAs1AE2npqTuRzDPoJjLoTAOKCG6xGJvPiVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9LXMtb1pWLWJ5emwyUF9wTFB5blMzSHd1QXhJMlZ5ajNtSXVua2Z2V2JsV0NjM0wzTzl2VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5VDA1UVJrOW1WVEppY0hwd2MzSmpTV2QwTW0wM2FHaEZWMVZLVGtwdmFGcENVRVJ6V2w5Q1J6Um5VRTlSTjJ0WlgzUnFWRU5CUm5SWlYyeHpaRWM0Tm1KWGJITmFWMXAxVVVoS2QyRlROV3hhU0ZVdQ..>
>>>> > wrote:
>>>>
>>>>> Under what conditions are shaders actually rebuilt? This seems to be
>>>>> the source of my performance issues and I need to know how to avoid this.
>>>>> The function I'm referring to is in vtkOpenGLPolyDataMapper(). It seems
>>>>> that they get rebuilt when an object gets modified, is this true?
>>>>>
>>>>> Thanks,
>>>>> Nick
>>>>>
>>>>> _______________________________________________
>>>>> Powered by www.kitware.com
>>>>> <http://redir.aspx?REF=IekiU072T4tQkKA1EhP2yERF4NSsNbcM4v5Y-KsekYKVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9WmNBeEhMWV9BaTBrSEtVT0RnTWN3MnVMeTM1em9mUmg5TTZwYllIQ2JrdUNjM0wzTzl2VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5ZWpCc2IyOWphbHBXWlZKMlMxQTJORVYzY2tsblUxVjRaREl3WjIxdWExVk5WMlJmYW0xNk0xZzVaM1p3WW5OWlgzUnFWRU5CUm05a1NGSjNUMms0ZG1RelpETk1iWFJ3WkVoa2FHTnRWWFZaTWpsMA..>
>>>>>
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>> <http://redir.aspx?REF=vZYlEbhL0pDguM7Vb_XvVr611N53JtyMjMgCuPKdZc-VnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9TXBGQ2hBSW5kVkYtMzFCRHUxUDhHS2tGbU1lRVBncEZCb0xKSldmUUdYYUNjM0wzTzl2VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5ZUdwTU1GcENiR1ZFWDJoUGNEWm5lVlJYUTFoYVp6TlBZVGc0TFRoV1lrNW9ZVE5qUlROUlJEUk1kM1p3WW5OWlgzUnFWRU5CUm05a1NGSjNUMms0ZG1RelpETk1iWFJ3WkVoa2FHTnRWWFZaTWpsMFRESTVkMXBYTlhwaU0xWjVXVEpWZG1JelFteGliazUyWkZoS2FscFROVzlrUnpGeg..>
>>>>>
>>>>> Search the list archives at: http://markmail.org/search/?q=
>>>>> vtk-developers
>>>>> <http://redir.aspx?REF=4PGrshj6Qo82lkGltS2-RFMur0lpjKIa9tkdXpjdLjyVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9aDJKZElQaHBSLTBfZ1NlTXFJNjdWbFlNR2VqQnA1aVpMczVmOHhnRWdyLUNjM0wzTzl2VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5UmpGM1kwMHRUVmRJYnpBMGRtcFRNblpGWDFCbVVuTkhSa3hQUW5WdmIwRm1TSFZVU2tkSGRsOW1RWFp3WW5OWlgzUnFWRU5CUm05a1NGSjNUMms0ZG1KWFJubGhNakZvWVZkM2RXSXpTbTVNTTA1c1dWaEthbUZET0Y5alZERXlaRWR6ZEZwSFZqSmFWM2gyWTBkV2VXTjNMaTQu>
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>> <http://redir.aspx?REF=EAlTZLQI3zlSDmRGiGgDemhmy2qt_qeMsjQBiwZsumGVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9dkZhdFJtVUxsdkpRZEpLY0dvWS1jVnhtRXpkcTRHbFZVdmtyWTQzaUV4YUNjM0wzTzl2VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5VFdoWFFrRmxkbGxPYVhGTFRraGliSGx3TUZsUWRVRnBSWEozZFhGRk5HZGtlRUZxVlhGeFR5MHdXWFp3WW5OWlgzUnFWRU5CUm05a1NGSjNUMms0ZG1OSVZtbGlSMnhxVEcxMGNHUklaR2hqYlZWMVdUSTVkRXd5TVdoaFYzaDBXVmMwZG1KSGJIcGtSMngxV20wNGRtUnVVbkpNVjFKc1pHMVdjMkl6UW14amJrMHU.>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Ken Martin PhD
>>>> Chairman & CFO
>>>> Kitware Inc.
>>>> 28 Corporate Drive
>>>> Clifton Park NY 12065
>>>> 518 371 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
>>>
>>> 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
>>
>> 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
>> <http://redir.aspx?REF=26vIYSFmKUypZLnImmTpA4zelCFMO5ZLnX3KwnKIeHSVnH-TvtzTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29t>
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>> <http://redir.aspx?REF=rpvekQp3gTZfZY3uH_gyBw870sETaSZvsK76ByQkaeGVnH-TvtzTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29tL29wZW5zb3VyY2Uvb3BlbnNvdXJjZS5odG1s>
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>> <http://redir.aspx?REF=oIxtxRakH3IHudjawXuHcyFGvxucJjABzwuPyWfs-MiVnH-TvtzTCAFodHRwOi8vbWFya21haWwub3JnL3NlYXJjaC8_cT12dGstZGV2ZWxvcGVycw..>
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>> <http://redir.aspx?REF=FKtbOloD6O-enBFOofiP-siTqalWeju9pA52ojdhF7aVnH-TvtzTCAFodHRwOi8vcHVibGljLmtpdHdhcmUuY29tL21haWxtYW4vbGlzdGluZm8vdnRrLWRldmVsb3BlcnM.>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160914/17e7e254/attachment-0001.html>