is there a list of commands which take advantage of multithreading? i read that contour uses multithreading i also found a list for components for grasshopper here while most likely not every command might need multithreading per se i certainly would believe there are quite some commands which could benefit from it. for instance quadremesh, heightfield patch etc
We do not have a list of commands that use multiple threads
_TestEnableMultiThreadedMeshing
1 Like
could you name a few more? i had the feeling quadremesh was discussed but i am not certain.
Quadremesh is not multi-threaded, at least in my case.
â
or at least it didnât use more than 4 threads.
although I appreciate the ability to use all of my available cores to run things faster. many geometric algorithms are sequential which cannot be done in a parallel way.
Iâd appreciate a faster cleaner code over more complex one.
1 Like
i would assume that every geometry can be divided into an infinite amount of parts. each thread gets a chunk and the result added together. or which algorithms would you have in mind?
Thatâs not how it works at all.
2 Likes
Probably works on meshes. Since they have a data structure (vertex, edge, face, normals) that can be sorted into a parallel algorithm. NURBS is way more complex type of geometry. The only way I can think of is probably doing a parallel function on multiple objects like planar surf on multiple closed curves or calculating the volume on multiple selected solids.
Thatâs why literally all rendering engines (including Rhinoâ shaded mode) build a mesh geometry first before shading or rendering.
No itâs that all rendering systems work on meshes, directly rendering NURBS is a nerdy academic niche thing.
ReduceMesh takes advantage of it nicely.
1 Like
Direct rendering of NURBS could be parallelized. The reason meshes with triangular or bi-linear quads are preferred for rendering is evaluation of the location and normal of such mesh faces is much faster (many fewer operations) than evaluation of NURBS surfaces.
2 Likes
would you be so kind to elaborate a bit more?
without being nerdy we would not even be typing on our computers. here some info claiming that avoiding some steps in the usual process due to a direct conversion of nurbs leads to a magnitudal speed increase.
maybe and as stated in the mean time, nurbs get converted to meshes before being even displayed, can we call that discretization? so since discretization happens anyway, why not using this to split up the geometry and voila multithread galore. also even if single surfaces can not be split easily (whatever easy means), discretized without applying a mesh transformation, at least polysurfaces could be.
well, this recent post claims that anything working on a gpu has no need of parallelizing anyway since it all gets (magically) thrown into multi core gpu, i assume as meshes already but even if, bringing that back to general multithreading if that is correct what you say that could be utilized to cpu multithread nurbs maybe.
Itâs the other way around. To utilize a GPU there has to be parallel code. For graphics that parallel code will usually be in the Open GL, etc routines which use the GPU, which means the person creating the graphics software which uses those routines does not have to create parallel code.
Not really, Iâve tried to explain too many times already! You canât just arbitrarily split up a Rhino model to parallelize anything, no. Most âcontent creationâ tasks are a linear this happens then that then that, itâs not even possible to parallelize. 9 women canât make a baby in 1 month! Even if it is theoretically possible to parallelize something it has to actually be worth the trouble of splitting the problem into chunks for the threads, making sure the threads donât trip over each other and deadlock the program or risk the integrity of the Rhino database, waiting on them all to finish, and collating the results. Otherwise itâll be a lot slower!
2 Likes
If few tasks will have to modify same data simultaneously, then parallelism is not thread safe and will lead to corrupted data.
If job is to modify different data (or clearly defined parts of data which do not rely on each other) then parrallelism may be a solution, if caused overhead will not consume its benefit.
1 Like
right, so meshes as in display/rendermesh is processed on the gpu? what i meant if that is true that the meshes could be used to evaluate the tasks multithread instead of the nurbs non multithread in that case even on the gpu. maybe for some tasks it could be good enough also when set to a high mesh resolution the outcome would potentially be within tolerance.
I think something similar could already be used in mesh modellers. Rhino currently is not a mesh modeller.
The GPU uses the 3D display/render mesh and other information to calculate the RGB or equivalent values for each pixel of the 2D display. These calculations need to be redone each time the display is changed.
A GPU can be used some other types of calculations but those tasks require task specific code which is GPU hardware dependent. That code is different from the code used for display calculations.
Depending on the details the added overhead of using the GPU may result in a particular task taking more time using the GPU than using the CPU.
Rhino currently uses âunder the hoodâ analysis meshes which are created from NURBS and SubD surfaces for use by surface analysis commands. These meshes are automatically refined so that the results will be within the acceptable tolerance. I donât know if any of these calculations using analysis meshes are currently multi-threaded.
They are but not officially supported. You can run _testmultithreadedmeshing and the process of creating rendermeshes becomes much faster.(at least on my system)
1 Like