Adding geometry in VEX, and parallelism

   4575   6   0
User Avatar
Staff
4170 posts
Joined: Sept. 2007
Offline
I heard from someone that adding and creating geometry in VEX isn't done in parallel, and that all of the add* functions are run in serial.

I've been doing some small tests, both at home and work, and using the Grow Hairs example snippet on AttribWrangle. With 3,000,000 points, it takes between 26 and 30 seconds to finish on my MacBook Pro. However, the first chunk (the red part of the CPU graph image), is the only part that really runs in parallel, which seems to confirm what I'd heard.

Is it just how things are, or is there a way to add geometry in a more parallel-friendly way, reducing the amount of serial work that has to be done? i.e. only adding geometry at the beginning/end of some VEX code, or something like that

Thanks!

Attachments:
addgeom_cpu_graph.png (25.4 KB)

I'm o.d.d.
User Avatar
Member
7726 posts
Joined: July 2005
Offline
i.e. only adding geometry at the beginning/end of some VEX code, or something like that

As I understand it, that's already what is being done. You can create the geometry in parallel, do lots of work with it, and then when the shader is *finished*, the created geometry is collated/added serially. I haven't seen the example before, but does it do much besides create the geometry? If it does not, then you're going to see your bottleneck in the serial portion because you're not doing anything else that could have been done in parallel.

The other thought is how the performance differs on Linux vs OSX. Early on in the OSX builds, we had performance problems with the system synchronization primitives on OSX. I wonder if this has changed (for the better or worst).
User Avatar
Staff
4170 posts
Joined: Sept. 2007
Offline
Thanks Edward. Wow, you were right, much faster under Linux - 21 seconds.

The Grow Hairs example does some noise and jitter as it creates the hairs, though perhaps not enough to offset the cost of adding the geometry at the end, especially when working on so many points. Would you agree?

Here is the code (and the hip file, thought it's in the AttribWrangle Snippets menu):

vector dir = { 0, 1, 0 };
//vector dir = @N; // grow in normal direction
float len = 1.0;
int steps = 10;
float jitter = 0.1;
float seed = 0.12345;

vector pos = @P;
int pr = addprim(geoself(), “polyline”);

// Start the curve with our point
addvertex(geoself(), pr, @ptnum);
for (int i = 0; i < steps; i++)
{
pos += dir * len / steps;
pos += (vector(rand( @ptnum + seed )) - 0.5) * jitter;

// Clone our point to copy attributes
int pt = addpoint(geoself(), @ptnum);
// But write a new position
setpointattrib(geoself(), “P”, pt, pos);

// Connect the new point to our curve.
addvertex(geoself(), pr, pt);
seed += $PI;
}

Attachments:
grow_hairs_millions.hip (61.1 KB)
grow_hairs_snippet.png (80.2 KB)

I'm o.d.d.
User Avatar
Member
7726 posts
Joined: July 2005
Offline
goldleaf
much faster under Linux - 21 seconds.

This is on the same hardware right? If we take an average of your 26-30s to say 28s, then 28/21 = ~1.33x speed up. It's not like night and day but I guess still significant. The slowdown on OSX might also be due to using OSX's system allocator as well, compared to the jemalloc allocator that is used on Linux.

The Grow Hairs example does some noise and jitter as it creates the hairs, though perhaps not enough to offset the cost of adding the geometry at the end, especially when working on so many points.

You can try to make it do more work, like take the output of rand and then run through through another round of rand(). Do this like 100 times and see if there's a point where the parallel work exceeds the serial work.
User Avatar
Member
4189 posts
Joined: June 2012
Offline
Same hardware, set the sphere frequency to 5 - OsX10.9.3 vs Linux Mint 16

Aattribvop1 via Performance Monitor

OsX = 38.225
Linux = 35.795

~1.06 speedup.

Similar to Mantra test:
http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=30644&highlight=osX [sidefx.com]
User Avatar
Staff
4170 posts
Joined: Sept. 2007
Offline
edward
This is on the same hardware right?

Well, that would explain the time difference much better completely spaced that the Linux machine is much faster (3.4Ghz vs 2.4Ghz). I blame the 3-day weekend and too much food… Thanks Marty for running that on the same hardware.

And thanks for the clarifications Edward, it's helped these make more sense; particularly, how adding geometry affects performance.

Cheers!
I'm o.d.d.
User Avatar
Member
4523 posts
Joined: Feb. 2012
Offline
On a related note is it possible to really create geometry in parallel? I imagine this would be really tricky, but maybe there are actually established ways to do this?
Senior FX TD @ Industrial Light & Magic
Get to the NEXT level in Houdini & VEX with Pragmatic VEX! [www.pragmatic-vfx.com]

youtube.com/@pragmaticvfx | patreon.com/animatrix | pragmaticvfx.gumroad.com
  • Quick Links