Closed rainergericke closed 3 years ago
I don't have a macOS or iOS system to test the problem so will need work with you to figure out the cause and come up with a solution.
Do you think an update the VSG caused the regression? I merged the KhronosRayTacing branch a couple of days ago:
The only change to vsg::Instance that is now crashing was the assignment of VkApplicationInfo.apiVersion = vulkanVersion, which before was hardwarired to VK_API_VERSION_1_0.
The value is supplied by WindowTraits.vulkanVersion which also defaults to VK_VERSION_1_0 so I wouldn't expect this to be an issue.
If it does look to be an VSG commit that caused the regression could you do git bisect and see which commit caused the problem, then we can look within that commit for what might have caused the problem.
I found the commits, where Mac functionality has broken:
Working until: VulkanSceneGraph-72bcf7ad783fd83b1a75d7280a66e31d558a64d2 vsgExamples-b6031b523cd37f6cfc9c0bb38d396a1f4c3c8f4b
Broken since: VulkanSceneGraph-1dc325d628cf90cabe9b4bc9679a78ad2e3d5848 vsgExamples-b62765de8535aa0d98f2f0028a8c0deaaf6b9b37
My Vulkan version is 1.2.162
Thanks for investigating, so it was the merge of KhronosRayTracing functionality:
Working commit prior merge of KhronosRayTracing : 72bcf7ad783fd83b1a75d7280a66e31d558a64d2 Failing commit merge of KhronosRayTracing: 1dc325d628cf90cabe9b4bc9679a78ad2e3d5848
These changes should just affect the extension setup and not the general vkInstance initialization, so I'm surprised that it's caused problems will applications like vsgdraw.
The next step would be to see if there is bug in the VulkanSDK on macOS, the latest VulkanSDK 1.2.176.1 would be worth trying to see if that has any affect.
The other avenue would be to run vsgdraw with debug and api layers enabled for the working commit and the failing commit to see if there are differences in the API calls that the VSG is making prior to the crash.
I tried to rebuild with VulkanSDK 1.2.176.1. There is an influence:
my own examples are broken, if pbr shading is used. Simple vsg like texturing works and also Blinn-Phong shading does.
The first failing commits could not be built in this configuration:
[4/42] Building CXX object src/vsg/CMakeFiles/vsg.dir/rtx/AccelerationGeometry.cpp.o
FAILED: src/vsg/CMakeFiles/vsg.dir/rtx/AccelerationGeometry.cpp.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DGLSLANG_ResourceLimits_maxDualSourceDrawBuffersEXT -DHAS_GLSLANG -I/Users/rainerge/VSGTEST/may-12-1/VulkanSceneGraph/include -Iinclude -isystem /usr/local/include -O3 -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk -fPIC -std=gnu++17 -MD -MT src/vsg/CMakeFiles/vsg.dir/rtx/AccelerationGeometry.cpp.o -MF src/vsg/CMakeFiles/vsg.dir/rtx/AccelerationGeometry.cpp.o.d -o src/vsg/CMakeFiles/vsg.dir/rtx/AccelerationGeometry.cpp.o -c /Users/rainerge/VSGTEST/may-12-1/VulkanSceneGraph/src/vsg/rtx/AccelerationGeometry.cpp
/Users/rainerge/VSGTEST/may-12-1/VulkanSceneGraph/src/vsg/rtx/AccelerationGeometry.cpp:29:61: error: assigning to 'VkDeviceAddress' (aka 'unsigned long long') from incompatible type 'nullptr_t'
_geometry.geometry.triangles.vertexData.deviceAddress = VK_NULL_HANDLE;
^~~~~~
/usr/local/include/vulkan/vulkan_core.h:40:36: note: expanded from macro 'VK_NULL_HANDLE'
Later configs can be built, but this is probably not what we want now.
Our pbr shader is actually pretty simplistic and has to be reworked yet. So this is not what we like, but a reason to look at it again and has nothing to do with the vsg/mac issues.
Am 20.05.2021 um 09:00 schrieb Robert Osfield @.***>:
Thanks for investigating, so it was the merge of KhronosRayTracing functionality:
Working commit prior merge of KhronosRayTracing : 72bcf7a https://github.com/vsg-dev/VulkanSceneGraph/commit/72bcf7ad783fd83b1a75d7280a66e31d558a64d2 Failing commit merge of KhronosRayTracing: 1dc325d https://github.com/vsg-dev/VulkanSceneGraph/commit/1dc325d628cf90cabe9b4bc9679a78ad2e3d5848 These changes should just affect the extension setup and not the general vkInstance initialization, so I'm surprised that it's caused problems will applications like vsgdraw.
The next step would be to see if there is bug in the VulkanSDK on macOS, the latest VulkanSDK 1.2.176.1 would be worth trying to see if that has any affect.
The other avenue would be to run vsgdraw with debug and api layers enabled for the working commit and the failing commit to see if there are differences in the API calls that the VSG is making prior to the crash.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/vsg-dev/VulkanSceneGraph/issues/283#issuecomment-844768690, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHOLYFPLH4HBDMN7NJQX3C3TOSXQXANCNFSM45EAQEGA.
Hi Rainer,
On Thu, 20 May 2021 at 09:12, Rainer Gericke @.***> wrote:
I tried to rebuild with VulkanSDK 1.2.176.1. There is an influence:
my own examples are broken, if pbr shading is used. Simple vsg like texturing works and also Blinn-Phong shading does.
Is this with shaders that are compiled from GLSL to SPIR-V by the VSG/glsLang or preexisting SPIR-V shaders?
Do you get an error when running the shaders on other machines i.e. linux/windows?
The first failing commits could not be built in this configuration:
[4/42] Building CXX object src/vsg/CMakeFiles/vsg.dir/rtx/AccelerationGeometry.cpp.o FAILED: src/vsg/CMakeFiles/vsg.dir/rtx/AccelerationGeometry.cpp.o /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DGLSLANG_ResourceLimits_maxDualSourceDrawBuffersEXT -DHAS_GLSLANG -I/Users/rainerge/VSGTEST/may-12-1/VulkanSceneGraph/include -Iinclude -isystem /usr/local/include -O3 -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk -fPIC -std=gnu++17 -MD -MT src/vsg/CMakeFiles/vsg.dir/rtx/AccelerationGeometry.cpp.o -MF src/vsg/CMakeFiles/vsg.dir/rtx/AccelerationGeometry.cpp.o.d -o src/vsg/CMakeFiles/vsg.dir/rtx/AccelerationGeometry.cpp.o -c /Users/rainerge/VSGTEST/may-12-1/VulkanSceneGraph/src/vsg/rtx/AccelerationGeometry.cpp /Users/rainerge/VSGTEST/may-12-1/VulkanSceneGraph/src/vsg/rtx/AccelerationGeometry.cpp:29:61: error: assigning to 'VkDeviceAddress' (aka 'unsigned long long') from incompatible type 'nullptr_t' _geometry.geometry.triangles.vertexData.deviceAddress = VK_NULL_HANDLE; ^
~~~~~ /usr/local/include/vulkan/vulkan_core.h:40:36: note: expanded from macro 'VK_NULL_HANDLE'define VK_NULL_HANDLE nullptr
Later configs can be built, but this is probably not what we want now.
I've checked in fixes for this build issue when working with VulkanSDK-1.2.176.1 Just replacing the problem VK_NULL_HANDLE usage with 0.
Our pbr shader is actually pretty simplistic and has to be reworked yet. So this is not what we like, but a reason to look at it again and has nothing to do with the vsg/mac issues.
I don't know if this might be a factor, but one of the changes I had to make to get the Khronos ray tracing working was:
https://github.com/vsg-dev/VulkanSceneGraph/commit/5b6b6658a7ee2e9e11f89f4af35ce0e5d21a7265
Changing SPIR-V target from glslang::EShTargetSpv_1_0 to EShTargetSpv_1_4.. I guess this might have an effect if the version you are using is using the VSG to compile GLSL to SPIR-V and has this change.
Cheers, Robert.
Earlier I wrote:
"The only change to vsg::Instance that is now crashing was the assignment of VkApplicationInfo.apiVersion = vulkanVersion, which before was hardwarired to VK_API_VERSION_1_0.
The value is supplied by WindowTraits.vulkanVersion which also defaults to VK_VERSION_1_0 so I wouldn't expect this to be an issue."
On hunting down a vulkan debug layer error report seen with vsgimgui on Linux I found at that setting WindowTraits.vulkanVersion to VK_VERSION_1_0 is not equivalent to setting it to VK_API_VERSION_1_0. I've now fixed this and checked it with this commit:
62e4030b7465b03e4a0f3f1d18c094b0e7562c81
Could you update to the latest VSG master to see if this fix helps under macOS. Thanks.
Thanks a lot, that was an important fix. All vsg related demos work again, if at all supported on the Mac. The special problem with pbr shaders remains with Vulkan 1.2.176 on the Mac. On Windows it runs normally. Looks we can close this issue.
Wow, thank goodness for that. Thanks for the testing.
On Thu, 20 May 2021 at 16:07, Rainer Gericke @.***> wrote:
Thanks a lot, that was an important fix. All vsg related demos work again, if at all supported on the Mac. The special problem with pbr shaders remains with Vulkan 1.2.176 on the Mac. On Windows it runs normally. Looks we can close this issue.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/vsg-dev/VulkanSceneGraph/issues/283#issuecomment-845204188, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKEGUEOPIH2BQ2XBC3L4G3TOUQS3ANCNFSM45EAQEGA .
Describe the bug Purely text based programs like vsgarrays, vsgio work.
To Reproduce Steps to reproduce the behavior:
Expected behavior Should open a window and display the scenegraph
Screenshots Dump file for vsgdraw appending.
Desktop (please complete the following information):
Smartphone (please complete the following information):
Additional context Khronos Vulkan Samples run well (the ones that are supported on the Mac) VulkanSDK 1.2.176.1 VulkanSDK 1.2.170.0 - worked until few days ago dump.txt