Preparing for new developer releases of VulkanSceneGraph, vsgXchange and vsgExample please test :-) #1280
Replies: 22 comments 23 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.
-
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