Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong/missing SType for some structures #60

Open
TillAlex opened this issue Mar 31, 2020 · 8 comments
Open

Wrong/missing SType for some structures #60

TillAlex opened this issue Mar 31, 2020 · 8 comments

Comments

@TillAlex
Copy link

The validation layers throw lots of VKStructureType warnings at me when using different structs.

Here is an example:

vkCreateDescriptorSetLayout: pCreateInfo->pNext chain includes a structure with unexpected VkStructureType VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO; Allowed structures are [VkDescriptorSetLayoutBindingFlagsCreateInfo].

The unexpected type differs between calls and usually does not make any sense.

Looking at the code generate by SharpVk my guess is that for some structures SType is not set at all, but I am not sure if I am just missing the line where it's set.

One example is DescriptorSetLayoutBindingFlagsCreateInfo. While other MarshalTo methods set SType correctly, here SType is not set at all.

@FacticiusVir
Copy link
Owner

The unmanaged memory used to marshal structs is not zeroed for fields that will always have a value, such as SType, so the unexpected type is likely garbage data from previous calls. I'll have a dig into the generator to see why these structs are not getting SType set correctly.

@TillAlex
Copy link
Author

TillAlex commented Apr 1, 2020

Thank you for looking into this in advance and also thank you for all your great work here!

@TillAlex
Copy link
Author

TillAlex commented Apr 4, 2020

Debugging a bit it seems that for DescriptorSetLayoutBindingFlagsCreateInfo the EnumElementReader only finds the old SType VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_BINDING_FLAGS_CREATE_INFO_EXT, but not the new VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_BINDING_FLAGS_CREATE_INFO.

@FacticiusVir
Copy link
Owner

Thanks for spotting that - I hadn't noticed the extension enums being moved into feature release elements in the XML, so the generator was simply skipping the SType fields that referenced them. I'll push some NuGet packages tonight.

@TillAlex
Copy link
Author

TillAlex commented Apr 8, 2020

I will test it as soon as you pushed the Nuget packages. Thank you!

@TillAlex
Copy link
Author

Just testet the new Nuget package. Lots of sTypes are fixed, thank you!

However, there are still some sType related bugs. When calling physicalDevice.GetFeatures2() the debug layer throws:

vkGetPhysicalDeviceProperties2KHR: parameter pProperties->sType must be VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROPERTIES_2. The Vulkan spec states: sType must be VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROPERTIES_2 (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vksp
ec.html#VUID-VkPhysicalDeviceProperties2-sType-sType)

It seems that when calling GetFeatures2() MarshalTo() is not called for the structure before calling vkGetPhysicalDeviceProperties2KHR and therefor sType is not initialized. The same problem occours for GetProperties2() and GetMemoryProperties2()

@FacticiusVir
Copy link
Owner

That's going to take a little more fiddling :-D I'd not tackled extensions in return values, because there's no clean way to include "optional" return values without creating lots of references and memory churn. Until I've added those the GetFeatures2(), et cetera don't give you anything over regular GetFeatures()

@TillAlex
Copy link
Author

No problem. Currently I am only using extensions features supported by all the GPUs we are using. Just wanted to let you know that there are still some sTypes missing. Thanks for fixing the other structures again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants