Should you use Wrangle SOPs whenever possible?

[goldleaf]

Thanks johner!

[Guest tar]

The kernel file is in $HFS/houdini/ocl/sim, so black (grey?) magic:

$hconfig -h HOUDINI_OCL_PATH
HOUDINI_OCL_PATH
The search path for OpenCL kernels. Setting this path will override the
default path of $HOUDINI_PATH/ocl/.
[/CODE]

Hey Joner, have you had a chance to look at implementing openCl for OsX10.9?

[ikarus]

How much performance improvement does OpenCL provide though? If it's 30%, I shouldn't go crazy about it

Is there any chance of having the Gas Wrangle to support OpenCL completely?

Opencl uses it's own language for kernel's, independent of vex. You would need a intermediary code interpreter.

[johner]

How much performance improvement does OpenCL provide though? If it's 30%, I shouldn't go crazy about it

OpenCL can be a few times faster on the Intel CPU driver than the regular CPU path (even more on the GPU), but that's not the main reason to write an OpenCL version of an existing GasFieldVOP or Wrangle. You want an OpenCL version so that if you're using the OpenCL path for the Smoke or Pyro solver, you don't have to transfer all of your data from OpenCL memory to regular CPU memory before running VEX on it, which only runs on the CPU. That transfer is really expensive on the GPU, and even a bit expensive on the CPU.

So a GasFieldWrangle will work fine in the middle of an OpenCL sim, you're just paying for a lot of needless memory copying when you could be doing the work faster directly in OpenCL, assuming you're OK hand-porting the VEX to OpenCL once you've got the logic figured out.

Hey Joner, have you had a chance to look at implementing openCl for OsX10.9?

We haven't I'm afraid. IIRC, even when we could get them running, their previous drivers were fairly disappointing for performance in the Smoke / Pyro solvers, and we had all kinds of stability problems. But maybe they've gotten better with this release.

[magneto]

Thanks ikraus & johner. But do you need to install vcc, etc just like when you want to use inlinecpp? Because I find that not as portable.

I don't mind hand porting to OpenCL. Is there a chance of having OpenCL Wrangle or something similar?

[anim]

you apparently don't need anything more than standard houdini install

[johner]

Thanks ikraus & johner. But do you need to install vcc, etc just like when you want to use inlinecpp? Because I find that not as portable.

As Tomas said, you don't need a compiler. Every OpenCL driver has a runtime compiler, which is why we can ship the kernels as source code and they will compile for the GPU or CPU depending on the driver.

I don't mind hand porting to OpenCL. Is there a chance of having OpenCL Wrangle or something similar?

An OpenCL Wrangle is possible, though unlikely. At the moment I don't believe you can even use a file embedded in an OTL; it has to be on the filesystem somewhere.

We're not advocating widespread use of OpenCL in lieu of VEX or anything. But if a studio has an internal toolset that contains some custom VEX field manipulation, and they want to take advantage of the OpenCL path for Smoke and Pyro, then it's worth looking at porting that code to an OpenCL DOP just to have a pure OpenCL pipeline. That's one of the reasons the OpenCL DOP exists; we needed some of the GasFieldVOP based operators in the Pyro pipeline available from OpenCL.

[magneto]

Thanks I see it now. For OpenCL Wrangle, maybe at each cook for the first time and each time the file is changed, maybe it would save it to a temp location on disk and then compile that? I don't know if this is bad.

Is it possible to completely convert Pyro, Smoke, Fluids into OpenCL? I assume it's not because of the type of operations? If so, how can someone know something is gonna bottleneck the sim if you use OpenCL somewhere in the DOP tree? Memory copying, etc.

Also these OpenCL toggles in certain nodes seem like too much micro management. Would you not want to turn all OpenCL toggles for the entire sim? I don't know if that would be better or worse.

I am not familiar with this so I might be very wrong

[Guest tar]

This could be of interest: OpenCL2.0 spec is finalised.

https://www.khronos.org/news/press/khronos-finalizes-opencl-2.0-specification-for-heterogeneous-computing