Since VEX is a SIMD architecture and GPUs implement SIMD how much effort is going into implementing VEX primitives generally for GPU SIMD computation?

I am aware that COPS utilize GPU processing but it is not clear how much.

If the answer is this is an active area of Houdini development, my second question is will there be VEX user call outs to write GPU SIMD kernels directly?

If the answer is this is not an active area of Houdini development, my question is why not since VEX is SIMD and GPUs are SIMD?

VR

Lars

Some years old but good background, my bold.

What is VEX?
VEX is a shading language similar to the Renderman Shading Language (RSL). It is a software interpreted language so provides the flexibility of scripting. However, it also has an implicitly SIMD evaluation approach that amortizes interpretation overhead.
VEX has moved well beyond just shading, however. It is used as the workhorse for simulation and geometry processing.
Often it is compared to hardware shading languages, such as GLSL, OpenCL, CUDA, or Cg. This is a bit misleading. If they were truly similar, multithreading VEX would be trivial. And moving it onto the GPU would likewise be a manageable task. We will talk more about the difficulties VEX poses later

http://www.multithreadingandvfx.org/course_notes/2015/houdini_threading.pdf [multithreadingandvfx.org]

This is interesting, I have to understand this more. I have extensive experience with both GPU and massively parallel systems of all forms. Here is a published paper the US National Security Agency Super Computing Research Center asked me to write on a supercomputing machine in a brief case I built in a two months. Much better than their stuff at the time.

The machine functions as all GPUs based systems function today but with raw optoelectronic interconnect with passive diffraction grating add/drop multiplexors. Was 1000 times faster than the fastest supercomputer at the time. The design of the machine is still valid but my focus is automating animation.

http://fvg.com/optical-computing.html [fvg.com]

Thanks again for your insights. This feedback is very valuable to me.

VR

Lars

wow your paper is even older then i expected! i heard something like that in the end of the 90's from the CCC hacker convention.

nice to see you here!

if you are already familiar with writing GPU kernels, you will probably find some use for Gas OpenCL DOP which can modify Fields or Geometry Attributes in parallel on GPU, so instead of writing VEX snippet you'll write CL snippet

Not to burst too many bubbles, but this seems a bit like “Toronto is a city, and Las Vegas is a city, so why not have a CN Tower in Las Vegas?” In concept, it may be possible, but it'd be a gigantic amount of work, probably way more work than the original, it'd have to be done from scratch, and it probably won't be worth it to go to Las Vegas just to see a copy of the CN Tower there; you'd need to be able to do other stuff while you're there, else it'd be a huge disappointment.

As an example of a complication, in VEX, you can request parameter values from any node, or topology data from any SOP's geometry, meaning that if you want VEX on the GPU, either you need to ban those operations or send all of that data to the GPU, which would mean that it could be significantly slower than doing it on the CPU unless you're doing a ton of computation. VEX has regular expression parsing functions, so you either need to ban them or port all of those to the GPU. VEX has functions that can find the closest point on a detail or send a ray into a detail, supporting most of Houdini's primitives, including NURBS surfaces, curves, metaballs, etc, meaning that all of that would need to be ported to the GPU. VEX has functions that queue up geometry modification operations to be done after the VEX part is done, so there'd be no possible benefit for those operations.

In a nutshell, getting *every*thing on the GPU would take an effort comparable to re-writing all of VEX and all of the code that it relies on, and the overhead due to sending all of the data needed may mean that it'd be worse off before it even began any real computation on the GPU. I wouldn't predict that it's never going to happen, but it'd almost certainly have to be a very strict subset of current VEX functionality, which may be perfectly acceptable for some things.

ndickson
In a nutshell, getting *every*thing on the GPU would take an effort comparable to re-writing all of VEX …

I completely agree, which is why we must take an asymmetric approach with Mathematica Kernels connected to Houdini to greatly increase Houdini's functionality toward the path of full automation and greatly increased performance and efficiency. Houdini is excellent technology, I am making it better.

First rule in my asymmetric thinking play book: why build one when you can have two (VEX, Python, Mathematica)? For example:

Did you know Houdini can now do facial recognition dynamic scanning edge detection that runs off GPUs and then turn that into geometry? Here is an example of what Houdini can do now in the attached image that was originally drawn by hand, imported into Houdini and scanned using a new mathematica Houdini node. I changed the algorithm today based upon feedback and requirements asked for by DASD. I also changed the algorithm to use as many images as one cares to use and automatically subdivide based on modeling and animation requirements, based on DASD feedback.

See attached multiple pass, multiple resolution facial edge detection image samples. Wrinkles, no problem.

More information here: http://fvg.com/technology.html [fvg.com]

Unfortunately generating a billion polygons as DASD suggested was done broke the mesh somewhere on the round trip from Houdini to Mathematica and back again, so I have to fix a bug in my Mathematica code or adjust the code so Houdini can handle the polygon count before I upload a Houdini screen shot. I still have some work to do. Time for my milk and cookies. I will automate Houdini UV creation for multiple geometries as per DASD request using Heat Seeker algorithm.

VR

Lars

tamte
if you are already familiar with writing GPU kernels, you will probably find some use for Gas OpenCL DOP which can modify Fields or Geometry Attributes in parallel on GPU, so instead of writing VEX snippet you'll write CL snippet

With mathematica code density is 1000 to 1 in conventional languages, notwithstanding tiny GPU kernels. The mathematica gpu codes I do are all symbolic so a Houdini node specification is sent to Mathematica and the GPU kernel is automatically generated. So the answer is yes, that can be done easily. Great idea!

VR

Lars

mandrake0
wow your paper is even older then i expected! i heard something like that in the end of the 90's from the CCC hacker convention.

nice to see you here!

Thanks! Great to be here.

Finally working on my dream project I first conceived in the 1980s. The problem has always been I am constantly trying to incorporate 3D work into everything I do. Like when I was designing molecules for DuPont they were saying how did you do this (lol)? http://fvg.com/science-of-the-unseen.html [fvg.com] and here http://fvg.com/science.html [fvg.com] both microscopic spacetime continuous subatomic models of molecular structure based upon boson string theoretic representation of matter: http://fvg.com/gauge-chemistry.html [fvg.com]

Interestingly the work in differential geometry I have done is directly applicable to automated generation of model geometry from facial recognition.

VR

Lars

Just a progress update. Using the automation technology I am developing that is connected to and drives Houdini I am now able to generate a mesh with good detail from a single image. This took ten seconds to generate from the drawn image. I still have a lot to do but progress is very good. Link that discusses technology I am developing is here: http://fvg.com/technology.html [fvg.com]

VR

Lars