Mario Marengo
Mario Marengo
About Me
Expertise
Not Specified
Location
Not Specified
Website
Connect
Recent Forum Posts
[HDK] CVEX Woes With HtoA Sept. 11, 2022, 1:36 p.m.
-- SOLVED --
There was a "placement new" operation in the code which used an Arnold allocator. This interfered with Houdini's own allocation strategy and is explicitly warned against in the HDK docs:
Serves me right for being lazy and copy-pasting someone else's code!
There was a "placement new" operation in the code which used an Arnold allocator. This interfered with Houdini's own allocation strategy and is explicitly warned against in the HDK docs:
TFM
Custom Allocators
Houdini is built with special custom allocator libraries that override the default allocation routines (eg. malloc, free, etc.). As such any code you build or link into HDK plugins cannot use their own such libraries such as tbbmalloc_proxy. If you do, then conflicts and crashes can occur as a result.
Serves me right for being lazy and copy-pasting someone else's code!
[HDK] CVEX Woes With HtoA Sept. 10, 2022, 3:37 p.m.
Hi all,
I've been hitting a runtime (as opposed to compile-time) issue with a custom Arnold plugin (VOP shadeop) that calls a CVEX function.
I'm building against a bunch of HtoA/Hou versions, but the issue pops up in all of them, so for this post's sake, I'll pick: HtoA-6.1.3.1 (Arnold-7.1.3.0) and Houdini-19.0.657, using gcc-9 and hcustom's default -std=c++17 in this case (built in CentOS-7 using SCL devtoolset-9).
I'm linking against
The problem happens at runtime, and exactly at the point when
So it seems TBB-related, and taking a closer look at
Looking into the provenance of the signature
So the only thing left that I can think of to look at are the 3
Just in case, and grasping at straws at this point, I built my own
Does any of this ring any bells for anyone here?
Thanks in advance for any pointers!
I've been hitting a runtime (as opposed to compile-time) issue with a custom Arnold plugin (VOP shadeop) that calls a CVEX function.
I'm building against a bunch of HtoA/Hou versions, but the issue pops up in all of them, so for this post's sake, I'll pick: HtoA-6.1.3.1 (Arnold-7.1.3.0) and Houdini-19.0.657, using gcc-9 and hcustom's default -std=c++17 in this case (built in CentOS-7 using SCL devtoolset-9).
I'm linking against
-lHoudiniUT -laifrom the Houdini and HtoA installations respectively. The plugin compiles/links without errors and ldd -ron the resultant .sotracks no missing symbols or any other dependency issues.The problem happens at runtime, and exactly at the point when
CVEX_ContextT<VEX_32>.run()is called (already verified that the context is valid, one per thread, and that the function is loaded successfully, i.e: no VEX errors before that call). At this point, the plugin crashes with the following output (calling kickdirectly on an .assfile for this test):... 00:00:00 224MB | starting 20 bucket workers of size 64x64 ... UT_TBBProxy: WARNING: Failed to bind to TBB - TBBPROXY_CreateTaskArena() UT_TBBProxy: WARNING: Failed to bind to TBB - TBBPROXY_DestroyTaskArena() UT_TBBProxy: WARNING: Failed to bind to TBB - TBBPROXY_TaskArenaExecute() UT_TBBProxy: WARNING: Failed to bind to TBB - TBBPROXY_ScalableAllocationCommand() UT_TBBProxy: WARNING: Failed to bind to TBB - TBBPROXY_InitializeTaskArena() kick: symbol lookup error: <houdini19.0.657>/dsolib/libpxr_plug.so: undefined symbol: _ZN3tbb10interface78internal20isolate_within_arenaERNS1_13delegate_baseEl <crash> $ c++filt _ZN3tbb10interface78internal20isolate_within_arenaERNS1_13delegate_baseEl tbb::interface7::internal::isolate_within_arena(tbb::interface7::internal::delegate_base&, long) $
So it seems TBB-related, and taking a closer look at
libHoudiniUT.soshows that it contains the "Failed to bind to TBB"string, though the code that issues the warning is not exposed in the HDK headers, but regardless, I believe the "undefined symbol..." error is the root cause from which all those "failure to bind" warnings cascade. Looking into the provenance of the signature
tbb::interface7::internal::isolate_within_arena(tbb::interface7::internal::delegate_base&, long), which was demangled by c++filtabove, I end up at the header <tbb/task_group.h>(in $HDK/include), which only defines it when #if TBB_PREVIEW_ISOLATED_TASK_GROUP && __TBB_TASK_ISOLATION. Okay, so then I took a look at hcustom's compile flags and noticed they include -DTBB_PREVIEW_ISOLATED_TASK_GROUP, so the compile side of that seems to be taken care of (I added both of those in my module and explicitly via $HCUSTOM_CFLAGSjust in case, but no improvement).So the only thing left that I can think of to look at are the 3
tbblibraries (from ${HFS}/dsolib) that we're linking against (indirectly via -lHoudiniUT), but when I check for the (demangled) public symbols, I see that the required signature is reported as available:$ nm -g libtbb.so.2 | c++filt | grep -i isolate_within_arena 00000000000220a0 T tbb::interface7::internal::isolate_within_arena(tbb::interface7::internal::delegate_base&, long)
TBB-2019_U9making sure that TBB_PREVIEW_ISOLATED_TASK_GROUP && __TBB_TASK_ISOLATIONwere both defined, then linked against that instead of the HDK-supplied tbb, but the runtime "undefined symbol..." error persists <sigh>. Running out of ideas here...Does any of this ring any bells for anyone here?
Thanks in advance for any pointers!
Camera Projection and NDC April 26, 2012, 12:13 p.m.
jason_iversen
I really do wish there was some deeper support for camera transforms within Houdini. We at R+H have obviously written our own formulas like the one above, but a good encapsulated camera definition and functions to transform by them are sorely needed.
Currently you're going to account for Window Size, Crops and Pixel Aspect yourself too; all three of these are commonly used in an FX pipeline for oversized camera projections (to account for lens warping) and such.
Completely agree.
In fact, I would love to not have to look at another NDC matrix ever again.
