Setup issues on Ubuntu 23.10

[Firestar99]

My Professor recommended your framework as a potential baseline for my master's thesis. So I attempted to get it working on my Ubuntu 23.10 machine with Clion and according to your documentation shouldn't require anything out of the ordinary apart from the vulkan-sdk. But Unfortunately I ran into multiple issues, and instead of creating a separate issue for each one, I thought it'll be better to just summarize them here.

1. Example model_loader fails to configure

I've used the -D avk_toolkit_BuildExamples=ON cmake flag to enable all of your examples to get an overview of what the framework can do. Sadly the model_loader example fails to configure, so I commented out the lines below likely breaking the example. May there be a typo in the last line, with gvk instead of avk?

add_post_build_commands(model_loader
    ${PROJECT_SOURCE_DIR}/examples/model_loader/shaders
    ${model_loader_BINARY_DIR}/shaders
    $<TARGET_FILE_DIR:model_loader>/assets
    "${model_loader_assets}"
    ${gvk_CreateDependencySymlinks})

examples/model_loader/CMakeLists.txt

2. Framework fails to build with clang

It fails to build with clang but works with GCC, so I guess I continue with that.

<project_dir>/auto_vk/include/avk/buffer.hpp:273:4: error: calling 'read_into' with incomplete return type 'avk::command::action_type_command'
read_into(static_cast<void*>(&result), aMetaDataIndex);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<project_dir>/auto_vk/include/avk/buffer.hpp:255:37: note: 'read_into' declared here
avk::command::action_type_command read_into(void* aDataPtr, size_t aMetaDataIndex) const;
^
<project_dir>/auto_vk/include/avk/avk.hpp:215:10: note: forward declaration of 'avk::command::action_type_command'
struct action_type_command;
^

Full error

FAILED: CMakeFiles/Auto_Vk_Toolkit.dir/cmake_pch.hxx.pch 
/usr/bin/clang++ -DIMGUI_DISABLE_OBSOLETE_FUNCTIONS -DIMGUI_DISABLE_OBSOLETE_KEYIO -I<project_dir>/external/linux/include -I<project_dir>/auto_vk_toolkit/include -I/include/assimp -I<project_dir>/cmake-build-debug/_deps/glfw-src/include/GLFW -I<project_dir>/cmake-build-debug/_deps/imgui-src -I<project_dir>/cmake-build-debug/_deps/imgui-src/backends -I<project_dir>/auto_vk/include -I<project_dir>/cmake-build-debug/_deps/glfw-src/include -I<project_dir>/cmake-build-debug/_deps/stb-src -g -std=gnu++20 -fcolor-diagnostics -Winvalid-pch -fpch-instantiate-templates -Xclang -emit-pch -Xclang -include -Xclang <project_dir>/cmake-build-debug/CMakeFiles/Auto_Vk_Toolkit.dir/cmake_pch.hxx -x c++-header -MD -MT CMakeFiles/Auto_Vk_Toolkit.dir/cmake_pch.hxx.pch -MF CMakeFiles/Auto_Vk_Toolkit.dir/cmake_pch.hxx.pch.d -o CMakeFiles/Auto_Vk_Toolkit.dir/cmake_pch.hxx.pch -c <project_dir>/cmake-build-debug/CMakeFiles/Auto_Vk_Toolkit.dir/cmake_pch.hxx.cxx
In file included from <built-in>:1:
In file included from <project_dir>/cmake-build-debug/CMakeFiles/Auto_Vk_Toolkit.dir/cmake_pch.hxx:5:
In file included from <project_dir>/auto_vk_toolkit/include/auto_vk_toolkit.hpp:113:
In file included from <project_dir>/auto_vk/include/avk/avk.hpp:223:
<project_dir>/auto_vk/include/avk/buffer.hpp:273:4: error: calling 'read_into' with incomplete return type 'avk::command::action_type_command'
                        read_into(static_cast<void*>(&result), aMetaDataIndex);
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<project_dir>/auto_vk/include/avk/buffer.hpp:255:37: note: 'read_into' declared here
                avk::command::action_type_command read_into(void* aDataPtr, size_t aMetaDataIndex) const;
                                                  ^
<project_dir>/auto_vk/include/avk/avk.hpp:215:10: note: forward declaration of 'avk::command::action_type_command'
                struct action_type_command;
                       ^
1 error generated.
ninja: build stopped: subcommand failed.

3. hello_world example fails assert

Duplicate of: #157

