Vulkan

[codex128]

This is an experiment I've been working on for the past month or two. I'm opening this PR now to get feedback on whether Vulkan support should be pursued further, and if so, whether OpenGL support should be dropped. Let me know what you guys think.

The primary goal is to determine how difficult it would be to port the engine over to Vulkan. Currently, I've made a set of tools that match 1:1 with Vulkan's base elements and have managed to render a spinning textured quad with those tools running from a JME application. I'm finding it to be not as bad as expected in terms of complexity.

Going forward, I'm trying to be as faithful as possible to JME's original high-level design. That means Mesh, Material, Geometry, etc. will hopefully be publically identical for their most common functions.

• Mesh should be relatively simple to port. Vulkan's vertex buffers are fairly similar.
• Geometry shouldn't need to change much since its primary job is to associate a material with a mesh.
• Material will probably be the hardest. Vulkan is completely different from OpenGL in this area.

Other considerations:

• Vulkan is manually synchronized. The engine components will have to be a lot more context-aware than they currently are.
• Vulkan benefits from having multiple frames-in-flight. That may require that some data structures have duplicates for each possible concurrent frame.
• We will have to drop lwjgl2 and jogl support. Most lwjgl-related advice is to move to lwjgl3 anyway, so I doubt anyone will be missing lwjgl2.

Because Vulkan uses structs for storing object creation settings that can often hold a lot of settings, I decided to use make use of builders and try-with-resources blocks. This way, it is obvious what methods are for initialization only, and everything is initialized and closed properly with the try-with-resources block. It also works very nicely with MemoryStack.

VulkanInstance instance = new VulkanInstance(VK_API_VERSION_1_3);
try (VulkanInstance.Builder i = instance.build()) {
    i.addGlfwExtensions();
    i.addDebugExtension();
    i.addLunarGLayer();
    i.setApplicationName(VulkanHelperTest.class.getSimpleName());
    i.setApplicationVersion(1, 0, 0);
}

LogicalDevice<GeneralPhysicalDevice> device = new LogicalDevice<>(instance);
try (LogicalDevice.Builder d = device.build(id -> new GeneralPhysicalDevice(instance, surface, id))) {
    d.addFilter(surface);
    d.addFilter(DeviceFilter.swapchain(surface));
    d.addCriticalExtension(KHRSwapchain.VK_KHR_SWAPCHAIN_EXTENSION_NAME);
    d.addFeature(DeviceFeature.anisotropy(1f, true));
}

[github-actions]

🖼️ Screenshot tests have failed.

The purpose of these tests is to ensure that changes introduced in this PR don't break visual features. They are visual unit tests.

📄 Where to find the report:

• Go to the (failed run) > Summary > Artifacts > screenshot-test-report
• Download the zip and open jme3-screenshot-tests/build/reports/ScreenshotDiffReport.html

⚠️ If you didn't expect to change anything visual:
Fix your changes so the screenshot tests pass.

✅ If you did mean to change things:
Review the replacement images in jme3-screenshot-tests/build/changed-images to make sure they really are improvements and then replace and commit the replacement images at jme3-screenshot-tests/src/test/resources.

✨ If you are creating entirely new tests:
Find the new images in jme3-screenshot-tests/build/changed-images and commit the new images at jme3-screenshot-tests/src/test/resources.

Note; it is very important that the committed reference images are created on the build pipeline, locally created images are not reliable. Similarly tests will fail locally but you can look at the report to check they are "visually similar".

See https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-screenshot-tests/README.md for more information

Contact @richardTingle (aka richtea) for guidance if required

[riccardobl]

wow you've done a ton of work!

I don't think we should have the goal to drop opengl entirely, because it is still the most widely supported api, even on platforms where vulkan is not available yet (ie. web with webgl).

But i think we can decide to drop everything that is below GL ES 3 and GL ~3.2.
And if it helps harmonizing vulkan and opengl renderers (actually i don't know, so i am asking you), we could switch to UBOs for material parameters.

[codex128]

Thanks, your response is very encouraging! I will take that as support to continue working on this project.

I don't think we should have the goal to drop opengl entirely, because it is still the most widely supported api, even on platforms where vulkan is not available yet (ie. web with webgl).

That is the position I expected, and I agree. I ask only because not supporting OpenGL would probably have made things a lot easier. 😉

if it helps harmonizing vulkan and opengl renderers, we could switch to UBOs for material parameters.

That's a good idea! I hadn't thought about doing it that way. I don't know for certain about the CPU-side stuff just yet, but it will help tremendously with having shaders work with either platform. This is definitely worth looking into more.

I'm planning on tackling Material first, as it looks to be the most difficult. I will have more details to provide then.

[richardTingle]

Please ignore the screenshot test failure. This is caused by a version change. I have a PR out for it