Skip to content

[3.0] Add Vulkan bindings for Silk 3.0 #2457

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

Draft
wants to merge 37 commits into
base: develop/3.0
Choose a base branch
from

Conversation

Exanite
Copy link
Contributor

@Exanite Exanite commented May 23, 2025

Current progress

(Will update this as I work)

Currently investigating how enum and handle types should be handled.

Enum types

Not actively working on.

Handle types

Actively working on.

Perksey and I discussed rewriting ExtractNestedTyping and TransformHandles to use the Roslyn symbol model and to use the symbol renamer. The symbol renamer is currently implemented in a different, unmerged PR so I'll likely wait for that or cherry pick that commit. However, I'll start working on any functionality that does not require the symbol renamer in the meantime.

Summary of the PR

This PR primarily adds Vulkan bindings.

Summary of important decisions/changes:

This also adds a few fixes to existing code:

  • f9d72f3 removes an assert that was causing MixKhronosData to fail when parsing Vulkan's
  • FindCommonPrefix now handles cases where no names are provided by simply returning an empty string

Related issues, Discord discussions, or proposals

Initial Discord discussion: https://discord.com/channels/521092042781229087/587346162802229298/1375224188129906778

Discord thread: https://discord.com/channels/521092042781229087/1376331581198827520/1376623544875880589

Further Comments

Before undrafting PR

This tracks smaller things that I might forget about.

  • Remove code used to generate enum mappings in sources/SilkTouch/SilkTouch/Mods/MixKhronosData.cs.
  • Automate the generation of enum mappings.
  • Remove Linux specific Clang workaround in eng/silktouch/vulkan/settings.rsp
  • Self code review and make sure all important changes/decisions are documented in the PR summary.

Exanite added 7 commits May 23, 2025 19:11
This code seems to look for "<feature api=" elements in vk.xml. However, one of the six total elements don't have a "depends" attribute.
You can see this by opening https://raw.githubusercontent.com/KhronosGroup/Vulkan-Docs/refs/heads/main/xml/vk.xml and searching for "<feature api=".

This is the line that does not have the depends attribute, which causes the assert to fail:
<feature api="vulkan,vulkansc" name="VK_VERSION_1_0" number="1.0" comment="Vulkan core API interface definitions">

The other relevant lines do have a depends attribute:
<feature api="vulkan,vulkansc" name="VK_VERSION_1_1" number="1.1" depends="VK_VERSION_1_0" comment="Vulkan 1.1 core API interface definitions.">
This commit fixes the allowLeadingDigits overload. The previous similarly named commit fixes the maxLen overload.
This currently doesn't generate anything for some reason (only the enums generate, and that's because of a previous mod)
@Exanite Exanite changed the title Add Vulkan bindings for Silk 3.0 [3.0] Add Vulkan bindings for Silk 3.0 May 25, 2025
Exanite added 10 commits May 26, 2025 08:11
I'm guessing we don't need this since we don't care about vulkansc. Let me know if we want to keep this defined.
Nothing generates yet. Not sure why.
There are some file names that are incorrect (the enum name inside the file is fine), such as sources/Vulkan/Vulkan/Vulkan/VkBufferCreateFlagBits.gen.cs. They all seem to be enums.

I did some light checking and it seems that these incorrectly named enums don't have equivalents in the Enums folder.

Some enums have multiple versions, which is expected, but the newer versions tend to be in the Enums folder while the older versions are in the Vulkan folder:
For example:
sources/Vulkan/Vulkan/Vulkan/VkAccessFlagBits.gen.cs
sources/Vulkan/Vulkan/Enums/AccessFlags2.gen.cs
sources/Vulkan/Vulkan/Enums/AccessFlags3KHR.gen.cs

Interestingly, as I was writing this commit message, I noticed that AccessFlags.gen.cs was named correctly before I added the traverse argument in my previous commits.
Will regenerate using Windows or whichever platform is preferred later for consistency.
@Exanite Exanite force-pushed the feature/vulkan-bindings-3.0 branch from a117cb2 to 20ef463 Compare May 26, 2025 16:38
@Exanite
Copy link
Contributor Author

