test for viability of compute systems at runtime

[stephengold]

I'm experimenting with the (post-v5.5.0) support for compute shaders in Jolt. My project is a JVM library that runs on various platforms including Linux, macOS, and Windows. Already I build multiple shared libraries for each platform:

• one with single-precision positions and assertions
• one with single-precision positions and no assertions
• one with double-precision positions and assertions
• one with double-precision positions and no assertions

I'd like to add support for compute shaders, both CPU-based and GPU-based, without doubling the number of shared libraries. My plan was to build with both -DJPH_USE_CPU_COMPUTE and (for example) -DJPH_USE_VK, then test at runtime whether the platform supports (in this example) Vulkan, then fall back to CPU compute if it doesn't:

       ComputeSystemResult csResult = CreateComputeSystem();
       if (csResult.hasError()) {
           csResult = CreateComputeSystemCpu();
       }

However when JPH_USE_VK is defined, Vulkan is unavailable, and assertions are enabled, CreateComputeSystem() crashes the JVM , due to the following assert in "IncludeVK.h":

JoltPhysics/Jolt/Compute/VK/IncludeVK.h

Line 38 in e486f5b

JPH_ASSERT(false);

I see the utility of failing quickly when a Vulkan call fails unexpectedly during debugging. However, it would be more convenient for me if failures during JPH::CreateComputeSystemVK() were reported via the return value (ComputeSystemResult) instead of an assertion. Perhaps the assertion could be bypassed by JPH::CreateComputeSystemVK().

Or is there a better way to determine at runtime whether (for example) Vulkan is supported?

[jrouwe]

That assert is there to easily catch the exact location where things went wrong in the debugger. After the assert triggers, it should continue and return the error code through the ComputeSystemResult code. So I think your technique should work. But maybe asserts are fatal in Java? (they're not in Jolt)

[stephengold]

Thank you for your reply.

But maybe asserts are fatal in Java?

That's a perceptive question. I tend to think of asserts as fatal, both in Java and Jolt, but of course they don't have to be.

In Java, assertions are implemented using exceptions, which code can catch and ignore, though I consider that poor coding practice. As far as I know, the Java debugger won't modify variables or clear exceptions. (Though now that I think of it, that might be a limitation of the IDE I'm using.)

In Jolt, the return value of the AssertFailed method determines whether a breakpoint is generated, and unless a native-code debugger is attached, such breakpoints are fatal. For the duration of the CreateComputeSystem() call, I could alter the AssertFailed method to return false instead of true. I hadn't considered that approach before. I'll try it and see if it works.

Assuming it works, is that the best way to determine whether a suitable DX/Metal/Vulkan driver is present? It looks clumsy because it would affect all assertions for the duration of the call, not just the current thread and not just the assertion at line 38.

[stephengold]

With the fix, my test app crashes with a failed assertion at a new location:

Jolt/Compute/VK/ComputeSystemVKImpl.cpp:25: ((inSeverity & VK_DEBUG_UTILS_MESSAGE_SEVERITY_ERROR_BIT_EXT) == 0) 

I'll obtain a stack trace.

[jrouwe]

Can you also list the error message it outputs?

[stephengold]

The stack trace of the new crash:

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libjoltjni.so+0x415085]  CrashAssertFailed(char const*, char const*, char const*, unsigned int)+0xb5
C  [libjoltjni.so+0xa05bc]  JPH::AssertFailedParamHelper(char const*, char const*, unsigned int, JPH::AssertLastParam)+0x2c
C  [libjoltjni.so+0x712ab2]  JPH::sVulkanDebugCallback(VkDebugUtilsMessageSeverityFlagBitsEXT, unsigned int, VkDebugUtilsMessengerCallbackDataEXT const*, void*)+0x72
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  com.github.stephengold.joltjni.ComputeSystem.createSystemGpu()J+0

On Linux, the last relevant message is "VK: vkCreateInstance: Found no drivers!"

On Windows, the last relevant messages are:

VK: windows_read_data_files_in_registry: Registry lookup failed to get layer manifest files.
VK: windows_read_data_files_in_registry: Registry lookup failed to get ICD manifest files.  Possibly missing Vulkan driver?

[jrouwe]

I really don't want to lose this assert (it's super helpful when working on the Vulkan implementation). I think the best way forward is to just register an assert handler that never triggers a breakpoint.

[stephengold]

Thanks for your advice. I'll do that.