Preparing for new developer releases of VulkanSceneGraph, vsgXchange and vsgExample please test :-) #1280
Replies: 29 comments 40 replies
-
|
Hi Robert, I made a few tests today. There some serious problems on my system (MacOS 15, Vulkan 1.3.290). |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the testing @rainergericke. The issues look related to the DatabasePager/DeleteQueue, in general I'd look at a race condition for this type of functionality. @rolandhill and I collaborated on a drawn out test/fix round that was related to the DatabasePager/TransferTask/RecordAndSubmitTask and my assumption is that we hammered the paging functionality pretty hard until they looked to be working solidly, so I'm surprised by the new issues you are seeing - we didn't come across any crashes related to DeleteQueue. How quickly are the paging examples like vsghelloworld and vsgtiledatabase crashing? Do you see any visuals on screen? I have just run vsgsubpass is on this Kubuntu 24.04/Intel iCore7/Xe laptop and visually it's fine but when I run with Vulkan Validation Layer enabled I see the following format mismatch error: $ vsgsubpass -d
VUID-VkFramebufferCreateInfo-pAttachments-00880(ERROR / SPEC): msgNum: 449121544 - Validation Error: [ VUID-VkFramebufferCreateInfo-pAttachments-00880 ] Object 0: handle = 0x20000000002, type = VK_OBJECT_TYPE_RENDER_PASS; Object 1: handle = 0x2d000000002d, type = VK_OBJECT_TYPE_IMAGE_VIEW; | MessageID = 0x1ac50d08 | vkCreateFramebuffer(): pCreateInfo->pAttachments[1] has format of VK_FORMAT_D32_SFLOAT that does not match the format of VK_FORMAT_D24_UNORM_S8_UINT used by the corresponding attachment for VkRenderPass 0x20000000002[]. The Vulkan spec states: If flags does not include VK_FRAMEBUFFER_CREATE_IMAGELESS_BIT, each element of pAttachments must have been created with a VkFormat value that matches the VkFormat specified by the corresponding VkAttachmentDescription in renderPass (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkFramebufferCreateInfo-pAttachments-00880)
Objects: 2
[0] 0x20000000002, type: 18, name: NULL
[1] 0x2d000000002d, type: 14, name: NULL
VUID-VkFramebufferCreateInfo-pAttachments-00880(ERROR / SPEC): msgNum: 449121544 - Validation Error: [ VUID-VkFramebufferCreateInfo-pAttachments-00880 ] Object 0: handle = 0x20000000002, type = VK_OBJECT_TYPE_RENDER_PASS; Object 1: handle = 0x2d000000002d, type = VK_OBJECT_TYPE_IMAGE_VIEW; | MessageID = 0x1ac50d08 | vkCreateFramebuffer(): pCreateInfo->pAttachments[1] has format of VK_FORMAT_D32_SFLOAT that does not match the format of VK_FORMAT_D24_UNORM_S8_UINT used by the corresponding attachment for VkRenderPass 0x20000000002[]. The Vulkan spec states: If flags does not include VK_FRAMEBUFFER_CREATE_IMAGELESS_BIT, each element of pAttachments must have been created with a VkFormat value that matches the VkFormat specified by the corresponding VkAttachmentDescription in renderPass (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkFramebufferCreateInfo-pAttachments-00880)
Objects: 2
[0] 0x20000000002, type: 18, name: NULL
[1] 0x2d000000002d, type: 14, name: NULL
VUID-VkFramebufferCreateInfo-pAttachments-00880(ERROR / SPEC): msgNum: 449121544 - Validation Error: [ VUID-VkFramebufferCreateInfo-pAttachments-00880 ] Object 0: handle = 0x20000000002, type = VK_OBJECT_TYPE_RENDER_PASS; Object 1: handle = 0x2d000000002d, type = VK_OBJECT_TYPE_IMAGE_VIEW; | MessageID = 0x1ac50d08 | vkCreateFramebuffer(): pCreateInfo->pAttachments[1] has format of VK_FORMAT_D32_SFLOAT that does not match the format of VK_FORMAT_D24_UNORM_S8_UINT used by the corresponding attachment for VkRenderPass 0x20000000002[]. The Vulkan spec states: If flags does not include VK_FRAMEBUFFER_CREATE_IMAGELESS_BIT, each element of pAttachments must have been created with a VkFormat value that matches the VkFormat specified by the corresponding VkAttachmentDescription in renderPass (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkFramebufferCreateInfo-pAttachments-00880)
Objects: 2
[0] 0x20000000002, type: 18, name: NULL
[1] 0x2d000000002d, type: 14, name: NULLPerhaps this mismatch is what is causing issues on your machine. |
Beta Was this translation helpful? Give feedback.
-
|
vsgsubpass -d VUID-VkSubpassDescription2-pDepthStencilAttachment-02900(ERROR / SPEC): msgNum: 1872834363 - Validation Error: [ VUID-VkSubpassDescription2-pDepthStencilAttachment-02900 ] | MessageID = 0x6fa12f3b | vkCreateRenderPass2(): pCreateInfo->pAttachments[1].format (VK_FORMAT_D24_UNORM_S8_UINT) format features are VkFormatFeatureFlags2(0) (referenced by pCreateInfo->pSubpasses[0].pDepthStencilAttachment). The Vulkan spec states: If pDepthStencilAttachment is not NULL and the attachment is not VK_ATTACHMENT_UNUSED then it must have an image format whose potential format features contain VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT (https://vulkan.lunarg.com/doc/view/1.3.290.0/mac/1.3-extensions/vkspec.html#VUID-VkSubpassDescription2-pDepthStencilAttachment-02900) vsghelloworld vsgtiledatabase |
Beta Was this translation helpful? Give feedback.
-
|
What happens when you run: vsgviewer models/lz.vsgt
vsgviewer modles/openstreetmap.vsgtThe first is just straight loading of a static model, when the second uses vsg::TileDatabase & vsg::DatabasePager so I'm expecting the same issues as vsgtiledatabase + vsgpagedlod. It's really odd how vsgtiledatabase etc. are failing so early, especially as Windows 11 and Kubuntu 2x.xx are currently working without a hint of issue. |
Beta Was this translation helpful? Give feedback.
-
|
vsgviewer models/lz.vsgt runs fine. |
Beta Was this translation helpful? Give feedback.
-
|
I now have my new AMD8700G system working with a Geforce 1650 under Kubuntu 24.04.1 with the NVidia drivers and have got a hang in vsgtiledatabase if I move from location to location by pressing the 1 through 9 keys and then minimizing the window. It doesn't happen every time but occasionally it hangs. I didn't see this problem earlier in the week with my previously working AMD 5700G + Kubuntu 22.04 system or my Windows 11 system with a Geforce 2060, but as the code hasn't changed, only my hardware/OS/drivers I think it's most likely it's a prexisting race condition that has been lurking. At this point there is no way of knowing whether this is the same race condition that @rainergericke has seen when loading paged models/paged examples but hopefully it is as I don't have a macOS system to test it against. |
Beta Was this translation helpful? Give feedback.
-
|
I have rebuilt the VSG with debug info and ran vsgtiledatabase in gdb and got it hang by pressing 1 then 2 and minimzing the window then unminizing the window. No crash happens, it's just hanging, breaking the run gdb shows the main thread is sitting waiting on a fence: #0 0x00007ffff531b4cd in __GI___poll (fds=0x5555571aaa80, nfds=1, timeout=10) at ../sysdeps/unix/sysv/linux/poll.c:29
#1 0x00007fffe3607ae3 in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.550.107.02
#2 0x00007fffe3a22e79 in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.550.107.02
#3 0x00007fffe3a07870 in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.550.107.02
#4 0x00007fffe392383e in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.550.107.02
#5 0x00005555557a838d in vsg::Fence::wait (this=0x7ffff038b6b4, timeout=18446744073709551615) at /home/robert/dev/VulkanSceneGraph/src/vsg/vk/Fence.cpp:61
#6 0x0000555555746547 in vsg::RecordAndSubmitTask::start (this=0x7ffff038b5b8) at /home/robert/dev/VulkanSceneGraph/src/vsg/app/RecordAndSubmitTask.cpp:127
#7 0x000055555574625c in vsg::RecordAndSubmitTask::submit (this=0x7ffff038b5b8, frameStamp=...) at /home/robert/dev/VulkanSceneGraph/src/vsg/app/RecordAndSubmitTask.cpp:89
#8 0x000055555570031a in vsg::Viewer::recordAndSubmit (this=0x7ffff038915c) at /home/robert/dev/VulkanSceneGraph/src/vsg/app/Viewer.cpp:836
#9 0x0000555555687f8f in main (argc=1, argv=0x7fffffffd928) at /home/robert/dev/vsgExamples/examples/nodes/vsgtiledatabase/vsgtiledatabase.cpp:255While the DatabasePager readThread looks to be just going about it's business: ownload failed: Invalid argument. Continuing without source file ./nptl/./nptl/futex-internal.c.
#0 0x00007ffff5298d61 in __futex_abstimed_wait_common64 (private=-1409203808, cancel=true, abstime=0x7fffcddfebe0, op=137, expected=0, futex_word=0x7ffff038fc44) at ./nptl/futex-internal.c:57
warning: 57 ./nptl/futex-internal.c: No such file or directory
(gdb) where
#0 0x00007ffff5298d61 in __futex_abstimed_wait_common64 (private=-1409203808, cancel=true, abstime=0x7fffcddfebe0, op=137, expected=0, futex_word=0x7ffff038fc44) at ./nptl/futex-internal.c:57
#1 __futex_abstimed_wait_common (cancel=true, private=-1409203808, abstime=0x7fffcddfebe0, clockid=32767, expected=0, futex_word=0x7ffff038fc44) at ./nptl/futex-internal.c:87
#2 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x7ffff038fc44, expected=expected@entry=0, clockid=clockid@entry=1, abstime=abstime@entry=0x7fffcddfebe0,
private=private@entry=0) at ./nptl/futex-internal.c:139
#3 0x00007ffff529c106 in __pthread_cond_wait_common (abstime=<optimised out>, clockid=<optimised out>, mutex=0x7ffff038fbf4, cond=0x7ffff038fc1c) at ./nptl/pthread_cond_wait.c:503
#4 ___pthread_cond_clockwait64 (abstime=<optimised out>, clockid=<optimised out>, mutex=0x7ffff038fbf4, cond=0x7ffff038fc1c) at ./nptl/pthread_cond_wait.c:691
#5 ___pthread_cond_clockwait64 (cond=0x7ffff038fc1c, mutex=0x7ffff038fbf4, clockid=<optimised out>, abstime=<optimised out>) at ./nptl/pthread_cond_wait.c:679
#6 0x00005555556f27b1 in std::__condvar::wait_until (this=0x7ffff038fc1c, __m=..., __clock=1, __abs_time=...) at /usr/include/c++/13/bits/std_mutex.h:185
#7 0x00005555556f40fc in std::condition_variable::__wait_until_impl<std::chrono::duration<long, std::ratio<1l, 1000000000l> > > (this=0x7ffff038fc1c, __lock=...,
__atime=std::chrono::_V2::steady_clock time_point = { 2917469174980ns }) at /usr/include/c++/13/condition_variable:203
#8 0x00005555556f3c69 in std::condition_variable::wait_until<std::chrono::duration<long, std::ratio<1l, 1000000000l> > > (this=0x7ffff038fc1c, __lock=...,
__atime=std::chrono::_V2::steady_clock time_point = { 2917469174980ns }) at /usr/include/c++/13/condition_variable:113
#9 0x00005555556f36d2 in std::condition_variable::wait_for<long, std::ratio<1l, 1000l> > (this=0x7ffff038fc1c, __lock=..., __rtime=std::chrono::duration = { 100ms })
at /usr/include/c++/13/condition_variable:165
#10 0x00005555558a06a4 in vsg::DatabaseQueue::take_when_available (this=0x7ffff038fbdc) at /home/robert/dev/VulkanSceneGraph/src/vsg/io/DatabasePager.cpp:63
#11 0x00005555558a1005 in operator() (__closure=0x555556e82678, requestQueue=..., status=..., databasePager=..., threadName="DatabasePager read thread 0")
at /home/robert/dev/VulkanSceneGraph/src/vsg/io/DatabasePager.cpp:150
#12 0x00005555558a4347 in std::__invoke_impl<void, vsg::DatabasePager::start(uint32_t)::<lambda(vsg::ref_ptr<vsg::DatabaseQueue>, vsg::ref_ptr<vsg::ActivityStatus>, vsg::DatabasePager&, const std::string&)>, std::reference_wrapper<vsg::ref_ptr<vsg::DatabaseQueue> >, std::reference_wrapper<vsg::ref_ptr<vsg::ActivityStatus> >, std::reference_wrapper<vsg::DatabasePager>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >(std::__invoke_other, struct {...} &&) (__f=...) at /usr/include/c++/13/bits/invoke.h:61
#13 0x00005555558a407f in std::__invoke<vsg::DatabasePager::start(uint32_t)::<lambda(vsg::ref_ptr<vsg::DatabaseQueue>, vsg::ref_ptr<vsg::ActivityStatus>, vsg::DatabasePager&, const std::string&)>, std::reference_wrapper<vsg::ref_ptr<vsg::DatabaseQueue> >, std::reference_wrapper<vsg::ref_ptr<vsg::ActivityStatus> >, std::reference_wrapper<vsg::DatabasePager>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >(struct {...} &&) (__fn=...) at /usr/include/c++/13/bits/invoke.h:96I'm not running vsgtiledatabase multi-threaded so it's just the main thread, the databases thread and any threads that libcurl is spawning. By current best guess is the main thread hanging on a vkFence suggests that a previous frame has submitted work with a semaphore that hasn't been signaled so that previous frame simply hasn't completed. I will try out the Vulkan validation layers to see if that can provide any further insight. As things stand I don't think this is related to the crash under macOS that @rainergericke has found. |
Beta Was this translation helpful? Give feedback.
-
|
As quick test I commented out the following code block in Viewer::compile() that sets up a dedicated Transfer Queue for the TransferTask and since vsgtiledatabase hasn't hung me yet. VkQueueFlags transferQueueFlags = VK_QUEUE_TRANSFER_BIT | VK_QUEUE_GRAPHICS_BIT; // use VK_QUEUE_GRAPHICS_BIT to ensure we can blit images
for (auto& queue : device->getQueues())
{
if ((queue->queueFlags() & transferQueueFlags) == transferQueueFlags)
{
if (queue != mainQueue)
{
transferQueue = queue;
break;
}
}
}Only the NVidia hardware/drivers have been meeting the criteria that to set up a dedicated transfer queue so this particular problem might only be seen on NVidia hardware/drivers. @rainergericke what are the hardware specks of the machine(s) you've used in your macOS testing? Might it be also enabling the dedicated transfer queue? |
Beta Was this translation helpful? Give feedback.
-
|
Here is the output of vulkaninfo, hope it is helpful. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it is the driver coming with MacOS/Vulkan/MoltenVK actually. |
Beta Was this translation helpful? Give feedback.
-
|
When was the MoltenVK driver last updated? |
Beta Was this translation helpful? Give feedback.
-
|
It came together with Vulkan 1.3.290. |
Beta Was this translation helpful? Give feedback.
-
|
The version listed in your vailkaninfo is older than the 1.3.290 so I presume they aren't updating MoltenVK as often, or there's a lag. |
Beta Was this translation helpful? Give feedback.
-
|
The actual version of MoltenVK is 1.2.10. It's indeed not part of Vulkan 1.3.290 due to stability issues. |
Beta Was this translation helpful? Give feedback.
-
|
I haven't checked it in yet, as I haven't set my new machine up to check stuff into the repo, but here's the debug output I've added to VulkanSceneGraph/src/vg/app/Viewer.cpp to show the setup of the main queue used for rendering and transfer queue: $ git diff HEAD~
diff --git a/src/vsg/app/Viewer.cpp b/src/vsg/app/Viewer.cpp
index 6f114356..287e586d 100644
--- a/src/vsg/app/Viewer.cpp
+++ b/src/vsg/app/Viewer.cpp
@@ -513,6 +513,8 @@ void Viewer::assignRecordAndSubmitTaskAndPresentation(CommandGraphs in_commandGr
}
}
+ info("Viewer::compile() mainQueue = ", mainQueue, " transferQueue : ", transferQueue);
+
if (deviceQueueFamily.presentFamily >= 0)
{
// collate all the unique Windows associated with this device's commandGraphsOn this new Kubuntu 24.04.1 AMD8700G + Geforece 1650 I seeing: $ vsgtiledatabase
info: Viewer::compile() mainQueue = ref_ptr<vsg::Queue>(vsg::Queue 0x7abfb71a034c) transferQueue : ref_ptr<vsg::Queue>(vsg::Queue 0x7abfb71a03a8) |
Beta Was this translation helpful? Give feedback.
-
|
@rainergericke I don't think think the vsgtiledatabase issues I've seen on my AMD8700G+Geforece1650 system are related to the crash you have seen, so the I am limited in what I can do to investigate what is going wrong, so I'll need to rely upon you to provide what insights you can. Stack trace of the times when it crashes will be really help. Did the 1.1.7 dev release work fine on macOS? I think the error with vsgsubpass is something I and others can investigate as I have Vulkan debug error to go off. |
Beta Was this translation helpful? Give feedback.
-
|
Short prelaminary answer: vsgtiledatabase, vsgpagedlod and vsgtextureprojection didn't work on macOS with VSG 1.1.7 release too. I will try to get more details tomorrow. |
Beta Was this translation helpful? Give feedback.
-
|
Here come test results from VSG 1.1.7 and vsgExamples 1.1.5. vsgtiledatabase -a vsgtiledatabase |
Beta Was this translation helpful? Give feedback.
-
|
Error report: |
Beta Was this translation helpful? Give feedback.
-
|
Has vsgtiledatabase ever worked on macOS? If so do you know how long ago it worked? The fact errors are occurring before the current Compile_Using_TransferTask was merged with VSG master suggests there's a more general issue that has been resolved by this issue, but this work hasn't necessary cased more new problems. |
Beta Was this translation helpful? Give feedback.
-
|
I am not sure. In projectchrono we use VSG just for a while as 3D library, but we havn't ever used this functionality. I could try a few older releases of VSG. |
Beta Was this translation helpful? Give feedback.
-
|
I just tested two older configurations and saw
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the detective work. The key change of VulkanSceneGraph v1.1.5 was the use of an external glslang. Are you building against glslang? If so which version? If you aren't building against glslang then perhaps compiling glslang from source and then configuring and building the VSG would provide some additional insight. Given the problems you are seeing didn't start with the merge of the Compile_Using_TransferTask/v.1.1.8 I'm inclined towards making v.1.1.8 and working on resolving the macOS issues after. Thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
I built vsg against glslang (not the one included in the Vulkan SDK!): I tried today VSG 1.1.5 and 1.1.6. The latter one introduces the crashes on the Mac, while 1.1.5 is okay. It's also okay to push the macOS fixed a bit behind, since we are not directly concerned. |
Beta Was this translation helpful? Give feedback.
-
|
It looks like it should be building fine. Is the VSG configure reporting glslang support? Could post the generated Version.h? This is he version I have currently on this newly setup Kubuntu 24.04 system: $ glslang --version
Glslang Version: 11:14.0.0
ESSL Version: OpenGL ES GLSL 3.20 glslang Khronos. 14.0.0
GLSL Version: 4.60 glslang Khronos. 14.0.0
SPIR-V Version 0x00010600, Revision 1
GLSL.std.450 Version 100, Revision 1
Khronos Tool ID 8
SPIR-V Generator Version 11
GL_KHR_vulkan_glsl version 100
ARB_GL_gl_spirv version 100I still haven't fully configured this new machine for development but am getting there. However, its no substitute for having a macOS machine when trying to figure out what has caused the regression. Looking at VulkanSceneGraph v1.1.6 vs 1.1.5 the big change was the new IntrusiveAllocator: https://github.com/vsg-dev/VulkanSceneGraph/releases/tag/v1.1.6 Perhaps it's the new allocator that is causing problems. The code is just C++ so it's not something I'd expect would cause different issues on different platforms. |
Beta Was this translation helpful? Give feedback.
-
|
Actually I have VSG v.1.1.6. This is Version.h: |
Beta Was this translation helpful? Give feedback.
-
|
My test results on a Windows 11 desktop system: I tried the bleeding edge version of the vsg libs. Problems (not complete): It's a bit suprpising because it does not happen on your Windows machine, doesn't it? |
Beta Was this translation helpful? Give feedback.
-
|
I don't recall issues, but have just booted up my Windows machine to check what I see with these examples. My Windows 11 system is an Intel iCore7 + Geforce 2060. Could you run these problem examples with -d on the command line to see if the Vulkan Validation Layer picks up any issues? |
Beta Was this translation helpful? Give feedback.
-
|
vsghelloworld -d does nothing, no window, no errormessage |
Beta Was this translation helpful? Give feedback.
-
|
I have run just run: vsgdynamicwindows -dOn my new Kubuntu 24.04 + ADM 8700G + Gefore 1650 systems and get a stream of the following Vulkan Validation Layer issues reported: Objects: 2
[0] 0x5e755fec1f90, type: 6, name: NULL
[1] 0xe000000000e0, type: 10, name: NULL
UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout(ERROR / SPEC): msgNum: 1303270965 - Validation Error: [ UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0: handle = 0x5e755fec1f90, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0xe000000000e0, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x4dae5635 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[2] command buffer VkCommandBuffer 0x5e755fec1f90[] expects VkImage 0xe000000000e0[] (subresource: aspectMask 0x1 array layer 0, mip level 7) to be in layout VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL--instead, current layout is VK_IMAGE_LAYOUT_UNDEFINED.
Objects: 2
[0] 0x5e755fec1f90, type: 6, name: NULL
[1] 0xe000000000e0, type: 10, name: NULL
UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout(ERROR / SPEC): msgNum: 1303270965 - Validation Error: [ UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0: handle = 0x5e755fec1f90, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0xe000000000e0, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x4dae5635 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[2] command buffer VkCommandBuffer 0x5e755fec1f90[] expects VkImage 0xe000000000e0[] (subresource: aspectMask 0x1 array layer 0, mip level 8) to be in layout VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL--instead, current layout is VK_IMAGE_LAYOUT_UNDEFINED.
Objects: 2
[0] 0x5e755fec1f90, type: 6, name: NULL
[1] 0xe000000000e0, type: 10, name: NULLWhich might be a lead for the issues with vsgdynamicwindows. |
Beta Was this translation helpful? Give feedback.
-
|
I have just tried vsgdynamicwindows on my Windows 11 system and also see 2 small windows hung, but with valid graphics, with wait icons while the first window fully functioning with it responding to mouse and keyboard controls. I tried the vsgqtmdi and vsgqtwindows examples from vsgQt and they both work fine. vsgwindows from vsgExamples also works correctly so it doesn't look to be a general multiple window issue, but something connected to how vsgdynamicwindows is presently manage things. |
Beta Was this translation helpful? Give feedback.
-
|
@rainergericke wrote:
I have tried both vsghelloworld and vsgpagedload on my system and they work. Is there any chance that you don't have vsgXchange built against libcurl? On my system when I run vsgconv with --features I get a listing of the curl loader. > vsgconv --features vsgXchange::curl
vsgXchange::curl provides support for 0 extensions, and 2 protocols.
Protocols Supported ReaderWriter methods
---------- ------------------------------
http read(vsg::Path, ..)
https read(vsg::Path, ..)
vsg::Options::Value type
------------------- ----
CURLOPT_SSL_OPTIONS uint32_t |
Beta Was this translation helpful? Give feedback.
-
|
Progress :-) What exactly do you mean by "vsgdynamicwindows is endlessly loading the openstreetmap model" ? |
Beta Was this translation helpful? Give feedback.
-
|
Without libcurl vsgdynamicwindows cannot load openstreemap.vsgt, but seems to try, symbolized by a rotating cursor symbol. It will run for ever. With libcurl I can see a black circle and the cursor is running again. The sceenshot does not show the cursor. |
Beta Was this translation helpful? Give feedback.
-
|
Starting vsgdynamicwindows several times I could see the earth like in vsghelloworld, but it is quickly covered by the black ball. vsgvolume shows a nice model but produces error messages: |
Beta Was this translation helpful? Give feedback.
-
|
The black earth is expected, the vsgdynamicwindows is probably not enabling lighting and it's loading a model that is relying upon it. I will look into this. |
Beta Was this translation helpful? Give feedback.
-
|
I have looked into vsgdynamicwindows and it is correctly setting up lighting so the black earth is not caused by not adding the required vsg::Light to the view. Experimenting with this example, if I assign the models/openstreetmap.vsgt first and disable adding the multi-threaded adding of additional windows + view I find that the earth model loads correctly with lighting on as you'd see in 'vsgviewer models/openstreetmap.vsgt'. Added even just one multi-threaded window add causes the black earth, and briefly you actually see the correctly textured and lit earth in the first window before the second window is created but as soon as the second window comes on the first window with the earth model goes black immediately. If I run vsgmultiwindows with -d to enable the Vulkan Validation Layer it runs without warnings if just the first window is created, but if I add the second window it starts generated Vulkan errors in form: [1] 0x7e000000007e, type: 10, name: NULL
UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout(ERROR / SPEC): msgNum: 1303270965 - Validation Error: [ UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0: handle = 0x569f305a5200, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x7e000000007e, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x4dae5635 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] command buffer VkCommandBuffer 0x569f305a5200[] expects VkImage 0x7e000000007e[] (subresource: aspectMask 0x1 array layer 0, mip level 6) to be in layout VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL--instead, current layout is VK_IMAGE_LAYOUT_UNDEFINED.
Objects: 2
[0] 0x569f305a5200, type: 6, name: NULL
[1] 0x7e000000007e, type: 10, name: NULL
UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout(ERROR / SPEC): msgNum: 1303270965 - Validation Error: [ UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0: handle = 0x569f305a5200, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x7e000000007e, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x4dae5635 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] command buffer VkCommandBuffer 0x569f305a5200[] expects VkImage 0x7e000000007e[] (subresource: aspectMask 0x1 array layer 0, mip level 7) to be in layout VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL--instead, current layout is VK_IMAGE_LAYOUT_UNDEFINED.
Objects: 2
[0] 0x569f305a5200, type: 6, name: NULL
[1] 0x7e000000007e, type: 10, name: NULL
UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout(ERROR / SPEC): msgNum: 1303270965 - Validation Error: [ UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0: handle = 0x569f305a5200, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x7e000000007e, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x4dae5635 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] command buffer VkCommandBuffer 0x569f305a5200[] expects VkImage 0x7e000000007e[] (subresource: aspectMask 0x1 array layer 0, mip level 8) to be in layout VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL--instead, current layout is VK_IMAGE_LAYOUT_UNDEFINED.
Objects: 2
[0] 0x569f305a5200, type: 6, name: NULL
[1] 0x7e000000007e, type: 10, name: NULLIt seems likely that this is associated with the earth model going black. |
Beta Was this translation helpful? Give feedback.
-
|
Actually I found a vsg build issue on macOS. When using vsgFramework vsg is built without glslang support even when glslang is present (installed via homebrew). The reason is glsslang has version 15.0.0 now, which seems to be incompatible whith vsg. Homebrew does not support the installation of older versions of glslang. So the best solution is to make an own build of glslang version 14.3.0. My actual hints for macOS are obsolete now. |
Beta Was this translation helpful? Give feedback.
-
|
vsgFramework needs some work to handle the peculiarities of glslang out in the wild in various versions. When I made glslang external I spent some time on it but not enough time to figure out how best to proceed. That will have to wait as I have enough other stuff to fix... When you say 15.0.0 seems incompatible with the VSG, what were the issues? We'll need to resolve these. |
Beta Was this translation helpful? Give feedback.
-
|
When configuring VSG there is a Cmake message like: glslang version not accepted. |
Beta Was this translation helpful? Give feedback.
-
|
Curious, the cmake looks like it should just set the minimum of 14, rather than just accept 14.x. # Enable/disable shader compilation support that pulls in glslang
set(VSG_SUPPORTS_ShaderCompiler 1 CACHE STRING "Optional shader compiler support, 0 for off, 1 for enabled." )
if (VSG_SUPPORTS_ShaderCompiler)
set(GLSLANG_MIN_VERSION "14" CACHE STRING "glslang 14 is the earliest version that we think installs itself properly on all platforms. Other platforms may be able to use an earlier version")
find_package(glslang ${GLSLANG_MIN_VERSION} CONFIG)
if (glslang_FOUND)
set(FIND_DEPENDENCY_glslang "find_package(glslang ${GLSLANG_MIN_VERSION} CONFIG REQUIRED)")
else()
message(WARNING "glslang not found. ShaderCompile support disabled.")
set(VSG_SUPPORTS_ShaderCompiler 0)
set(FIND_DEPENDENCY_glslang "")
endif()
else()
set(FIND_DEPENDENCY_glslang "")
endif() |
Beta Was this translation helpful? Give feedback.
-
|
I have found some time today to play with the CMakeLists.txt in vsgFramework. My first idea was to test if vsg works with glslang v15.x.x at all - fortunately it does. Setting GLSLANG_MIN_VERSION to "15" does the job. I wasn't able to set a range for GLSLANG_MIN_VERSION as shown in the cmake documentation yet. Cmake will ignore glslang versions < 15, so version 14 is not accepted any more and vice versa. A version range could be set(GLSLANG_MIN_VERSION "14...15"), but it is not accepted. Do you have an idea? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the testing, a curious finding. Could this be done to the maturity of the cmake config support available in 14.x vs 15.x? While not ideal perhaps vsgFramework working with glslang 15.x would OK, as the worst thing that happens would be ignoring a local 14.x glslang and just building a local 15.x one. |
Beta Was this translation helpful? Give feedback.
-
|
A local glslang v14.x would break the configuration, when v15.x is demanded. If both is missing, the glslang&co sources are getting downloaded, but built after vsg. So vsg cannot recognize the freshly built glslang. |
Beta Was this translation helpful? Give feedback.
-
|
Would changing vsgFramework to always download and build glslang as part of vsgFramework help? |
Beta Was this translation helpful? Give feedback.
-
|
We should test it. |
Beta Was this translation helpful? Give feedback.
-
|
This morning I did various experiments with trying to get vsgFramework to accept the locally built glslang to no avail. I would have liked to resolve this before tagging VulkanSceneGraph-v1.1.8 but as I have other tasks to get on with I will need to leave vsgFramework aside for now. |
Beta Was this translation helpful? Give feedback.
-
|
As we discussed a few weeks ago, vsgFramework is known to be non-functional as it relies on being able to get and use glslang via FetchContent, which it doesn't support. It would need altering to get it via ExternalProject instead so that it's built during configure time and can be installed to a subdirectory that dependent projects can see when they're configured. I can probably do that fairly quickly if it's something we need, but it's not like glslang's a tricky project to build in the first place (libcurl and FreeType were the pain points on Windows for me), so I don't see a huge value add from vsgFramework existing in the first place. I've also had a look at why glslang 15.x is being rejected, and it looks like glslang is using CMake's default so it seems we can't explicitly state that we support a wider range than Once 14.x+ has propagated far enough, then we can probably make the problem go away by not specifying a required version at all, and then if we genuinely need to block out certain versions, we can check the value of |
Beta Was this translation helpful? Give feedback.
-
|
I'm ready to tag new developer releases of VulkanSceneGraph, vsgXchange, vsgImGui and vsgExamples, so would appreciate testing of the respective masters. I have one outstanding issue #1301 that I haven't got a way of reproducing at this point so if folks are seeing issues like this can you see if you can recreate it with the any examples so I can investigate at my end. Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
Testresults on macOS 15.0.1 / Vulkan 1.3.296 Only non-working examples are contained in this file: The image file can be viewed with vsgviewer but not be used with vsgtextureprojection. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the testing. Curious vsgtextureprojection with the bear model works fine for me with Kubuntu 24.04:
Doe vsgtextureprojection work for other images? For instance vsgExamples/data/textures/lz.rgb? The bus error you are seeing with the database paging examples, could you try to get a stack trace for them? |
Beta Was this translation helpful? Give feedback.
-
|
I'd second the suggestion to not get a bottom-end Mac. At a previous job I had the displeasure of having to interact with entry-level Macs that couldn't run their own desktop environment at an interactive framerate once security updates had been installed just two years after that model was released. |
Beta Was this translation helpful? Give feedback.
-
|
I've done a quick search, and the 2nd hand ones don't seem much cheaper than new. Looking at new is this the type of level that would be good enough to work with? How much work/time is it to get a full dev environment working for Vulkan/VulkanSceneGraph development? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it should do it. macOS is based on Unix (NetBSD as far as I know), so on the command line it works pretty much like Linux. The steps for configuration are:
Development can start in between 2 hours, maybe faster. |
Beta Was this translation helpful? Give feedback.
-
|
So I've ordered the above macbook, so I've dug myself a hole and tomorrow it should arrive and I'll trip into and my world will go all Alice in Wonderland while I set it up. I have other work that I need to get on with so this will have to be a side project. My intention is make this my laptop so will live and breath macOS for more recreational side and work on the go, my Linux and Windows desktop machines will need to remain my main work platforms as that's where my clients all are right now. |
Beta Was this translation helpful? Give feedback.
-
|
Let me know, if I can help. But I don't expect problems! |
Beta Was this translation helpful? Give feedback.
-
|
Windows 11, Intel i7-12650H, NVIDIA RTX 3050Ti, VulkanSDK-1.3.290 All examples work fine except vsgdynamicwindows. It shows one main window with two subwindows. The main one is active and controllable, but the sub-ones halted. The program can exit normally, but displays a few warning messages on terminal:
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the testing. I'm seeing issues with vsgdynamicwindows as well - it's a bit of niche test program as it's creating windows and views multi-threaded and adding them on the fly to the viewer. I don't know if we are seeing a regression under Windows or whether it's never worked. I'm seeing issues under Linux as well, but I think this might be a regression. As vsgdynamicwindows is such a unusual usage case I'll not prioritize getting it fixed for the developer release. |
Beta Was this translation helpful? Give feedback.
-
|
I've tested the latest VSG on an ARM board and get some good results... Phytium D2000+X100, GPU: Imagination AXT-16-512 Most examples can work perfectly, with 80-100 fps. |
Beta Was this translation helpful? Give feedback.
-
|
If you run 'vsgdeviceslection--extensions' you'll get a list of supported extensions, I presume these won't include mesh and ray tracing extensions. |
Beta Was this translation helpful? Give feedback.
-
Hi All,
This morning I wrapped up refactor of CompileTraversal/TransferTask/RecordAndSubmitTask & DatabasePager to enable the compile traversal to leverage the TransferTask for transferring data efficiently to the GPU. I originally thought this work would be wrapped up in 1 to 2 weeks but it's taken over 6 weeks to sort out the edge cases. The upside is database paging is now faster as load threads don't need to wait on a fence for data to be transferred to the GPU, instead can just defer this transfer work to TransferTask that is optimized for this work.
This work looks solid enough for wider community testing in prep for making a VulkanSceneGraph-1.1.8, vsgXchange-1.1.4 and vsgExamples 1.1.6 dev releases. I want to make sure these projects are all compiling and running fine on various platform and application usage combinations.
At my end I am testing under Windows 11 with Intel + Geforce 2060, and Kubuntu 24.04 + Intel iCore7 iGPU. My main Linux desktop system has decided to fry itself so for now can't test on it - I have taken the opportunity to fix the broken machine by upgrading motherboard, memory and CPU - so I'll have a lovely AMD 8700G system to test with replacing my previous AMD 5700G.
Please let me know of success or failures with build and runtime, thanks,
Robert.
Beta Was this translation helpful? Give feedback.
All reactions