APPLE: Fix for Issue #1749

[creijon]

Description of Change(s)

The _topology field in the drawingcoord was overflowing the 8-bit range for assets with a large number of geomsubsets. This has been promoted to a 32-bit value to avoid this.

The instancePrimvar field could also overflow, so this has been promoted to a 32 bit value too.

Fixes Issue(s)

• HdStorm fails to render a mesh with many material GeomSubsets #1749

• I have verified that all unit tests pass with the proposed changes

• I have submitted a signed Contributor License Agreement

[spiffmon]

I'm not up to date on current architecture, but am curious, @jonny-apple , if this changes the size of the structure, when packed? If so, it would be great to see some memory numbers with large numbers of meshes?

[creijon]

I'm not up to date on current architecture, but am curious, @jonny-apple , if this changes the size of the structure, when packed? If so, it would be great to see some memory numbers with large numbers of meshes?

Very good point spiff, I'll run some numbers on the large stages that we have as test assets.

[sunyab]

Filed as internal issue #USD-7774

[creijon]

@spiffmon , I've run a few variations of the field sizes in the HdDrawingCoord structure.
I've used the TS4 assets that you gave us, which has 456,356 prims.
These figures were from running usdview on a Mac with latest OS. It takes a little bit of time for the memory to settle down, so there is some variability.

Firstly, the original 8 bits per field
(9 bytes total, probably rounded to 12)

Physical footprint: 4.7G
Physical footprint (peak): 5.6G

Physical footprint: 4.8G
Physical footprint (peak): 5.6G

Physical footprint: 4.6G
Physical footprint (peak): 5.6G

Then 16 bits for _topology and _instancePrimvar
(11 bytes total, probably rounded to 12)

Physical footprint: 4.7G
Physical footprint (peak): 5.8G

Physical footprint: 4.6G
Physical footprint (peak): 5.6G

Physical footprint: 4.6G
Physical footprint (peak): 5.8G

Then 32 bits for _topology and _instancePrimvar
(15 bytes total, probably rounded to 16)
Physical footprint: 4.7G
Physical footprint (peak): 5.5G

Physical footprint: 4.8G
Physical footprint (peak): 5.5G

Physical footprint: 4.8G
Physical footprint (peak): 5.6G

It looks like this has a small impact on the overall memory size, but if there is a concern then 16 bits for these fields gives us enough headroom and shouldn't change the memory footprint.

I'll amend the PR to use 16 bits.

[spiffmon]

Thanks so much, @jonny-apple - that seems like a good choice, for now. I'll note that we can double the value of our money by using uint_16t for those two fields that we specifically want headroom with?

[drwave]

And to be clear - this came from a real bug we found with importing OBJ files that we overflowed how many geom subsets we needed to create import the data to USD - so this isn’t academic - it was a weird bug we ran into!

…

On Nov 19, 2022, at 5:03 PM, F. Sebastian (spiff) Grassia ***@***.***> wrote: Thanks so much, @jonny-apple <https://github.com/jonny-apple> - that seems like a good choice, for now. I'll note that we can double the value of our money by using uint_16t for those two fields that we specifically want headroom with? — Reply to this email directly, view it on GitHub <#2089 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM2AOQ532KCKBDLYNNBO6TWJF2G3ANCNFSM6AAAAAASACKY3Q>. You are receiving this because you are subscribed to this thread.