Spirv-headers are not in correct locations with latest LunarG on linux

[Steve132]

Steps to reproduce: install latest linux LunarG packages

wget -qO - http://packages.lunarg.com/lunarg-signing-key-pub.asc | sudo apt-key add -
sudo wget -qO /etc/apt/sources.list.d/lunarg-vulkan-1.1.121-bionic.list http://packages.lunarg.com/vulkan/1.1.121/lunarg-vulkan-1.1.121-bionic.list
sudo apt update
sudo apt install vulkan-sdk

Then try to compile the examples:

cmake ../examples/ && make

/home/steven/Software/Vookoo/examples/../include/vku/vku.hpp:31:10: fatal error: vulkan/spirv.hpp11: No such file or directory
#include <vulkan/spirv.hpp11>

This is because in the new lunarg SDK splits the spirv headers into a new project https://github.com/KhronosGroup/SPIRV-Headers

The new location for the headers in the lunarg sdk is spirv/<version>

find /usr/include -name spirv.hpp11
/usr/include/spirv/unified1/spirv.hpp11
/usr/include/spirv/1.2/spirv.hpp11
/usr/include/spirv/1.0/spirv.hpp11
/usr/include/spirv/1.1/spirv.hpp11

[FunMiles]

I have hit the same issue. I simply changed the include to:

#include <spirv/unified1/spirv.hpp11>

Is this project still alive? A pull request could be warranted if this work on every machine.
However there's also the issue that on Mac OS X, I am not finding this spirv.hpp11 file.
Can it be simply copied from Linux (I will have to try when I have a bit more time)

[lhog]

Looks like vookoo is becoming a bit bitrotten, which is sad. I really liked the capabilities and code. @andy-thomason what's your plan for this repo?

[andy-thomason]

If you want to make PRs, I'll be happy to accept them.

[andy-thomason]

The motivation for Vookoo came from the need to make high framerate molecular simulators like https://github.com/andy-thomason/moovoo

[andy-thomason]

I'm no longer working in the structural biology space but in statistical genetics and almost entirely in Rust, but I hope to return to Vulkan when the opportunity arises.

[lhog]

@FunMiles @Steve132 cannot reproduce your issue.
I'm on Vulkan 1.2.131.2, which is latest at the time I write this. spirv.hpp11 is still where it was before:

[Steve132]

https://github.com/KhronosGroup/SPIRV-Headers/tree/master/include/spirv

[lhog]

For me spirv.hpp11 in include/vulkan and blabla/spirv/unified1 is exactly same.

I see it might be not the case for your OS/distribution.

I haven't been able to find any CMake file examples how to deal with finding relative path to spir-v/unified1 in a cross-platform way. For you it's just /usr/include, but I'm not sure it's uniform for other Linux distributions.

[andy-thomason]

I've made the spirv headers optional for now but did observe that the package glslang-dev on debian contains a SPIRV directory.

[andy-thomason]

I would be remiss if I didn't mention the excellent Vulkano crate in the Rust ecosystem.
https://github.com/vulkano-rs/vulkano

[FunMiles]

For me spirv.hpp11 in include/vulkan and blabla/spirv/unified1 is exactly same.

I see it might be not the case for your OS/distribution.

I haven't been able to find any CMake file examples how to deal with finding relative path to spir-v/unified1 in a cross-platform way. For you it's just /usr/include, but I'm not sure it's uniform for other Linux distributions.

The MacOS X distribution of Vulkan/MoltenVK does not include the spirv includes. So Andy's work to make them optional have made it possible for me to easily port Vookoo to Mac OS. The README.md of Khronos SPIR-V headers says:

Headers are provided in the include directory, with up-to-date headers in the unified1 subdirectory. Older headers are provided according to their version.

So it seems that the path spirv/unified path is the intended standard path.

[andy-thomason]

While making the spirv headers optional has made this less of a problem, we should investigate restoring them once we have a definitive location and package list.

I'm going to close this for now.

[FunMiles]

I will look at this and try to address @lhog comment on how to find it. Perhaps trying to find the include from a series of possible paths and turning on/off a flag to indicate whether they were found would do the job. Then any example that require them should be removed from the build list.