Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UsdImagingDelegate::SetTime Performance in static scenes #1166

Closed
williamkrick opened this issue Apr 17, 2020 · 4 comments
Closed

UsdImagingDelegate::SetTime Performance in static scenes #1166

williamkrick opened this issue Apr 17, 2020 · 4 comments

Comments

@williamkrick
Copy link
Contributor

Description of Issue

I'm doing profiling of mayaUSD looking at overall draw performance. One hotspot I am seeing is significant time spent in UsdImagingDelegate::SetTime during playback for scenes which are fully static. The code there appears to have to visit every prim when time changes to see if it has time varying bits. In my large static scene this is taking up about 8% of my frame time. I'm expecting that number to grow as we finish more optimizations in the Vp2RenderDelegate and shrink the total frame time.

I do realize that playing back a fully static scene is not useful, I'm just using this example to illustrate the per-object overhead that static objects have during playback.

It seems like low hanging fruit for a nice speedup during playback that I think everyone is probably seeing.

Steps to Reproduce

  1. Open a large, fully static USD file in your favorite USD app. In my case I am opening a USD scene which has around 80k prims in MayaUSD, but I think this issue will affect all USD apps.
  2. Playback the scene so that time is changing every frame and use a performance profiler to measure hotspots.
  3. You should see significant time spent in UsdImagingDelegate::SetTime() iterating the full list of prims checking for time varying bits.

System Information (OS, Hardware)

I tested on Windows 10 with an AMD 3970X, but I think this issue will occur on all system configurations. The relative time spent in the hotspot will of course vary depending on the system & USD host application.

Package Versions

USD v0.20.5-beta1-40c8134
Looking at the up-to-date sources for UsdImagingDelegate::SetTime() I think this issue still exists.

Build Flags

python build_usd.py
--python
--no-debug-python
--no-tests
--build-relwithdebug
--build-shared
--no-alembic
--build-args
USD "a bunch of stuff to build with the same python Maya uses"
boost "--with-date_time -with-thread --with-system --with-filesystem"

@jilliene
Copy link

Filed as internal issue #USD-5999

@PixelPartner
Copy link

Would you be allowed to share the "bunch of stuff ..." for Maya, because it might help me and others to build for other Autodesk builds. I consider to build USD to use with VRED.

@williamkrick
Copy link
Contributor Author

Sure it's not secret, I just thought it was long and uninteresting. I suppose things my be a little different for you because I'm building Maya while you have a Maya install.

First figure out what python executable is actually in use by Maya. I believe when you install Maya it will install python as well if you don't already have it.

We set:

-DPYTHON_INCLUDE_DIR=C:/Python27/include
-DPYTHON_EXECUTABLE=C:/Python27/python.exe
-DPYTHON_LIBRARIES=C:/Python27/libs/python27.lib

Where my installed version of python is 2.7.11.

pixar-oss pushed a commit that referenced this issue May 12, 2020
… SetTime().

Fixes #1166

(Internal change: 2066734)
(Internal change: 2067677)
@williamkrick
Copy link
Contributor Author

I tested this today in e7ff8e8, which includes the related commit a4f7a2e and the runtime of UsdImagingDelegate::SetTime() no longer scales with the number of static objects in the scene, thank you for fixing this one!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants