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

Ken Martin ken.martin at kitware.com
Wed Sep 14 13:09:43 EDT 2016


You can check if you have the faster version by looking in
OpenGL2/vtkShaderProgram.h for

  // maps of std::string are super slow when calling find
  // with a string literal or const char * as find
  // forces construction/copy/destruction of a
  // std::sting copy of the const char *
  // In spite of the doubters this can really be a
  // huge CPU hog.
  struct cmp_str
  {
     bool operator()(const char *a, const char *b) const
     {
        return strcmp(a, b) < 0;
     }
  };

If you have it, then you have the faster version.

Thanks
Ken


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

> @Ken, my version is a week or two old, it's forked from your fork, so it's
> possible I missed the commit.
>
> @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?
> ------------------------------
> *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.>
>>
>>
>>
>


-- 
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160914/4df904a3/attachment-0001.html>


More information about the vtk-developers mailing list