search

RenderKit / ospray

An Open, Scalable, Portable, Ray Tracing Based Rendering Engine for High-Fidelity Visualization
http://ospray.org
Apache License 2.0
1.01k stars 182 forks source link

Graceful codepath for when no implementation is available #470

Closed mathstuf closed 1 year ago

mathstuf commented 3 years ago

This is most recently seen on macOS ARM machines with Rosetta which does not implement AVX emulation. Currently even trying to initialize OSPRay fails with a SIGILL. OSPRay should detect when the hardware/runtime configuration does not support any compiled backend and have a suitable no-op path (and some API available that consumers can use to know that OSPRay is in such a mode). This can also occur when running with older CPUs which don't have any AVX at all, so it's not just a macOS issue.

Cc: @demarle

Twinklebear commented 3 years ago

Hi Ben, could you share a bit more info about how you built/got OSPRay to run it? We do build and ship SSE builds of our ISPC code and Embree/OpenVKL should fall back to SSE if they detect AVX isn't supported. I have one of the M1 Mac Minis and was able to download and run ospExamples from the 2.4.0 release under Rosetta:

Screen Shot 2021-02-04 at 10 01 56 PM

Edit: I'm also able to build and run via the superbuild, though this needed some modifications to the dependency and ospray build scripts to pass through the -DCMAKE_OSX_ARCHITECTURES=x86_64 flag

mathstuf commented 3 years ago

We are building using the instructions found in this file (and we're using OSPRay 2.4 with the default "ALL" ISA setting). The reported crash is in a binary built with Xcode 11.5 (so no support for aarch64 at all in that compiler). The observed backtraces can be seen here where it tries to load one of its libraries. It seems that OSPRay's CPU feature detection does not take some things into account?

Twinklebear commented 3 years ago

Interesting, I'm not sure the cause of the crash there because this example app will go through the same code path after calling ospInit as far as setting up OSPRay is concerned. I'll try out building the superbuild on my M1 machine, but it looks like I've got XCode 12.4 installed which might also be related to the build here working vs. not there. Although I'd think for x86_64 targets it's similar

Twinklebear commented 3 years ago

Hi Ben,

I talked with @demarle about how to run the VTK tests with OSPRay and got these built on my M1 machine, and it looks like I'm able to run with OSPRay under Rosetta when using my superbuild version of OSPRay (OSPRay 2.4, same used in ParaView 5.9 I think). I do get the same crash you reported when running ParaView downloaded from the release page, so I think this is more of a temporary build config issue in the ParaView 5.9 release rather than a bug in OSPRay/Embree. I'm using XCode 12.4 but I was also able to run the OSPRay releases off of github, which I think are built with clang 11 (I'm using 12, and xcode 12.4), along with the Embree verification tests on SSE using Rosetta from the Embree release page.

For example, here's the TestOSPRayRenderMesh test in the interactive run mode under Rosetta:

Screen Shot 2021-02-10 at 12 01 31 PM

This is run on the paraview/release branch of VTK https://gitlab.kitware.com/vtk/vtk/-/tree/paraview/release , before the commit disabling OSPRay on M1 (commit hash 53f3d9ed3c00b91be73afc419e3950ee5e5c4b8f ). I don't have qt5 setup, and I've got brew on the M1 setup to do arm builds so it's a bit fiddly to setup to run ParaView GUI but I think the VTK OSPRay stuff is run the same (@demarle ?) whether it's directly in VTK or ParaView. At least this basic issue where it fails to run entirely should be the same, which I don't seem to be able to reproduce here.

Edit: Maybe one thing we'd need to fix it (though I'm not quite sure) is to add the OSX arch's flag in the OSPRay superbuild. However, if the compiler defaults to x86_64 (on my M1 it defaults to arm) that may not be needed? I need that flag set when building on my M1 since clang will default to arm otherwise. This flag being set is likely where I diverge a bit, however the release builds on Github of OSPRay/Embree are built on x86_64 Mac's and don't explicitly set this flag

demarle commented 3 years ago

I'll look at differences in PVSB's embree et al and OSPRaySB's. Perhaps there is something in the configs that would explain it.

mathstuf commented 3 years ago

I'll note that we are building with Xcode 11.5, so that could also be a difference.

johguenther commented 3 years ago

What is the status here? Note that we support ARM natively starting with v2.7.0.