You request 3 images and for some reason Mesa gives you 5, which causes this assert. Same workaround as the mentioned issue: In the main method change set_number_of_concurrent_frames(3) and set_number_of_presentable_images(3) to 5. Then Hello world works!

assert(imagesInFlight == get_config_number_of_presentable_images()); // TODO: Can it happen that these two ever differ? If so => handle!

auto_vk_toolkit/src/window.cpp:783

4. vertex_buffers and all other raster examples fail to link

See my highlight below, I'm not sure how this is supposed to work, and I'm suck here, as all other examples depend on vertex input working.

<project_dir>/auto_vk/include/avk/input_description.hpp:173:
undefined reference to `vk::Format avk::format_for<glm::vec<3, float, (glm::qualifier)0> vertex_buffers_app::Vertex::*>()
                                                   | first generic "glm::vec3f"        | | a second generic?         |

Full error

[5/5] Linking CXX executable examples/vertex_buffers/vertex_buffers
FAILED: examples/vertex_buffers/vertex_buffers 
: && /usr/bin/c++ -g  examples/vertex_buffers/CMakeFiles/vertex_buffers.dir/source/vertex_buffers.cpp.o examples/vertex_buffers/CMakeFiles/vertex_buffers.dir/__/__/auto_vk/src/avk.cpp.o -o examples/vertex_buffers/vertex_buffers  -Wl,-rpath,<project_dir>/cmake-build-debug-gcc  libAuto_Vk_Toolkit.a  /usr/lib/x86_64-linux-gnu/libassimp.so.5.2.4  /usr/lib/x86_64-linux-gnu/libz.so  /usr/lib/x86_64-linux-gnu/libdraco.so.8.0.0  -lminizip  _deps/glfw-build/src/libglfw3.a  /usr/lib/x86_64-linux-gnu/librt.a  -lm  -ldl  /usr/lib/x86_64-linux-gnu/libX11.so  /usr/lib/x86_64-linux-gnu/libvulkan.so  libstb_shared.so && :
/usr/bin/ld: examples/vertex_buffers/CMakeFiles/vertex_buffers.dir/source/vertex_buffers.cpp.o: in function `avk::partial_input_binding_to_location_mapping& avk::partial_input_binding_to_location_mapping::stream_per_vertex<glm::vec<3, float, (glm::qualifier)0> vertex_buffers_app::Vertex::*>(glm::vec<3, float, (glm::qualifier)0> vertex_buffers_app::Vertex::* const&)':
<project_dir>/auto_vk/include/avk/input_description.hpp:173:(.text._ZN3avk41partial_input_binding_to_location_mapping17stream_per_vertexIMN18vertex_buffers_app6VertexEN3glm3vecILi3EfLNS4_9qualifierE0EEEEERS0_RKT_[_ZN3avk41partial_input_binding_to_location_mapping17stream_per_vertexIMN18vertex_buffers_app6VertexEN3glm3vecILi3EfLNS4_9qualifierE0EEEEERS0_RKT_]+0x15): undefined reference to `vk::Format avk::format_for<glm::vec<3, float, (glm::qualifier)0> vertex_buffers_app::Vertex::*>()'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

5. All raytracing examples have validation errors and segfault

If raster doesn't work we can of course try raytracing :D

I've mostly played around with the ray_tracing_with_shadows_and_ao and ray_query_in_ray_tracing_shaders, as ray_tracing_custom_intersection doesn't even compile. First the validation error:

VUID-vkCreateDevice-ppEnabledExtensionNames-01387(ERROR / SPEC): msgNum: 307460652 - Validation Error: [ VUID-vkCreateDevice-ppEnabledExtensionNames-01387 ] Object 0: handle = 0x555555e84190, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x12537a2c | vkCreateDevice(): pCreateInfo->ppEnabledExtensionNames[3] Missing extension required by the device extension VK_KHR_ray_tracing_pipeline: VK_KHR_acceleration_structure. The Vulkan spec states: All required device extensions for each extension in the VkDeviceCreateInfo::ppEnabledExtensionNames list must also be present in that list (https://vulkan.lunarg.com/doc/view/1.3.268.0/linux/1.3-extensions/vkspec.html#VUID-vkCreateDevice-ppEnabledExtensionNames-01387)
    Objects: 1
        [0] 0x555555e84190, type: 1, name: NULL

And I assume this contributes to the segfault, caused by calling device().getAccelerationStructureBuildSizesKHR(...) with getAccelerationStructureBuildSizesKHR being a nullptr, as the extension VK_KHR_acceleration_structure was never requested. Adding that does make both of the compiling examples work.

6. Small things of note

• Docs on controls would be nice in the Readme's examples section, specifically that F1 is usually used to uncapture your cursor, so you can interact with ImGUI. Maybe a quick mention of the -D avk_toolkit_BuildExamples=ON cmake flag may also be helpful here.
• Shader hot reloading, if it exists, may be broken. In the console there is a lot of spam like this in every example:

INFO: Couldn't load 'shaders/shadow_ao_miss_shader.rmiss' but loading 'shaders/shadow_ao_miss_shader.rmiss.spv' was successful => going to use the latter, fyi! | file[avk.cpp] line[7178]

Hard- and Software

Everything was tested on latest master (e62ac9a), switching to tag 0.99 or 0.98 didn't change anything.

• AMD Rembrandt iGPU within a Ryzen 6900HS
  • RADV from Mesa (the default driver)
    • requires RADV_PERFTEST=rt env var to enable raytracing
  • AMDVLK (closed source driver from AMD)
• CLion 2023.3, Build #CL-233.11799.238, built on December 1, 2023
• CMake 3.27.0
• Clang: Ubuntu clang version 16.0.6 (15)
• GCC: gcc (Ubuntu 13.2.0-4ubuntu3) 13.2.0

[johannesugb]

Thank you for your detailed issue report and sorry that you have experienced so many troubles.
May I ask you do try the latest version on the development branch, which should have at least some of the issues fixed. 🙏

Regarding 1. Example model_loader fails to configure: Yes, that's a typo. But should be fixed on development.

Regarding 2. Framework fails to build with clang: Unfortunately we had to drop Clang support a while ago because it still doesn't offer support for Ranges. Currently, on Linux only GCC version 23 or higher is supported.

Regarding 3. hello_world example fails assert: I see. That must be fixed in code. But could take a while until I get to it. Pull requests are highly appreciated.

Regarding 4. vertex_buffers and all other raster examples fail to link: That's strange. At least our GitHub workflow for GCC 23 does not report any issues on the development branch. Please try that one!

Regarding 5. All raytracing examples have validation errors and segfault: I.e. adding VK_KHR_acceleration_structure solves the issue? May I ask you for a small pull request into the development branch?

Regarding Docs on controls: Should be better on development. The examples use an orbit_camera by default.

Regarding Shader hot reloading: It exists and works. But one has to use an updater to enable it. The "spam" on the console is expected behavior.

[Firestar99]

Regarding 4. vertex_buffers and all other raster examples fail to link: Your CI only ever tests the hello_world example, which does not utilize vertex attributes, as it's vertex data is declared as constants in the shader.

Regarding 5. All raytracing examples have validation errors and segfault:
sure: #190

I've also added a small note about the controls to the example section in your readme, so that not so obvious keybinds like F1 are known:

Auto-Vk-Toolkit/README.md

Lines 103 to 108 in b7daeeb

	Controls:
	* **WASD**
	* **E/Q** for up/down
	* **Shift** to go faster
	* **Esc** to exit
	* **F1** to Toggle input-mode (UI vs. scene navigation)

[ex0planetary]

I'm running into 4 as well. Using Auto-Vk, not Auto-Vk-Toolkit - so it's definitely an issue with Auto-Vk specifically.
I've determined the root cause of the issue, which is that MSVC and GCC parse pointers to members in different ways. If we have, say, a class called Vertex with a member glm::vec3 pos, then &Vertex::pos is of type glm::vec3 in MSVC, but in GCC it's glm::vec3 Vertex::*.
I was able to get it compiling by replacing the following function signature for stream_per_vertex:

template <class M>
		partial_input_binding_to_location_mapping& stream_per_vertex(const M&)

becomes

template <class M, class V>
        partial_input_binding_to_location_mapping& stream_per_vertex(const M V::*&)

It is worth noting two things from my attempted fix here:

1. It didn't actually work fully. Though the app did compile, it gave me a runtime error that the input binding #0 is defined in multiple times in different ways. I don't know exactly how the MSVC version manages to correctly offset the vertex data (though I suspect it has something to do with pointers) but my GCC approach isn't immediately replicating that.
2. Simply adding this as an alternate overload also likely won't work. Though they are separate template arrangements, they do both have one argument, so if you have both the compiler gets confused as to which one you're trying to use. So if this gets implemented into the actual repo, ideally the correct template should get enabled/disabled depending on the compiler you're using.