Houdini ROP performance - #920
Merged
Merged
Conversation
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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_COMPRESSIONset tolz4 9 1 1for the final timings, which was not the case in the original timing.Here are the results:
Improvements
Fixes
IECoreHoudini::LiveScene::readTags().Breaking Changes
FromHoudiniGeometryConverterhave new signatures.AttributeRemap&RemapInfo