HOT 1.0 rc4 multithreading issue

[warioh]

Hi,

I've got issue when rendering with HOT 1.0 rc4 in mantra with multithreaded mode. I've build the sources on opensuse 10.3 (64 bits) with gcc 4.1.3 and houdini 9.5.170. The sop works perfectly and is really fast (great job!). When using ocean_eval in a displacement shader, in multithreaded render, I've got some missing frames. There are different cases:

* I can get a backtrace (error occuring during alloc calls, alloc_disp_y() for example)

* I get a mantra '11' exit error code

* mantra seems to fall in an infinite loop

When rendering in single threaded mode I get no error. I just wanted to know if it's coming from my build or it's a known issue.

Thanks!

[aracid]

Hey man

I get the same issue and it seems to be the issue everyone here experiences,

Hopefully someone else can show me some hidden button that fixes this

[edward]

er, is ocean_eval() thread-safe?

[eloop]

It hasn't been to date, but it should be in the upcoming release. Before 9.0 it wasn't such an issue ... Mac fans will be happy to hear it now works on OSX as well as Linux (win32 not tested yet). Also for linux and osx the 3rd party dependencies are included and compiled statically, so there is no need to install shared libraries.

For the adventurous here is the latest src -

http://sf.anu.edu.au/~drw900/houdini/ocean...c_1.0rc5.tar.gz

To build on linux -

> tar xvfz http://sf.anu.edu.au/~drw900/houdini/ocean...c_1.0rc5.tar.gz

> cd hot/src/3rdparty

> ./build_linux.sh

> cd ..

> ./compile_linux.sh

On OSX

> tar xvfz http://sf.anu.edu.au/~drw900/houdini/ocean...c_1.0rc5.tar.gz

> cd hot/src/3rdparty

> ./build_osx.sh

> cd ..

> ./compile_osx.sh

Before trying to compile the above make sure that you can at least compile SOP_Star.C from the HDK examples (see http://odforce.net/wiki/index.php/HDK for help). So you should be able to do the following

> hcustom SOP_Star.C

All the examples should work properly including vop_displace.hip. I'd appreciate people give it a try and tell me how they fare. If everything looks ok this will probably become released as v1.0 as soon as it compiles on win32/64 and the docs are updated.

-Drew

er, is ocean_eval() thread-safe?

[warioh]

I've replaced the loki-lib threading model used by the ocean toolkit (SingleThreaded replaced by ClassLevelLockable) and it seems to have fixed the multithreading issue (I'm on linux 64 bits, opensuse). This way the initialization is done with locks (multiple threads but serialized) so no multi-threading benefit here then the render uses ocean_eval in a multi-threaded way.

Again: great tool

[eloop]

That's one of the changes in 1.0rc5 above, getting it right is subtle...

-Drew

I've replaced the loki-lib threading model used by the ocean toolkit (SingleThreaded replaced by ClassLevelLockable) and it seems to have fixed the multithreading issue (I'm on linux 64 bits, opensuse). This way the initialization is done with locks (multiple threads but serialized) so no multi-threading benefit here then the render uses ocean_eval in a multi-threaded way.

Again: great tool