bump to ospray 2.4

picks up a fix for volume shadows and AMR volume placement

changed milestone to %5.9 (Fall 2020)

@utkarsh.ayachit - The oidn on public is missing the source for the mkl-dnn submodule. For testing purposes I am grabbing directly from upstream.

Can you move the one I am pointing at onto public? Also please let me know if you got yours from an Intel website so that I correct it there.

thanks

Do: test

added 1 commit

• bb862671 - bump to ospray 2.4

Compare with previous version

added 1 commit

• b7463b6b - bump to ospray 2.4

Compare with previous version

resolved all threads

openvkl is not dynamically loading its modules. moving to WIP

marked as a Work In Progress

added 2 commits

• 236ae4a7 - bump to ospray 2.4
• d02a201c - add installed rpath to openvkl to make SB's build run as is

Compare with previous version

Warnings:

• the merge request is marked as a work-in-progress.

The warnings do not need to be fixed, but it is recommended to do so.

Removing WIP, the second commit solves the problem for VKL the same way OSPRay does it - rpath in the install tree.

unmarked as a Work In Progress

Do: test

@demarle, SB has moved over to gitlab-ci. use the pipelines to manually triggers the builds.

@utkarsh.ayachit Thanks. Er, how?

@utkarsh.ayachit I don't know how to interpret that failure on the mac builder, is that a systems issue or something real? Hmmm, I think I've kicked off a rebuild there, perhaps that will succeed.

everything seems to be passing now.

cc: @ben.boeckel

If it was an sccache server timeout thing, I'm working on that. Should have an update here soon.

If the failures were a transient infrastructure thing can we merge this?

If you're confident that macOS isn't affected by it. Otherwise, you can rebase and that specific problem should be fine now.