SciVis Structured Volume Crashing

[StasJ]

In ospTutorial.cpp, replace the example triangle mesh with the following:

int s = 64;
vector<float> data(s*s*s, 0);
ospray::cpp::Volume volume("structured_volume");
volume.setParam("voxelData", ospray::cpp::Data(data));
volume.setParam("voxelType", (int)OSP_FLOAT);
volume.setParam("dimensions", vec3i(s, s, s));
volume.commit();

ospray::cpp::TransferFunction tf("piecewise_linear");
tf.setParam("valueRange", vec2f(0, 1));
tf.setParam("color", ospray::cpp::Data(vector<vec3f>{{1,0,0}, {0,0,1}}));
tf.setParam("opacity", ospray::cpp::Data(vector<float>{0, 1}));
tf.commit();

ospray::cpp::VolumetricModel volumeModel(volume);
volumeModel.setParam("transferFunction", tf);
volumeModel.commit();

Then instead of adding the triangle mesh to the group, add the volumeModel:

group.setParam("volume", ospray::cpp::Data(volumeModel));

Upon running, the program will crash with the following output:

[openvkl] GridAcceleratorIterator required ISPC object size = 896, allocated size = 448

OPENVKL ERROR [1]: GridAcceleratorIterator has insufficient ISPC storage

This was tested on macOS Mojave using the latest 2.0x development build.

[jeffamstutz]

I think this is a VKL problem, but I can look into it (the lead developer, @gregjohnson, is on vacation right now).

@timrowley have you seen this before?

[jeffamstutz]

After having a look at the VKL code history, it looks like the size numbers (allocated size = 448 specifically) appear to be stale, even prior to the official v0.7.0 VKL release. Does a clean build of the VKL alpha tag (or later) fix this for you?

[jeffamstutz]

The correct values that should be used are defined here in VKL, where the values you appear to be using are from an older version.

[StasJ]

I changed openVKL to the devel branch and rebuilt everything, but I run into the same error.

[paulmelis]

Just chiming in here, I tried modifying ospTutorial.cpp in the way you suggested, but don't get the error. But this is on Linux.

[jeffamstutz]

I tried the same thing and was unable to reproduce.

[StasJ]

I rebuilt everything from scratch from the latest development branches and I got the same result as before. I've attached my ospTutorial.cpp just in case.

ospTutorial.cpp.zip

[timrowley]

I just built with the latest development branches and your ospTutorial.cpp and it ran fine. Could you check if you might have LD_LIBRARY_PATH set pointing to some old directory?

[StasJ]

I ran dtruss -t open ./tutorial which gave the following output:

dtrace: system integrity protection is on, some features will not be available
SYSCALL(args)        = return
open("/dev/dtracehelper\0", 0x2, 0xFFFFFFFFE8D710E0)         = 3 0
open("/Users/stasj/Developer/ospray2/opt/install/lib/libospray_module_ispc.dylib\0", 0x0, 0x0)       = 3 0
open("/Users/stasj/Developer/ospray2/opt/install/lib/libopenvkl_module_ispc_driver.dylib\0", 0x0, 0x0)       = 3 0
open("/usr/local/opt/embree/lib/libembree3.3.dylib\0", 0x0, 0x0)         = 3 0
open("/Users/stasj/Developer/ospray2/opt/install/lib/libopenvkl.dylib\0", 0x0, 0x0)      = 3 0

I confirmed that I do not have LD_LIBRARY_PATH set.

The linker command is:

c++  -g -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -mmacosx-version-min=10.14 -Wl,-search_paths_first -Wl,-headerpad_max_install_names  CMakeFiles/tutorial.dir/ospTutorial.cpp.o  -o tutorial -Wl,-rpath,/Users/stasj/Developer/ospray2/opt/install/lib /Users/stasj/Developer/ospray2/opt/install/lib/libospray.2.0.0.dylib /Users/stasj/Developer/ospray2/opt/install/lib/libospcommon.dylib /usr/local/lib/libtbb.dylib /usr/local/lib/libtbbmalloc.dylib

All of the above paths are correct (as in they reference the most recent devel builds). Embree and TBB are installed with homebrew at the versions below:

TBB: 2019_U9
Embree: 3.6.1

The ISPC version used is as follows:

Intel(r) SPMD Program Compiler (ispc), 1.12.0 (build commit 2a3fc60c1c60008d @ 20190815, LLVM 8.0.0)

[timrowley]

Could you run vklTests "SIMD*" in your vkl build? Trying to narrow down what might be happening.

[StasJ]

I got the following output:

./vklTests "SIMD*"
Filters: SIMD*

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vklTests is a Catch v2.7.2 host application.
Run with -? for options

-------------------------------------------------------------------------------
SIMD conformance
-------------------------------------------------------------------------------
/Users/stasj/Developer/ospray2/opt/openvkl/testing/apps/tests/simd_conformance.cpp:131
...............................................................................

/Users/stasj/Developer/ospray2/opt/openvkl/testing/apps/tests/simd_conformance.cpp:142:
warning:
  only performing SIMD conformance tests for native width: 8

===============================================================================
All tests passed (381 assertions in 2 test cases)

[StasJ]

I built the libraries in debug mode and I get EXC_BAD_ACCESS (code=EXC_I386_GPFLT) at line 476 in ISPCDriver.cpp in OpenVKL

[StasJ]

I followed the same steps on a linux machine and it works. I rebuilt the library on my Mac using static paths (as opposed to rpath) just to be safe and I run into the same issue.

[timrowley]

On the mac, which processor are you using? Perhaps we're misidentifying the vector width.

[StasJ]

I have an Intel I7-9750H

[StasJ]

Would you be wiling to send me a binary rather than me building from source? That would help eliminate any problems due to my system configuration and build process.

[johguenther]

Is this still an issue? A lot happened in VKL and OSPRay, in particular how the VKL-Iterators are allocated.

[StasJ]

I am no longer running into this issue.

[johguenther]

Thanks for checking.