vsgmultiviews is not ok about vsgexamples

[robertosfield]

Both:

vsgmultiviews models/lz.vsgt
vsgmultiviews models/lz.vsgt -s

Work correctly on my Kubuntu 22.04, AMD5700G system.

What VSG version, hardware, OS, VulkanSDK and Vulkan drivers are you using?

[robertosfield]

There has been a thread on the vsg-users google group about some users seeing problems with vsgmultiviews, best guess at this point is a NVidia driver bug on some hardware/OS combinations.

https://groups.google.com/g/vsg-users/c/mIV8v_MhrCo/m/MdAAzXISEQAJ?utm_medium=email&utm_source=footer

[bizehao]

vsg 1.0.0， system win11 22h2, nvidia 1070ti, vulkan sdk 1.3... vulkan drivers 1.1.
,cpu 12700

I just tested with the nuclear display. Although it will show, it will have a shadow

[robertosfield]

I suspect it's the same issue as reported on vsg-users., especially as it's same OS and type of hardware. Do you have any other machines to test against?

[bizehao]

My other notebook video card is nvidia 1060, and the first RenderGraph is not displayed

[robertosfield]

I can't do anything more myself so I've created a Discussion thread to request assistance from Windows users to see if they can provide any further insight,.

[bizehao]

I found the problem.
in RenderPass.cpp defaultColorAttachment

