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

Optimizations to mikktspace.c #93615

Open
wants to merge 12 commits into
base: master
Choose a base branch
from
Open

Conversation

Sluggernot
Copy link

Created in response to: #93587
Large glb file (778 MB) would hang, crash or load after extremely long time. This first set of optimizations focuses on sending SVec3 objects by reference instead of by value. Local tests in debug mode caused one iteration of GenerateSharedVerticesIndexList to go from 552ms to 470ms, on average. Unsure of the performance gains on release mode.

Created in response to: godotengine#93587
Large glb file (778 MB) would hang, crash or load after extremely long time. This first set of optimizations focuses on sending SVec3 objects by reference instead of by value. Local tests in debug mode caused one iteration of GenerateSharedVerticesIndexList to go from 552ms to 470ms, on average. Unsure of the performance gains on release mode.
Created in response to: godotengine#93587
Large glb file (778 MB) would hang, crash or load after extremely long time. This first set of optimizations focuses on sending SVec3 objects by reference instead of by value. Local tests in debug mode caused one iteration of GenerateSharedVerticesIndexList to go from 552ms to 470ms, on average. Unsure of the performance gains on release mode.
@Sluggernot Sluggernot requested a review from a team as a code owner June 26, 2024 04:02
@Sluggernot
Copy link
Author

First time using Github like this. Hopefully this isn't too bad.

@AThousandShips AThousandShips requested a review from a team June 26, 2024 08:21
@AThousandShips
Copy link
Member

These changes must be added as a patch file in thirdparty/misc/patches as they are third party sources and can be updated upstream, losing our changes

@Mickeon
Copy link
Contributor

Mickeon commented Jun 26, 2024

If it can be done it would be worth considering reporting this issue to the third-party, as well.

@AThousandShips
Copy link
Member

The patch would help a lot with that as well

@akien-mga
Copy link
Member

For the record, upstream is now https://github.com/mmikk/MikkTSpace and no longer just a page on the (old, and now 404'ing) Blender wiki.

But before proposing this upstream, this should definitely be benchmarked in a production build, debug build times aren't super useful aside from seeing the impact on debugging usability for engine devs.

@Sluggernot
Copy link
Author

Is there a standard benchmarking system of any kind? Any info would be helpful.
The last changes to that repo is 4 years ago but I'll attempt a pull request.
Can I propose to replace these two files with a cpp implementation?

@fire
Copy link
Member

fire commented Jun 26, 2024

Can you try to salvage #83648

@akien-mga
Copy link
Member

Is there a standard benchmarking system of any kind? Any info would be helpful. The last changes to that repo is 4 years ago but I'll attempt a pull request. Can I propose to replace these two files with a cpp implementation?

This is reference code for the implementation used by Blender, which is in C.
So I don't think porting to C++ would be welcome, though a separate (duplicated) reference implementation in C++ may be ok, you can ask if they're interested.

This is also not a library that changed at all in the past 10 years, so it's not a problem if we hard fork it to optimize it for Godot's needs.

@akien-mga akien-mga modified the milestones: 4.3, 4.4, 4.x Jun 26, 2024
@Sluggernot
Copy link
Author

mmikk/MikkTSpace#5 a 5 month old Issue where someone is asking for 2 '=' to be added to correct some sorting. (I will say I haven't vetted the request but it hasn't been commented on either.) Confidence is low. But, I'm not here to talk trash about a legacy/third-party lib. It was amazing until we want to load larger files.

What's the real solution?
My findings (which can be flawed) are showing the major bottlenecks being sqrt calculation with Length calls and calls to VScale. VScale has nothing going on computationally. The issue must be copy elision. Creating an SVec3 and returning a copy. C doesn't allow me to make overloaded constructors for structs (as far as I can see. I'm a C++ guy way more than C). I'm looking at other ways to get around this but open to suggestions.

@akien-mga
Copy link
Member

akien-mga commented Jun 26, 2024

I think it's fine modifying this lib downstream for our needs, it's a single file and not one that gets updated frequently. If porting to C++ lets us use features that improve performance in Godot's context, then I don't see a reason not to do it.

There is still lots of room for improvement but with my local tests I am down to 322ms from 552ms before my other proposed changes. The new major bottlenecks are QuickSortEdges and mikktGetPosition.
Issues: I am temporarily unable to build a release build, locally. I will look into this to get real world numbers.
I don't know how copyright works in this instance. I would happily keep the original copyright and hand these changes over.
I left a large comment in surface_tool.h about how to handle this side-change to the use of these new files without removing the old mikktspace.
@Sluggernot
Copy link
Author

I have so much to learn about git.
I have created a new commit that isn't a new pull request... It is an initial C++ implementation of mikktspace
There are several options to consider before accepting this change. I will try to get real world timings for these changes but I wanted to get some opinions from you guys before I dive further and spend time on something that may be impossible to actually complete.
While writing this I see I have a lot of fails. Looks like linting errors.

The error is ambiguous and oddly seemed to point the order in which I included two files. I need more verbosity or I just missed the description.
@fire
Copy link
Member

fire commented Jun 26, 2024

I would recommend getting timing 2-3 times on the #93587.

@Calinou has a benchmarking server we can use too!

@fire
Copy link
Member

fire commented Jun 26, 2024

I've had good experiences writing doctest unit tests for these things complicated things, it's not a requirement for merging, but wanted to mention.

@Calinou
Copy link
Member

Calinou commented Jun 26, 2024

I would recommend getting timing 2-3 times on the #93587.

Note that you can get Godot to print the time taken to import each resource by starting it with --verbose from the terminal, then looking at terminal output after each file is done importing.

Make sure to remove the .godot/ folder between each test so that everything is reimported.

@fire
Copy link
Member

fire commented Jun 27, 2024

  • benchmarked in a production build
  • benchmarked using the test cases (like linked issues)
  • optional unit tests

I was in search of every possible way to improve load times (of glb files in my case) and created this monstrosity of a set of changes. Do not allow this change to go through. I just wanted to preserve this set of changes for personal reasons.
@Sluggernot Sluggernot requested a review from a team as a code owner June 27, 2024 21:45
@Sluggernot
Copy link
Author

zeux/meshoptimizer#713

Hashing out some potential results with the owner of a potentially huge fix.

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

Successfully merging this pull request may close these issues.

None yet

6 participants