Exanite commented May 26, 2025

Putting this here for reference.

These are the logs related to the generation of enums during the MixKhronosData mod after the latest commit.

The enums specified in these errors either are:

  • Not enums (API Constants)
  • Are part of a non-core Vulkan header
    • VkFullScreenExclusiveEXT is part of vulkan_win32.h
    • VkDisplacementMicromapFormatNV is part of vulkan_beta.h
  • Or don't exist at all in the headers in the Vulkan-Docs nor Vulkan-Headers repos
fail: Silk.NET.SilkTouch.Mods.MixKhronosData[0] Enum "API Constants" has no base type. Please add TypeMap entry to the configuration. This enum group will be skipped.
fail: Silk.NET.SilkTouch.Mods.MixKhronosData[0] Enum "VkFullScreenExclusiveEXT" has no base type. Please add TypeMap entry to the configuration. This enum group will be skipped.
fail: Silk.NET.SilkTouch.Mods.MixKhronosData[0] Enum "VkFaultLevel" has no base type. Please add TypeMap entry to the configuration. This enum group will be skipped.
fail: Silk.NET.SilkTouch.Mods.MixKhronosData[0] Enum "VkFaultType" has no base type. Please add TypeMap entry to the configuration. This enum group will be skipped.
fail: Silk.NET.SilkTouch.Mods.MixKhronosData[0] Enum "VkFaultQueryBehavior" has no base type. Please add TypeMap entry to the configuration. This enum group will be skipped.
fail: Silk.NET.SilkTouch.Mods.MixKhronosData[0] Enum "VkPipelineMatchControl" has no base type. Please add TypeMap entry to the configuration. This enum group will be skipped.
fail: Silk.NET.SilkTouch.Mods.MixKhronosData[0] Enum "VkSciSyncClientTypeNV" has no base type. Please add TypeMap entry to the configuration. This enum group will be skipped.
fail: Silk.NET.SilkTouch.Mods.MixKhronosData[0] Enum "VkSciSyncPrimitiveTypeNV" has no base type. Please add TypeMap entry to the configuration. This enum group will be skipped.
fail: Silk.NET.SilkTouch.Mods.MixKhronosData[0] Enum "VkPipelineCacheValidationVersion" has no base type. Please add TypeMap entry to the configuration. This enum group will be skipped.
fail: Silk.NET.SilkTouch.Mods.MixKhronosData[0] Enum "VkDisplacementMicromapFormatNV" has no base type. Please add TypeMap entry to the configuration. This enum group will be skipped.

@Exanite Exanite force-pushed the feature/vulkan-bindings-3.0 branch from 20ef463 to e97a9a7 Compare May 26, 2025 19:04
Exanite added 2 commits May 26, 2025 22:21
Only uint64_t=ulong affects the generation, but the others are included to be slightly more complete.
This does not fix the enum backing types though, which also differ between Linux/Windows.

See this conversation in the Silk.NET Discord for more information: https://discord.com/channels/521092042781229087/1376331581198827520/1376628539536969949

Relevant ClangSharp issue: dotnet/ClangSharp#574
@Exanite Exanite force-pushed the feature/vulkan-bindings-3.0 branch from 54c6350 to 57bde07 Compare May 27, 2025 02:25
Exanite added 14 commits May 26, 2025 23:06
Technically this only removes the T, but the effect should be the same.
Note the git diff looks a bit weird on this commit. Git seems to think that some of the files were renamed when they were not.
Not sure if doing it this way is correct
This also adds slightly refactors the code for better debuggability (extractedFunctionPointers).
No idea why the using statements change.
Enum backing types also change between uint to int. This is fine for mosts cases since the bit width doesn't change, but nevertheless concerning.
This is so that the ExtractNestedTypes mod can also make use of the logic without having to duplicate code.

This also adds xml doc comments to all public facing members. Most of these new doc comments are inheritdoc tags. The notable doc comments to review are the comment on the class itself and on GetHandleTypes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Todo
Development

Successfully merging this pull request may close these issues.

1 participant