Closed blackball closed 4 years ago
Thanks for the note, I was concerned about the use of extensions in the header but the only way to find out if it's users are building against older headers is to put it out there. Potentially we could add some extra header definitions in to handle this particular case, though I'd rather keep the code as clean for as long as possible.
If you comment this entry out how far does the build get?
Could you check the value of VK_HEADER_VERSION found in your vulkan_core.h?
I've just had a look through the VULKAN_SDK from LunaG I've successively downloaded and the time VK_INDEX_TYPE_UINT8_EXT appears from VK_HEADER_VERSION 121 onwards.
As a workaround for the missing enum I've just checked in the follow commit to master.
https://github.com/vsg-dev/VulkanSceneGraph/commit/c3525a3b8e7e54fddd400e1cebda9bbaba4aa5e4
Comment that line out, the compilation will be succeed.
// Version of this file
#define VK_HEADER_VERSION 97
Do you see any errors with use of enums likes VK_RAY_TRACING_SHADER_GROUP_TYPE_MAX_ENUM_NV?
These are now used without any fallback in the RTX raytracing code.
With the latest version of vsg. The compilation are fine for both vsg and vsgExamples. But when I ran the examples, it will crash. For instance:
./vsgraytracing
Error: vsg::Device::create(...) failed to create logical device.
Error: vsg::Window::create(...) failed to create Window, unable to create Vulkan logical Device.
Could not create windows.
ldd vsgraytracing
linux-vdso.so.1 (0x00007ffe3edd7000)
libvulkan.so.1 => /lib/x86_64-linux-gnu/libvulkan.so.1 (0x00007fdeab9b9000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdeab998000)
libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fdeab96e000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fdeab7ea000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fdeab667000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fdeab64d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdeab48a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fdeab485000)
/lib64/ld-linux-x86-64.so.2 (0x00007fdeabb52000)
libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007fdeab281000)
libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fdeab07b000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007fdeab061000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fdeab055000)
Did vsgraytracing crash or just exit after reporting it couldn't create the required window.
If your driver/hardware don't support RTX ray tracing then the VSG won't be able to create a device/window to do it so that part of the behavior is normal. My guess is that mesa doesn't yet support the extension. The RTX ray tracing is an NVidia extensions. Just yesterday Khronos announced provision ray tracing API based on the RTX work from NVidia, so I'll move the code across to this once I have the opportunity.
Sorry for the late reply.
I checked the mesa version I installed, you are right, it doesn't support that extension. Also I was running the examples on a machine with just an Intel i7.
Thanks for your great work.
Describe the bug VulkanSceneGraph/include/vsg/vk/BindIndexBuffer.h:30:30: error: ‘VK_INDEX_TYPE_UINT8_EXT’ was not declared in this scope case (1): return VK_INDEX_TYPE_UINT8_EXT;
To Reproduce I am using the mesa-vulkan-drivers on Debian 10
Then just cmake and make.
Expected behavior Since mesa-vulkan-driver is depending on libvulkan1, on Debian10, it's version 1.1+, so I guess it should be supported ?
https://packages.debian.org/buster/mesa-vulkan-drivers https://packages.debian.org/buster/libvulkan1
Desktop (please complete the following information):