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

[enhancement] GPU Acceleration #9

Open
Asten-Valentinus opened this issue Jul 4, 2024 · 6 comments
Open

[enhancement] GPU Acceleration #9

Asten-Valentinus opened this issue Jul 4, 2024 · 6 comments

Comments

@Asten-Valentinus
Copy link

Currently, it goes quite slow when using on large node trees.
I think that to help with this perhaps GPU acceleration should be implemented.

@semagnum
Copy link
Contributor

Do you have a specific implementation in mind? Blender's Python module is pretty limited in what it offers for hardware acceleration. There are separate Python libraries that can do this, but that would require bundling them with the add-on.

If there's specific operations you're thinking of that are slow, we could look into optimizing them. Might be able to do a lot without needing to add external Python libraries.

@Asten-Valentinus
Copy link
Author

I noticed the problem with the 'Arrange Nodes' feature, although I see that it also applies to the 'Relax Brush'.

This is an example of a node tree I tried using this on (for reference of complexity):
Screenshot 2024-07-16 132212

@semagnum
Copy link
Contributor

Thanks for that. That means it's more about the underlying code than the operators/modals themselves. The code requires nodes checking for collisions with other nodes, so a lot of the speed complexity is around number of (selected) nodes.

With geometry nodes, I've noticed the modal can trigger a viewport update, so if the mesh's geometry nodes and other modifiers are enabled, it can be drastically slower in my experience. Is it faster when these modifiers are turned off?

@Asten-Valentinus
Copy link
Author

I tried what you suggested, and it does not speed up the process.

@semagnum
Copy link
Contributor

Okay. I mean it's slow for me too; usually I workaround this by running only on selected (which usually works better with frames anyway).

Before we could even consider hardware acceleration, we'd have to refactor the code to support it. That would likely mean doing all the calculations with numpy. That may be fast enough to not need further acceleration.

@Asten-Valentinus
Copy link
Author

Okay. I mean it's slow for me too; usually I workaround this by running only on selected (which usually works better with frames anyway).

Before we could even consider hardware acceleration, we'd have to refactor the code to support it. That would likely mean doing all the calculations with numpy. That may be fast enough to not need further acceleration.

Sounds good. As long as it's optimized I'm happy.

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

2 participants