Why Don't Samples Compile on Linux

[cuppajoeman]

I was reading in the docs and then found this in the samples section:

I am wondering why this is the case, and what would need to be done to have it work natively on linux.

[jrouwe]

The sample app uses DirectX, in order to port it to Linux a 2nd Vulkan based renderer would need to get written. This is something I intend to do some day, but for now you can run the samples using Wine as described in the Build section.

[cuppajoeman]

Thanks for your input @SirLynix and @Wunkolo. I never knew about the compatibility options for Vulkan, so those are great to know about.

From what I see, if we're were to use Ashes for example we could write the Vulkan renderer with native Vulkan code and then simply switch the include at the top to the ashes header and we would get compatibility for older hardware while also still using Vulkan on machines that allow for that.

@jrouwe What would be your take on using something like ashes while building a Vulkan renderer?

[SirLynix]

As a Vulkan confirmed user and big fan, I think it's the right choice for Jolt library as an optional GPU acceleration mode, but not so much for the demos. As it's very explicit and overly complicated for such classical rendering, just compare how many lines are required to draw a triangle with Vulkan and then with WebGPU. Plus WebGPU runs on more platforms and we may hope to port Jolt Physics demo on web (using emscripten), as I did myself with my own engine.

If Jolt's GPU implementation uses Vulkan then the Demos would need that Vulkan support anyways as well

From my understanding, Vulkan would be an implementation detail of Jolt and the demo would not have to use it to use GPU acceleration, it would be completely separate. Of course that means that Jolt Physics demos would not benefit from GPU acceleration when running on the web, which seems completely fine.

WebGPU is also designed at a level of abstraction where it is not able to access some native Vulkan features that might be interfaced with such as 64-bit integer/float support.

This is one of the many reason WebGPU is not suited for GPU acceleration, but it's still perfectly fine as a demo renderer.

From what I see, if we're were to use Ashes for example we could write the Vulkan renderer with native Vulkan code and then simply switch the include at the top to the ashes header and we would get compatibility for older hardware while also still using Vulkan on machines that allow for that.

You wouldn't even need to change / recompile the code, just set some environment variables or make the application load it instead of the Vulkan library on the system.

[Wunkolo]

just compare how many lines are required to draw a triangle with Vulkan and then with WebGPU

Something like Vulkan-Hpp would probably be used for both the implementation details in Jolt and the demos to remove much of the trivial fluff of structure-setup, pNext-chains, object-cleanup, and much of the other boilerplate found in the triangle demo. Check out some of the samples there for details. vk::Unique* would remove dozens of lines, using vk::(StructureName) would remove even more, and some of the other interactions between C++17 features and Vulkan-Hpp can allow even more concise and expressive code.

I also think the existing DX12 demo code lends itself to Vulkan better at the moment as well. It would make an eventual DX12->Vulkan port that much more trivial than a DX12->WebGPU one.

This is one of the many reason WebGPU is not suited for GPU acceleration, but it's still perfectly fine as a demo renderer.

I can foresee a situation where there is a GPU-Acceleration Jolt-Demo that provides some sort of visualization or interpretation of the underlying Jolt-GPU implementation. During development, these demos would also probably be a testbed of sorts for debugging and diagnosing issues with tools like RenderDoc and Nsight-Graphics which would both require a swapchain workload that eventually touches the Jolt-GPU implementation details. With WebGPU demos, WebGPU would now have to try and interop with Vulkan if there was any in-demo tooling or visualization that accesses this data and would also add this complexity to a gpu-debugging workflow. If the Vulkan implementation uses a feature that WebGPU has no analog for, like 64-bit int/float, then the ability to access or visualize or debug that data from a demo is that much more out of reach.

I also feel like the performance and general evaluation of the Demos is to be somewhat indicative of a shipped title that uses Jolt. WebGPU would be a bit farther away from that than interfacing with DX12/Vulkan directly like most game engines and projects that are evaluating Jolt as their physics-solution would do.

[jrouwe]

I agree with @Wunkolo here that it is better to have a Vulkan version first.

Requirements would be that:

• Both DX12 and Vulkan are supported by the demo framework
• I would prefer not to use any 3rd party libraries, although the use of vulkan-hpp doesn't seem that bad inside the Samples folder.
• Inside the Jolt folder only plain DX12/Vulkan code can be used to ensure that users of the library don't get to deal with multiple licenses.

Once I start working on a GPU version an abstraction around 'compute' will need to be written with an implementation for DX12 and Vulkan (and versions for other platforms). This abstraction should live in the Jolt folder. The abstraction should assume that DX12/Vulkan is already fully initialized and should take a minimal set of handles to the needed resources as it will need to integrate into other peoples engines. As the demo framework can render through DX12/Vulkan it can provide those handles and can instantiate the correct abstraction layer based on the current selected renderer (which makes debugging easier as @Wunkolo states).

Given how difficult it is to debug anything created with emscripten at the moment, I'm not sure if I'll ever get around to creating a GPU version for the web.

[jrouwe]

FYI: The Jolt samples now run natively on Linux using Vulkan