Pre VulkanSceneGraph-1.0.3 testing phase.

[robertosfield]

I've been planning on tagging 1.0.3 for a while now but have a series of client and open source tasks that have kept dropping in my lap that have prevented me from getting things VSG master close to a release state. I believe we now pretty close so would like to wider testing of the VSG and the associated projects to make sure that the code base is in a good place for tagging 1.0.3.

The biggest build change since 1.0.2 is removing glslang and SPIRV-Tools as external dependencies achieved by using glslang as a submodule and compiling glslang directly into the VSG. This approach is rather unconventional so I'm wary of unexpected problems that it might throw up - only testing on as many platform and application combinations as we can will settle this.

I need to sit down an enumerate all the changes since 1.0.2 as there have been quite a few, I will do that over the next few days in the run up to 1.0.3. Right now what I'd really like from the community is testing, testing, testing of VSG master. Please report success or failures here on this thread so we can get a feel for convergence towards a stable 1.0.3 state.

If everything goes smoothly I'll tag the 1.0.3 release this Thursday.

[robertosfield]

No negative feedback master means.... we're good for our first release candidate? :-)

OK, so I've ignored the lack the positive feedback and merge VSG, vsgXchange and vsgExamples master into the respective 1.0 branches. The rc's are:

https://github.com/vsg-dev/VulkanSceneGraph/releases/tag/VulkanSceneGraph-1.0.3-rc1
https://github.com/vsg-dev/vsgXchange/releases/tag/vsgXchange-1.0.2-rc1
https://github.com/vsg-dev/vsgExamples/releases/tag/vsgExamples-1.0.2-rc1

The changes between 1.0.3 and 1.02 are pretty extensive compared to between 1.0.1 and 1.0.2, a reflection of the longer time period, the complete changes can be seen in the three PR's I've just merged:

#737
vsg-dev/vsgXchange#148
vsg-dev/vsgExamples#213

Please test and let me know success or failures.

[timoore]

Hi, VSG master is looking pretty good here when compiling vsgCs. I did notice this error from the validation layer, which I thought we saw (and you fixed) with the ViewDependentState changes? If it's not obvious where this is coming from, I'll probe further.

VUID-VkWriteDescriptorSet-descriptorCount-00317(ERROR / SPEC): msgNum: -284942183 - Validation Error: [ VUID-VkWriteDescriptorSet-descriptorCount-00317 ] Object 0: handle = 0x3a6cbb0000000025, type = VK_OBJECT_TYPE_DESCRIPTOR_SET; | MessageID = 0xef042099 | vkUpdateDescriptorSets() pDescriptorWrites[0] failed write update validation for VkDescriptorSet 0x3a6cbb0000000025[] with error: Attempting write update to VkDescriptorSet 0x3a6cbb0000000025[] allocated with VkDescriptorSetLayout 0xab64de0000000020[] binding #1 (1 from dstBinding offset) with a different stageFlag and/or descriptorType from previous bindings. All bindings must have consecutive stageFlag and/or descriptorType across a VkWriteDescriptorSet. The Vulkan spec states: All consecutive bindings updated via a single VkWriteDescriptorSet structure, except those with a descriptorCount of zero, must have identical descriptorType and stageFlags (https://vulkan.lunarg.com/doc/view/1.3.239.0/linux/1.3-extensions/vkspec.html#VUID-VkWriteDescriptorSet-descriptorCount-00317)

[robertosfield]

I'll need to track down the various discussions as I've been covering so many different topics in the last week or two I'm loosing track of things. What is the best way to reproduce the warning? I can look at it again tomorrow when I'm back to my dev system.

[timoore]

Nevermind, this was a problem caused by the custom ViewDependentState in vsgCs. I'm now using the stock VSG ViewDependentState.

I believe that DescriptorSet::Implementation::assign() can provoke this validation error if a descriptor set has descriptors with different stage flags. I have a fix, but no test case! That can wait til after 1.03.