[3.0] Add OpenCL and OpenXR bindings

[Exanite]

Summary of the PR

This PR was originally going to be a mega-PR for all of the remaining Khronos-related bindings and Assimp.
However, I've changed the scope of this PR to focus primarily on OpenCL and OpenXR.

This PR is intended to get the bindings to a point where they exist, but not yet guaranteed to be usable. This is because I want to ensure that future changes are made taking into account all of the Khronos bindings that we plan to ship with.

As such, I do not plan on testing the bindings in this PR. I will be writing smoke-tests for the different bindings available in a separate PR.

Update: I've changed the scope of this PR to only include OpenCL and OpenXR. This PR also includes some improvements to the existing Khronos bindings.

Related issues, Discord discussions, or proposals

Discord thread for this PR: https://discord.com/channels/521092042781229087/1514735149915439274

Further Comments

Tasks

• Port back the option to only run selected jobs. Done during [3.0] Add --only option to SilkTouch #2591.
• Check the tracking issue and figure out what APIs are part of this
• Add required submodules
  • OpenXR
  • OpenCL
  • Assimp
  • SPIRV Reflect
  • SPIRV Cross
  • SPIRV Tools
  • SPIRV Headers
  • Shaderc
  • MoltenVK
  • GLSLang
  • VMA
  • Note: I'm not going to revert the submodule additions here since I plan on using them in my next PR.
• Set submodules to their latest tagged commit
• Update existing Khronos submodules and regenerate
• Generate initial bindings
  • This step will just involve getting the generator to run and output bindings without any obvious issues.
  • OpenXR
    • Initial generation had only one problem, which was that OpenXR's XML uses constants to define array sizes. This was fixed by updating MetadataUtils.GetTypeDetails to naively resolve symbols.
  • OpenCL
    • Fix constexpr error during ClangScraper
    • Exclude cl_bool from being generated? Question mark because I later realized that enums don't have any members. Figure out whether cl_bool is useful (contains members) and check if other similar APIs have a similar enum (I think OpenAL might).
      • Looked at Silk 2 and the XML. Bool seems to contain True, False, NonBlocking, Blocking. The last two are aliases. Will keep cl_bool since Silk 2 has it and there is some use to keeping it, even if it's not much.
    • Fix vendor suffix identification not working since vendor suffixes are capitalized while OpenCL type names are not
    • Fix context being identified as cont + ext where ext is a vendor suffix.
    • Fix enums not having any members.
    • Figure out why so many enums are missing base types. Note: there is one case where enums are expected to be missing base types, which is when the enum is defined in the XML, but not in the C header we parsed.
      • ErrorCodes probably should be manually specified. Need to look in the headers for the correct type.
      • Reason is because the XML doesn't specify the base type and unlike the OpenGL-like specs, we don't have a namespace enum type (eg: GLenum/CLenum) that we can type map.
      • I opted to manually typemap these since I don't believe there will be too many changes in the future, but we can look into automating this if preferred.
    • Fix issue where cl_accelerator_info_intel is prettified as AcceleratorInfointel instead of AcceleratorInfoINTEL.
    • Decide on whether I want to special case vendor affix identification for OpenCL. OpenCL specifies vendors as prefixes, suffixes, and infixes, which is totally not annoying at all. The infix case is technically a suffix, but ends up in the middle of a name due to the dot notation that they use and how Silk converts dots to underscores.
      • I ended up not special casing vendor affix identification, but instead added a special case to transform the weird names to be in the "usual" format where the vendor affix is at the end of the name. This transformation means the vendor suffix identification code works as normal.
      • Note that I consider the implementation of this transformation to be controversial, but also believe it brings more benefits than not. See my thoughts here: https://discord.com/channels/521092042781229087/1514735149915439274/1518124361263878225
    • Improve handling of "blocked" enums (for lack of a better term). Some enums have numbers at the end of their name (eg: cl_intel_advanced_motion_estimation.cl_motion_detect_desc_intel.2). We may want to combine these enums together.
      • Look at what Silk 2 does
        • Silk 2 leaves the enums as is.
      • Check if this is a valid transformation
        • The different sections must have the same base type and must not have enum members that share the same values (ie, a conflict)
        • Yes, this is valid for the single enum this affects
      • Apparently this affects 1 singular enum. Probably still worth handling though. IntelAdvancedMotionEstimationClMotionDetectDescIntel2 is the current name and contrasts with IntelAdvancedMotionEstimationClMotionDetectDescINTEL, which has the vendor suffix properly identified.
      • Notably, this enum has this comment in the XML spec: Part of previous block?
      • Aside: The usage of block in the tasks here and SilkTouch source code is to be consistent with this comment. I was going to call these "sectioned" enums rather than "blocked" enums, but noticed that the spec calls the different sections "blocks".
      • Edit: Decided against merging cl_intel_advanced_motion_estimation.cl_motion_detect_desc_intel.2 with the non-2 version. The non-2 version focuses on direction while the 2 version focuses on weights/fractions, so it makes sense to keep them separate.
    • Add missing opaque structs. These have the pattern of typedef struct _Type* Type in the headers. I handled these the same way GLsync is handled in OpenGL since that type has the same pattern.
      • I originally used AddOpaqueStructs for these, but then realized ExtractHandles works on OpenCL. Not sure why it doesn't for OpenGL.
    • Add TransformHandles mod so that these opaque structs are transformed as handle types.
