I am trying to work around the issue here on OLCF’s Summit machine.
My suspicion is that the use of EGL and the hardware accelerator layout on those nodes may just be too new and complex to be used for rendering on right now. So I am trying to use OSMesa for my rendering.
I am using mesa-19.2 and LLVM 9.0.0 which all installs all the way through my executable just fine.
At run time, however, I get the following output from OSMesa
lp_build_max_simple: altivec doesn't support nan return nan behavior
lp_build_min_simple: altivec doesn't support nan return nan behavior
The code then crashes when initializing the coprocessor. The backtrace shows the error happening in the OSMesa function
#1 0x0000200011e35134 in lp_rast_shade_quads_mask (task=0x1000000010, inputs=0x1000000010, x=8, y=8, mask=8)
at ../src/gallium/drivers/llvmpipe/lp_rast.c:454
state = 0xbd55a3c1bd55a3c1
variant = 0xbd55a3c1bd55a3c1
scene = 0x8000000080000000
color = {0x8000000080000000 <Address 0x8000000080000000 out of bounds>,
0xc26061d9c26061d9 <Address 0xc26061d9c26061d9 out of bounds>,
0xc26061d9c26061d9 <Address 0xc26061d9c26061d9 out of bounds>, 0x0, 0x0,
0x3d55a2e63d55a2e6 <Address 0x3d55a2e63d55a2e6 out of bounds>,
0x3d55a2e63d55a2e6 <Address 0x3d55a2e63d55a2e6 out of bounds>,
0x3f8000003f800000 <Address 0x3f8000003f800000 out of bounds>}
stride = {1065353216, 1065353216, 2147483648, 2147483648, 2147483648, 2147483648, 2147483648, 2147483648}
depth = 0x41e9ab0e41e9ab0e <Address 0x41e9ab0e41e9ab0e out of bounds>
depth_stride = 1105832718
i = 1105832718
__PRETTY_FUNCTION__ = "lp_rast_shade_quads_mask"
As a sanity check, I reused the same scenes and renderview in a python state file and ran it on the dataset my code writes, and it was able to render the images just fine. So my paraview install is behaving well. But it seems like when the renderviews are initialized while coprocessing there may be a nan passed that is not supported on the summit IBM architecture/instruction set?
Thanks for taking a look
Kyle