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

David Lonie david.lonie at kitware.com
Tue Sep 13 09:45:09 EDT 2016


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> 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>
> 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]
>> *Sent:* Monday, September 12, 2016 9:55 AM
>> *To:* Milef, Nicholas Boris
>> *Cc:* vtk-developers at vtk.org
>> *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=l3eCnv-fXfurBfUcrBNHqCKlRe72qQ3nagQmrm6q3hohEnD3O9vTCAFtYWlsdG86bWlsZWZuQHJwaS5lZHU.>
>> > 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=7NKZWv2KRrCx1AgMw-AKD2EBEOZ_yHLwuWYC7a5YyuOCc3L3O9vTCAFtYWlsdG86a2VuLm1hcnRpbkBraXR3YXJlLmNvbQ..>
>>> ]
>>> *Sent:* Friday, September 09, 2016 5:58 PM
>>> *To:* Milef, Nicholas Boris
>>> *Cc:* vtk-developers at vtk.org
>>> <http://redir.aspx?REF=8tUHUt7Em6OuoDLP0IXTEnWAkYtBimEmdiUgStsNrreCc3L3O9vTCAFtYWlsdG86dnRrLWRldmVsb3BlcnNAdnRrLm9yZw..>
>>> *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=-s-oZV-byzl2P_pLPynS3HwuAxI2Vyj3mIunkfvWblWCc3L3O9vTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9T05QRk9mVTJicHpwc3JjSWd0Mm03aGhFV1VKTkpvaFpCUERzWl9CRzRnUE9RN2tZX3RqVENBRnRZV2xzZEc4NmJXbHNaV1p1UUhKd2FTNWxaSFUu>
>>> > 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=ZcAxHLY_Ai0kHKUODgMcw2uLy35zofRh9M6pbYHCbkuCc3L3O9vTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9ejBsb29jalpWZVJ2S1A2NEV3cklnU1V4ZDIwZ21ua1VNV2Rfam16M1g5Z3ZwYnNZX3RqVENBRm9kSFJ3T2k4dmQzZDNMbXRwZEhkaGNtVXVZMjl0>
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>> <http://redir.aspx?REF=MpFChAIndVF-31BDu1P8GKkFmMeEPgpFBoLJJWfQGXaCc3L3O9vTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9eGpMMFpCbGVEX2hPcDZneVRXQ1haZzNPYTg4LThWYk5oYTNjRTNRRDRMd3ZwYnNZX3RqVENBRm9kSFJ3T2k4dmQzZDNMbXRwZEhkaGNtVXVZMjl0TDI5d1pXNXpiM1Z5WTJVdmIzQmxibk52ZFhKalpTNW9kRzFz>
>>>>
>>>> Search the list archives at: http://markmail.org/search/?q=
>>>> vtk-developers
>>>> <http://redir.aspx?REF=h2JdIPhpR-0_gSeMqI67VlYMGejBp5iZLs5f8xgEgr-Cc3L3O9vTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9RjF3Y00tTVdIbzA0dmpTMnZFX1BmUnNHRkxPQnVvb0FmSHVUSkdHdl9mQXZwYnNZX3RqVENBRm9kSFJ3T2k4dmJXRnlhMjFoYVd3dWIzSm5MM05sWVhKamFDOF9jVDEyZEdzdFpHVjJaV3h2Y0dWeWN3Li4.>
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>> <http://redir.aspx?REF=vFatRmULlvJQdJKcGoY-cVxmEzdq4GlVUvkrY43iExaCc3L3O9vTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9TWhXQkFldllOaXFLTkhibHlwMFlQdUFpRXJ3dXFFNGdkeEFqVXFxTy0wWXZwYnNZX3RqVENBRm9kSFJ3T2k4dmNIVmliR2xqTG10cGRIZGhjbVV1WTI5dEwyMWhhV3h0WVc0dmJHbHpkR2x1Wm04dmRuUnJMV1JsZG1Wc2IzQmxjbk0u>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> 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
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160913/94f8a8ff/attachment.html>


More information about the vtk-developers mailing list