• Update OpenGL to use TransformHandles. This has the effect of replacing Sync* with SyncHandle.
• Do a polish pass over the bindings
  • This step will involve creating the manually written files required for the bindings and reviewing every single file for issues.
  • OpenXR
    • Add the required manually written files
    • Figure out what to do for OpenXR's graphics and platform integrations. They can't be generated using a single platform unlike when using the XML. This is because we'll have missing types that are OS-specific (Metal, Win32, X11, etc). Does a cross-compilation like approach help with this? Separate integration projects? Manual stubs for missing types? Need to investigate and discuss.
  • OpenCL
    • Add the required manually written files
• Review generated bindings
  • Review note: Structs are usually fine. Functions and enums are usually where issues occur.
  • Compare current generator settings against Silk 2's settings
  • Compare current bindings output against Silk 2's output
  • Investigate any empty enums
• Ensure mod order for all jobs are consistent
• Ensure native builds are up to date
  • OpenAL
• Update docs
  • Generator usage docs
    • CLI options
    • Clarify that non .gen.cs .cs files do not get modified by SilkTouch
    • Verify usage against my experience during this PR
  • Any mod changes
  • Add new bindings to changelog
• Rebase onto develop/3.0
• Generate using Windows for consistency
  • This must include regenerating every existing binding

Split into future PRs

Khronos vendor suffixes:

• Reconsider the usage of KhronosImpliedVendor suffixes
  • Apparently aliased enums are simply replaced when bindings are updated. This means that users will naturally replace usages of those enums to point to their new versions. Eg: EXT to KHR. Issue is, with implied vendors, this also means that users might accidentally use the wrong enum member since the KHR version of the enum member now takes the name of the old EXT enum member. It might be better to forgo prettiness in favor of correctness here.
  • Also tempted to remove KhronosNonExclusiveVendors since I find this behavior to be more incorrect than it is helpful. It also lets me delete a lot of code (yay!).
  • History note: I believe both of these behaviors were ported from Silk 2. I ported these two behaviors from the INameTrimmer-based implementation to the current name-affix-based implementation.

Remaining bindings I plan to work on:

MoltenVK would just be a native build. VMA is not on the tracking issue, but we already discussed that we want this to be in Silk 3 (and I want it for my personal projects as well).

• Generate initial bindings
  • Assimp
  • SPIRV Reflect
  • SPIRV Cross
  • SPIRV Tools
  • Shaderc
  • VMA
• Do a polish pass over the bindings
  • Assimp
  • SPIRV Reflect
  • SPIRV Cross
  • SPIRV Tools
  • Shaderc
  • VMA
• Native builds
  • Assimp
  • SPIRV Reflect
  • SPIRV Cross
  • SPIRV Tools
  • Shaderc
  • VMA
  • MoltenVK
• Update docs
  • Any mod changes
  • Add new bindings to changelog
• Rebase onto develop/3.0
• Generate using Windows for consistency
  • This must include regenerating every existing binding

[github-actions]

File	Coverage
All files	20%	✅

Minimum allowed coverage is 0%

Generated by 🐒 cobertura-action against 9395d21

[github-actions]

All native library builds modified in this PR shall attempt to be built by CI.

[github-actions]

Some of the native library builds modified in this PR were not referenced in the PR description. Please ensure that the PR description contains /build-native OpenAL-Soft. These libraries won't be rebuilt without this being specified. If you believe this is in error, then please write a comment explaining why and ignore this suggestion. This comment will be automatically updated if rectified.