When I try to do colorAttachment.initialLayout = VK_IMAGE_LAYOUT_PRESENT_SRC_KHR;
The effect is correct，and vulkan give an error (It's inevitable)

UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout(ERROR / SPEC): msgNum: 1303270965 - Validation Error: [ UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0: handle = 0x19892d48dd8, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x4dae5635 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] command buffer VkCommandBuffer 0x19892d48dd8[] expects VkImage 0xd5b26f0000000010[] (subresource: aspectMask 0x1 array layer 0, mip level 0) to be in layout VK_IMAGE_LAYOUT_PRESENT_SRC_KHR--instead, current layout is VK_IMAGE_LAYOUT_UNDEFINED.

so, I think that after the first RenderGraph is rendered, when the second RenderGraph is rendered, the initialLayout of RenderPass is VK_ IMAGE_ LAYOUT_ UNDEFINED will be cleared, resulting in only the second RenderGraph

[bizehao]

Maybe when initialLayout is VK_IMAGE_LAYOUT_UNDEFINED, the renderArea range does not work

[robertosfield]

I have found the Vulkan debug layer has been reliable indicator of correct settings, so it's odd to get the correct result but an error.

Whether it's more likely that the driver is wrong, or the Valkan debug layer is wrong in this instance I can't say. This example works fine on other platforms combinations and doesn't generate any Vulkan debug layer errors so I'd be inclined towards assuming this is a driver bug.

The defaults used by the VSG are typically reflecting the ones suggested by Vulkan docks and examples. It may be that the defaults aren't appropriate for this particular usage case, but work on most platforms regardless and are normal enough that the vulkan debug layer is wrong.

Could you post a link to the modification you've made to get the rendering to work, this might help me investigate why your driver is happier with this change. For instance a commit to your local vsgExamples repo would be fine. Without this I'm not able to determine exactly what changes you made where.

[robertosfield]

I wonder if the NVidia driver requires the two RenderGraph need to be created with separate RenderPass in a more dependent way rather than as two independent RenderGraph/RenderPass.

It may worth looking for non VSG Vulkan examples that attempt this mulitple viewports.

[640kb]

Here on my Windows System, both

vsgmultiviews models/lz.vsgt
vsgmultiviews models/lz.vsgt -s

works correctly.

vsgmultiviews models\teapot.vsgt -s

Windows 10
VulkanSDK 1.3.231.1
NVidia Quadro T1000 with driver 511.79

[bizehao]

I think it is really the problem of the underlying driver implementation. I use the native Vulkan API to achieve the same effect。

[robertosfield]

Could it be a Windows 11 vs 10 driver issue with NVidia?

If the problem is occurring with other Vulkan based applications that do a similar thing then it does add strength to the idea that it's a driver rather than a VSG issue,

If it's a driver issue is it time to close this Issue?

[bizehao]

     Yes, I will use multi view instead of multi rendergraph and wait for the driver to repair.

[bizehao]

I found a solution by referring to the example of GPUOpen-Archive Anvil, I think it can be done in this way. Wait a moment. I will submit an example later.

Do you think I'm submitting a VulkanSceneGraph
PR, or add an example of vsgExamples

[robertosfield]

Great to hear you've found some thing that looks promising.

Once you have something working you can generate a PR against vsgExamples or VulkanSceneGraph. Even if it's not something suitable for merging right away I should be able glean the key features and figure out a final commit to which ever place is most appropriate.

So please just dive in and post something even if it's a bit rough and ready, you can treat it as sharing knowledge of what you've found to work rather than trying to worry about perfecting it right away.

[bizehao]

ok,Thank you for the encouragement, I will finish it soon

[robertosfield]

@bizehao I have just wrapped my client work and admin for 2022! So can look into this issue now. I am just started to look at Anvil. If you have something ported to the VSG already then this would help speed things up.

As a general though, if it's possible to enable the Vulkan API debug layer for the Anvil multiview example it should be possible capture all the Vulkan functions and settings and then we could ruin vsgmultiview and capture the output and then compare the parts setting up the RenderPass.

[robertosfield]

I'm getting compile errors when I attempt to compile Anvil, looks like the code is rather unmaintained under Linux.

[robertosfield]

I commented out the code in Anvil that was causing the compile errors and got everything compiled, hacky but I am just try to get a quick look. When I run the MultiViewport example I get a crash:

Thread 1 "MultiViewport" received signal SIGSEGV, Segmentation fault.
0x0000555555c2f4b2 in std::less::operator()(unsigned int const&, unsigned int const&) const ()
(gdb) where
#0 0x0000555555c2f4b2 in std::less::operator()(unsigned int const&, unsigned int const&) const ()
#1 0x0000555555cdddab in std::_Rb_tree<unsigned int, std::pair<unsigned int const, std::vector<Anvil::Queue*, std::allocatorAnvil::Queue* > >, std::_Select1st<std::pair<unsigned int const, std::vector<Anvil::Queue*, std::allocatorAnvil::Queue* > > >, std::less, std::allocator<std::pair<unsigned int const, std::vector<Anvil::Queue*, std::allocatorAnvil::Queue* > > > >::_M_lower_bound(std::_Rb_tree_node<std::pair<unsigned int const, std::vector<Anvil::Queue*, std::allocatorAnvil::Queue* > > > const*, std::_Rb_tree_node_base const*, unsigned int const&) const ()
#2 0x0000555555cd770e in std::_Rb_tree<unsigned int, std::pair<unsigned int const, std::vector<Anvil::Queue*, std::allocatorAnvil::Queue* > >, std::_Select1st<std::pair<unsigned int const, std::vector<Anvil::Queue*, std::allocatorAnvil::Queue* > > >, std::less, std::allocator<std::pair<unsigned int const, std::vector<Anvil::Queue*, std::allocatorAnvil::Queue* > > > >::find(unsigned int const&) const ()
#3 0x0000555555cd0e01 in std::map<unsigned int, std::vector<Anvil::Queue*, std::allocatorAnvil::Queue* >, std::less, std::allocator<std::pair<unsigned int const, std::vector<Anvil::Queue*, std::allocatorAnvil::Queue* > > > >::find(unsigned int const&) const ()
#4 0x0000555555cc5c38 in Anvil::BaseDevice::get_n_queues(unsigned int) const ()
#5 0x0000555555db6575 in Anvil::Swapchain::init() ()
#6 0x0000555555db5093 in Anvil::Swapchain::create(std::unique_ptr<Anvil::SwapchainCreateInfo, std::default_deleteAnvil::SwapchainCreateInfo >) ()
#7 0x0000555555ccc77c in Anvil::SGPUDevice::create_swapchain(Anvil::RenderingSurface*, Anvil::Window*, Anvil::Format, Anvil::ColorSpaceKHR, Anvil::PresentModeKHR, Anvil::Bitfield<Anvil::ImageUsageFlagBits, unsigned int>, unsigned int) ()
#8 0x0000555555c15204 in App::init_swapchain() ()
#9 0x0000555555c12bba in App::init() ()

Urggh. Definitely a project left of the shelf for too long. It's great that it's working under Windows so I'll wrap up this line of inquiry at my end and wait for input from @bizehao.

[bizehao]

He really hasn't maintained this project for a long time.
I've added an example vsgmultiviewsForIssues196

[robertosfield]

I posted the below comment on the PR, I'm copy and pasting here in case others come across this Issue in future and want to know how it was concluded.

I've done more reflecting on the issue how to get multiple RenderGraph that share the same window to play nice and have come to the conclusion that the approach you've taken is broadly workable, but if it takes so much extra code and complexity to workaround the intended design of vkRenderPass/vkFramebuffer that it's a clear indicator that it's just the wrong approach.

Rather than attempt to clean up the workarounds you've come up with I think best way forward is to simplify vsgmultiviews so it just has the clear attachments implementation and to remove the RenderGraph per View approach completely. My brief experiment with subpasses offered nothing over just using clear attachments directly so I will abandon that experiment as well.

Apologies for taking so long to come to this conclusion, this part of Vulkan is a bit awkward and reveals is roots as an API for modern games on modern graphics hardware that has been generalized enough to handle more general purpose graphics applications,

Thanks for your efforts trying to get to the bottom of the multi RenderGraph issues, I've learned/clarified a few things about Vulkan and Vulkan drivers/hardware because of this.

[bizehao]

OK, I understand that this does add too much code and I think it can be used as a custom personal project. I also learned a lot about vulkan by solving this, thanks for this project. I'm writing something now that I'm using this, and it's good to use.

[robertosfield]

On Sat, 24 Dec 2022 at 00:28, bizehao ***@***.***> wrote: OK, I understand that this does add too much code and I think it can be used as a custom personal project. I also learned a lot about vulkan by solving this, thanks for this project. I'm writing something now that I'm using this, and it's good to use.

It might be worth benchmarking your custom approach vs the ClearArttachment approach, while I reviewed all the possible implementations I didn't benchmark them, but don't expect there will be a noticable difference. If there isn't a performance benefit for the more complicated approach then it wouldn't be worth using it. Good luck with your project, and if you have something to share then please post a show and tell to the VulkanSceneGraph Discussion page as the community will appreciate finding out what others are up to,

…

Message ID: ***@***.***>