Skip to content

Houdini ROP performance - #920

Merged
andrewkaufman merged 23 commits into
ImageEngine:masterfrom
andrewkaufman:sccRopSpeed
Feb 14, 2019
Merged

Houdini ROP performance#920
andrewkaufman merged 23 commits into
ImageEngine:masterfrom
andrewkaufman:sccRopSpeed

Conversation

@andrewkaufman

Copy link
Copy Markdown
Member

This optimization was aimed at some heavy production cases where our SceneCache ROP was taking much longer than seemed necessary.

Most commits refer to extraction of an ~10 million poly production asset, because this was the main asset I used for testing code changes along the way. I've run the final code on a variety of assets to confirm the changes are beneficial in many cases. All results reported below are taken using the full frame range of a real production shot (except d and g which were single frames). Note I also used IECORE_STREAMINDEXEDIO_COMPRESSION set to lz4 9 1 1 for the final timings, which was not the case in the original timing.

  • (a) Large destruction
    • Polys: ~10 million
    • Names/locations: 53
    • Tag prim groups: 10
    • Fun fact: ~5 million polys share one name, and the other ~5 million are distributed fairly evenly between the other names (I think)
  • (b) Hero creature
    • Polys: ~0.5 million
    • Names/locations: 241
    • Tag prim groups: 20
    • Fun fact: 5 UV sets
  • (c) Deforming fur groom (full density groom for a section of a hero creature)
    • Poly Curves: ~0.7 million
    • Names/locations: 10
    • Tag prim groups: 12
  • (d) Baked instancing setup (eg bake out the final world space geo rather than a point cloud)
    • Polys: ~28 million
    • Names/locations: ~1500
    • Tag prim groups: 0
    • Fun fact: 30 points attrs/primvars
  • (e) Baked Crowd w/minimal hierarchy (eg bake out the final world space geo rather than skeletons)
    • Polys: ~10 million
    • Names/locations: 50
    • Tag prim groups: 12
  • (f) Baked Crowd w/full agent hierarchy (eg bake out the final world space geo rather than skeletons)
    • Polys: ~10 million
    • Names/locations: ~12000
    • Tag prim groups: 12
  • (g) Feather groom (full baked groom of a hero creature)
    • Poly Curves: ~6.6 million
    • Names/locations: ~57000
    • Tag prim groups: 0

Here are the results:

Case Original Final
a Time 1h 57m 0h 50m
Size 8.0 gb 5.1 gb
b Time 1h 13m 0h 13m
Size 1.7 gb 0.9 gb
c Time 0h 57m 0h 17m
Size 8.0 gb 3.2 gb
d Time 0h 6m 0h 4m
Size 3.5 gb 0.5 gb
e Time 5h 54m 1h 33m
Size 33.6 gb 25.6 gb
f Time 5h 38m 1h 46m
Size 34.9 gb 27.7 gb
g Time 0h 3.0m 0h 1.5m
Size 1.0 gb 0.7 gb

Improvements

  • Houdini: Optimized SceneCache ROP.

Fixes

  • Houdini: Fixed a bug in IECoreHoudini::LiveScene::readTags().

Breaking Changes

  • Houdini:
    • Curves and Points no longer have indexed UVs when extracted from Houdini.
      • This should be irrelevant as we were throwing the data away at rendertime, but it does technically result in different data on disk.
    • Several public methods on FromHoudiniGeometryConverter have new signatures.
      • None of these functions were used in the IE codebase and we're still in alpha.
    • I've removed AttributeRemap & RemapInfo
      • The tests were failing, and rather than fix them, I decided to remove the feature, as it was fairly RenderMan specific, hasn't been used since IECoreHoudini was in its infancy (as far as I'm aware), and these days it'd be more appropriate to do those sorts of conversions either live in Houdini or as a post process using a tool like Gaffer.

Combined with the previous commmit, this reduced extraction of an ~10 million poly production asset from 108s to 88s
In Cortex terminology, Vertex refers to the "visible" vertices (sometimes called points in other packages), while FaceVarying refers to the per-face vertices. MeshVertex is not a term we use anywhere.
…imvars.

Note this required modifying the DeleteFlaggedVertexFunctor a bit since we don't have vertexIds for cuves.
This reduced extraction of an ~10 million poly production asset from 88s to 84s
…ore hash_value

This reduced extraction of an ~10 million poly production asset from 84s to 80s
The tag prefix is fixed so we don't need a regex. We know they are unique as well, since they came from primvar names, so we don't need an intermediate set.

This reduced extraction of an ~10 million poly production asset from 80s to 65s
We should never haven been returning early or stomping over the tags accumulated from the logic above.
…ariables.

This was an unncessary creation of redundant data, when all we wanted was the mapping of names/locations to tags.

This reduced extraction of an ~10 million poly production asset from 65s to 58s
Default is true for backwards compatibility.
This has 3 benefits:
- We can avoid the needless UV welding for Curves and Points
- We can avoid the needless welding on the original extracted mesh, as well as the re-indexing on the segments.
- We can paralllelize the welding per segment per primvar

This reduced extraction of an ~10 million poly production asset from 58s to 45s
This reduced extraction of an ~10 million poly production asset from 45s to 37s
This is just shuffling code to make parallelization more straight forward.
Combined with the previous 2 commits, this actually increased extraction of an ~10 million poly production asset from 37s to 39s

But on a different asset with more attribs it was beneficial.
This reduced extraction of an ~10 million poly production asset from 39s to 37s
The parallel attrib->primvar conversion caused the AttributeRemap tests to fail (because we need to know how many primvars will exist ahead of time). Rather than fix it, I decided to remove the feature, as it was fairly RenderMan specific, hasn't been used since IECoreHoudini was in its infancy (as far as I'm aware), and these days it'd be more appropriate to do those sorts of conversions either live in Houdini or as a post process using a tool like Gaffer.
Collection the vertRange and tranferTags were two of the slower single threaded operations remaining in the conversion process, but SideFx suggested improving the single threaded code before attempting to multithread.

This reduced extraction of an ~10 million poly production asset from 37s to 35s
The combined effect of the last 3 commits reduced extraction of an ~10 million poly production asset from 35s to 33s
@andrewkaufman
andrewkaufman merged commit 97846db into ImageEngine:master Feb 14, 2019
@andrewkaufman
andrewkaufman deleted the sccRopSpeed branch February 14, 2019 18:28
andrewkaufman added a commit that referenced this pull request Feb 14, 2019
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

Successfully merging this pull request may close these issues.

1 participant