-
Notifications
You must be signed in to change notification settings - Fork 56
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
Easily switch nodes to use workers #3
Comments
Can you repeat what you"re requesting in more detail? What is the problem being solved? Typically performance feature enhancements need a target goal because workers typically makes code slower.. but can use more of the cpu"s threads. |
The goal is indeed to improve performance. It could be any of the following situations:
My current thinking is that an easy way for a user to configure which nodes should be sent to a worker would be to wrap them inside a subnet, toggle a parameter
You could then have middle to large scenes have different groups of nodes in different subnets, each using a different CPUs. This would make it easy to use as many thread as possible. In order to test this, you could create any node tree with a large input geometry. Or you could also test with the sop/attribTransfer node, which can take a long time by itself when both inputs are large geometries, as each point of the first input will check each point of the second input. And note that my comment above mentions "the current worker setup", but that"s is not existing anymore, as I have not worked on it since then. My knowledge of workers being pretty shallow, this would need to be started from scratch. |
Polish the current worker setup. A subnetwork whose nodes are sent to a worker should be able to only copy/shader an attribute buffer (as opposed to transfer a whole geometry, which can be very slow)
The text was updated successfully, but these errors were encountered: