Visitar URL original
[3.0] Exanite's Tracking Issue · Issue #2586 · dotnet/Silk.NET · GitHub
Skip to content

[3.0] Exanite's Tracking Issue #2586

New issue
New issue
Open
Open
[3.0] Exanite's Tracking Issue#2586
Assignees
Exanite

Description

@Exanite
Exanite
opened on Jun 6, 2026

Exanite's Tracking Issue

This tracks miscellaneous tasks that I accumulated while working on Silk.NET 3.0.
If you see anything you're interested in working on, please let me know!

A task being here on this tracker does not mean it is guaranteed to be completed.
This tracker's goal is so we do not accidentally forget tasks and any tasks not completed are intentionally left uncompleted.

In-progress

Tasks in progress will be moved to the corresponding pull request.

Uncategorized

This section contains informal reports, suggestions, or complaints about Silk.NET 3.0.
I'm logging them here so they don't get forgotten about until I either open a formal issue or address them.

From Aqua:

From Ethereal:

  • SilkTouch generator takes an immense amount of RAM: https://discord.com/channels/521092042781229087/607634593201520651/1513592461493145601
    • I need to also check with Curin to see how much RAM their device has. If their device doesn't have enough RAM, this might explain why the Microsoft job takes so long (aside from it already processing a lot of data).
    • Run the Microsoft job locally and see how much RAM it takes on my device.

Bindings and feature requests

From Nolram (https://discord.com/channels/521092042781229087/607634593201520651/1524213012402147348):

  • Add Imgui bindings
  • Investigate whether direct P/Invoke and static linking works in Silk.NET 3.0 and how we want to support it.
    • From what I can tell, it involves some configuration, providing static builds, and maybe switching over to LibraryImport over DllImport.

From dfkeenan:

High priority

Currently empty. See PR plans below.

Medium priority

Currently empty. See PR plans below.

Low priority

ABI compat proposal:

Bindings usage:

IDE / Metadata:

  • Ensure SupportedApiProfiles attributes are correct
    • Properly resolve API profiles for Flags/FlagBits types
    • Prefer name from NativeName for resolving API profiles
    • Note: I'm in favor of not doing this. If it were up to me, I'd rather drop the entire SupportedApiProfiles feature entirely.
  • Consider optimizing NativeName attributes.
    • This should involve renaming StripAttributes to CleanupAttributes and adding an option in its config to optimize NativeName attributes.
    • Note: I'm in favor of not doing this since this seems excessive and unnecessary since almost every name differs (non-optimizeable), it's confusing to drop the string/attribute for users, whether this is done doesn't affect the bindings, and SupportedApiProfiles uses a magnitude more strings.
    • Also see: [3.0] Implement name-related improvements identified in previous Vulkan PR #2503 (comment)

Activity

  1. Exanite
    added this to Silk.NET Development Trackeron Mar 24, 2026
  2. Exanite
    self-assigned this
    on Jun 6, 2026
  3. Exanite
    converted this from a draft issue on Jun 6, 2026

  4. Exanite commented on Jun 17, 2026

    @Exanite
    Exanite
    on Jun 17, 2026
    MemberAuthor

    PR Plan

    More CI improvements

    Add missing bindings test projects

    Generator cleanup

    • Add SilkConstants class to generator
      • Ideally all magic numbers and constants are consolidated here and documented.

    Update ClangSharp

    • ClangSharp switched from System.CommandLine to a custom command line argument parser. I noticed that we had verbatim copied code from ClangSharp for handling arguments in Silk 3, so we should update that.
      • This also lets us update System.CommandLine, which we are still using a beta version of.
      • Also update the args we use for ClangSharp RSPs
        • From my initial look at this task on November 7th, 2026, looks like the CLI args also have been renamed
        • Possibly also update the TerraFX submodule for the same reason

    Multi-platform generation, continued

    Platform integrations:

    • Add platform integration headers for each API
      • Not exhaustive, but I'll start with these
      • OpenXR
      • OpenCL
      • Vulkan

    Validation:

    • Investigate OpenCL empty enums
      • Most of these should be populated once the other headers are included
      • cl_command_buffer_info_khr
      • cl_command_buffer_properties_khr
      • cl_command_buffer_state_khr
      • cl_command_buffer_update_type_khr
      • cl_command_properties_khr
      • cl_compiler_mode_altera
      • cl_d3d10_device_set_khr
      • cl_d3d10_device_source_khr
      • cl_d3d11_device_set_khr
      • cl_d3d11_device_source_khr
      • cl_dx9_device_set_intel
      • cl_dx9_device_source_intel
      • cl_gl_context_info
      • cl_gl_object_type
      • cl_gl_texture_info
      • cl_layer_properties
      • cl_media_adapter_set_khr
      • cl_media_adapter_type_khr
      • cl_mutable_command_info_khr
      • cl_mutable_dispatch_asserts_khr (Flags so by default 1 None member)
      • cl_mutable_dispatch_fields_khr (Flags)
      • cl_platform_command_buffer_capabilities_khr (flags)
      • cl_queue_properties_khr
      • cl_semaphore_reimport_properties_khr
      • cl_svm_alloc_properties_khr
      • cl_svm_capabilities_khr (Flags)
      • cl_svm_free_flags_khr (Flags)
      • cl_svm_free_properties_khr
      • cl_svm_pointer_info_khr
      • cl_va_api_device_set_intel
      • cl_va_api_device_source_intel
    • Also investigate any other empty enums, if there are any. Make sure to check for [Flags] enums as well, since these will not be empty and instead have a single None member.

    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
    • Regenerate bindings

    Khronos bindings improvements

    Bindings polish (multiple PRs)

    Bindings cleanup (good for new contributors):

    nullptr constant:

    • Consider making function pointer structs work with nullptr. Seems like a nice QOL feature.
    • The magic nullptr constant does not work. It fails to resolve to anything.
      • Apparently it works in the Silk 3 examples. Probably because it uses a ProjectReference instead of a PackageReference.

    SilkTouch job definitions:

    • Ensure mod order for all jobs are consistent

    InlineArrays (needs discussion first and may be dropped):

    • Why don't we use the InlineArrayN<T> types provided by .NET? Should we use them?
      • Someone in the C# discord mentioned that these were added in .NET 10, which is what led to me add this task.
      • Are the reasons we don't use them because ClangSharp doesn't output them and that they were not available back when the 3.0 SilkTouch was first written?
      • Note: This does have implications for how we handle casts, since there was the idea of making our InlineArray types act like our Ref types.
    • InlineArray structs should have implicit casts from strings/arrays, i.e., should behave like Ref. See [3.0] Add OpenCL and OpenXR bindings #2590 (comment)
      • image

    API object devirtualization (needs discussion first and may be dropped):

    Namespaced extension methods (needs discussion first and may be dropped):

    • Consider adding namespaced (C#) extension methods corresponding to different Khronos API extensions (as in Vulkan/OpenGL/etc extensions).
      • This likely is a nice user experience since it'll be easy to see which extension a method belongs to and what extensions are in use by each C# file.
      • Find the Discord discussion that introduced and discussed this idea.

    Array parameter transformation:

    • OpenCL GetPlatformIDs, GetDeviceIDs, and likely more functions do not have singular GetPlatformID equivalents. This should be handled by our function transformer so I'm guessing the XML metadata is missing. See [3.0] Add OpenCL and OpenXR bindings #2590 (comment).
    • Check other bindings for the same issue. Note this mainly is for Khronos APIs since we only have metadata for these.
      • However, do consider if the array parameter transformation can be done for other APIs as well.

    API contexts:

    • OpenAL context should be disposable

      • This is noted by Perksey in the OpenAL.Tutorial001.HelloSound project. I need to figure out what this Dispose method should do exactly.
      • Check other API contexts as well for the same issue
        channels/521092042781229087/1514735149915439274/1519099432442794150

    • From me (Exanite), as part of my OpenCL example program:

      • Original comments:

        Silk.NET/examples/CSharp/OpenCL/Tutorial001.SimpleKernel/Program.cs

        Lines 75 to 80 in 021738d

        // Load API
        // TODO: These todos apply to all Silk bindings.
        // TODO: Consider making INativeContext public. It's nice for debugging.
        // TODO: Consider returning the concrete class instead of the interface. Having to cast to access Cl.CurrentPlatform is annoying.
        // TODO: I liked how INativeContext only required the function name in Silk 2. Silk 3 is currently `LoadFunction(functionName, libraryNameHint)`.
        var cl = Cl.Create(); // TODO: This should be disposable
      • Expose INativeContext from the concrete API object where applicable (but not the interface)
      • Discuss INativeContext API. Silk 3 is currently LoadFunction(functionName, libraryNameHint), but I liked how Silk 2 only required the function name.
        • Note: I especially don't like how this is an instance that's loosely wrapping static state. It's effectively a cache object.

    • ExtractEnumConstants does not preserve attributes placed on extracted constants (needs verification).

    LoaderInterface hook:

    • The Vulkan bindings are double registering the LoaderInterface hook: https://discord.com/channels/521092042781229087/607634593201520651/1518220269519638599
      • I implemented a temporary hack fix, but I don't believe it to be the correct fix.
        • We need a way to initialize an assembly consistently.
        • Currently there are multiple entrypoints and they aren't guaranteed to be called.
      • In Vulkan, we call RegisterHook in both Vk (defined in a manual file) and Vk.DllImport (defined in a generated file).
        • This causes a multiple registration error, which admittedly is my fault since I didn't realize OpenAL didn't do the same pattern.
        • Removing the duplicate call in Vk is the "fix" I mentioned above, but does not solve the underlying issue.
        • Static constructors are only invoked if the static constructor's type or members are accessed.
        • Notably, accessing Vk.DllImport does not trigger the static constructor for Vk, and vice versa.
        • Because we assume/require both static constructors to be called for proper behavior (Vk.DllImport registers the hook and is not extensible, so we have to register alternative shared library names in Vk), having only one of them be called is a problem.

    Generated files:

    • Add <auto-generated/> comment to start of each generated file. This has the effect of disabling IDE/linter/etc checks, which means less noise and performance cost of working in the Silk repo.

    Enum typedefs are not preserved by ClangSharp. This is intended behavior by ClangSharp since there's no real way to automatically handle these consistently, but does mean we need to manually remap enum types. Vulkan/OpenXR already has some of these remappings done automatically, but we need to ensure every set of bindings has these remappings done.

    • I don't think the OpenGL bindings specify the method parameter types properly
      • Eg: void DrawElements(uint mode, uint count, uint type, void* indices);
      • This should use the enum type instead of uint.
    • Vulkan: Some types are incorrect. uint is used instead of MaybeBool<uint>.
    • OpenCL: Same issue. Tracked in the example project as todos.
    • Ensure all bindings have their enums preserved by remapping them
      • The above are specific cases that I noticed, but there are definitely more cases.
      • (Add all bindings at time of PR as tasks to this list)

    CLong:

    Search paths:

    • (From Aqua) Silk 3 does not prefer its own native binaries? Ie: it prefers the system ones instead of the ones shipped by Silk.
    • (From Curin) For D3D12, the Agility SDK is loaded from the System32 DLL instead of the working directory's D3D12 subdirectory. This means that Silk 2.x (report was for 2.x) and maybe Silk 3.0 (needs verification) cannot access Agility SDK features.

    Native binaries:

    • (From Aqua) libSDL3.so is humongous (should not be nearly 14 MB)
      • Exanite: I checked my system version and that one is only 3 MB.
      • Edit - Exanite: Looks like running file libSDL3.so says libSDL3.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, with debug_info, not stripped, so definitely because the binary was not stripped

    Release Preview 1

    Preview 1 will likely be sometime around here, maybe earlier if the more urgent polishing tasks are completed earlier.
    Before releasing, do read the other tracking issues for Silk 3.0 and ensure the required or relevant tasks are done.

    Additional polish

    Ensure no repeated bugs:

    • Cross reference changelog and past issues for Silk 2 to ensure that we don't have the same bugs in Silk 3

    Vulkan struct chaining

    • Reimplement the Vulkan struct chaining API

    Image format utils

    Needs discussion first and may be dropped:

    • Add image format utils for Vulkan/etc

    Documentation

    • Add Vulkan example project
      • Consider expanding this to be an example project per bindings project.
    • Add bindings usage docs
      • Explain that the native docs for each API can be used since Silk doesn't really change how you use the API
      • Explain difference between bindings and high level APIs
        • Ie, high level APIs do not represent bindings so usually the native docs don't apply for those
      • Explain the different DSL types and magical constants (eg: nullptr)

    Finalize SilkTouch API

    This likely will be fairly late in the preview phases.

    Finalize SilkTouch generator API:

    • Lock down public API to only the types necessary to integrate and add custom SilkTouch mods.
    • Add dedicated documentation section/folder for using the SilkTouch generator as a non-contributor.
    • Add single file SilkTouch example project
    • Add example project of implementing a custom SilkTouch mod with only public APIs available.
    • If possible, change the public API docs analyzer to also require API docs on internal APIs
      • This is to ensure that we keep our internal docs up to par even after we make everything internal instead of public.
  5. Exanite
    added a commit that references this issue on Sep 8, 2026

    Cleanup todos in OpenCL example program

    fbeaa88
  6. Perksey
    added a commit that references this issue on Oct 10, 2026

    [3.0] Add OpenCL and OpenXR bindings (#2590)

    76913ed

  7. Exanite commented on Nov 7, 2026

    @Exanite
    Exanite
    on Nov 7, 2026
    MemberAuthor

    Completed/canceled tasks

    Details

    After maintaining this section for a bit, I'll only list tasks not obviously related to a PR. Otherwise, it means that I'm tracking the same task in two places, which can get confusing.

    Completed during #2588:

    • Switch to SLNX solution format to improve readability/mergability
    • From Ethereal: They had a CSharpier TypeLoadException when running the Win32 job on develop/3.0. Might be related to the error I saw half a year ago. If so, likely can be fixed by simply updating CSharpier. CSharpier has updated their Roslyn package since then.

    Completed during #2591:

    • Port back the --only option from Curin's branch so I don't need to specify --skip for all but one job

    Completed or planned to be completed during #2590 (not yet merged):

    • Begin work on the rest of the Khronos bindings
      • I'd like to start this early because this lets us spot issues early and we can use these as test cases for the rest of the changes.
    • Generator usage: Explain SilkTouch CLI options
    • Generator usage: Clarify that SilkTouch does not modify non .gen.cs .cs files during the Generated Bindings Output section
    • Consider reworking data type trimming regexes.
      • This was discussed more here: [3.0] Implement name-related improvements identified in previous Vulkan PR #2503 (comment)
      • The summary is that the current set of 2 regexes doesn't elegantly handle the case where the ending of a word should not be trimmed, but the word itself can have data type suffixes.
      • For example: alSourceRewindv and alSourceRewind. The d in Rewind can be mistaken as a data type suffix, so we add it to the EndingsNotToTrim regex. However, the dv in Rewindv also has the same problem.
      • We likely need something more akin to WordsNotToTrimInto than EndingsNotToTrim.
    • Investigate why we currently use DllImport in Silk 3.
      • Also added some light documentation to AddVTables in the mod MD docs.

    Completed in dotnet/ClangSharp#699

    Completed outside of a PR:

    • For DrawElements/etc, check if the pointer to 0 issue present in Silk 2 still exists in Silk 3
    • Investigate using the new BitCast optimizations: https://discord.com/channels/143867839282020352/312132327348240384/1517589517727436952
      • Eg: BitCasting a user struct to a Vector struct and immediately using an SIMD operation is now properly optimized. Free performance!
      • This mainly affects Otac0n's work, but I'm logging it here so I also keep it in mind as I work on the bindings.
      • Decision: Just going to keep this in mind. Don't think I need to actively review the bindings for this since there's not many places where this will be used.

    Not doing

    For transparency and for reference, I'll move any tasks I don't plan on doing here.

    • Figure out how to handle CLA properly. Currently native builds will block CLA due to the use of a bot account.
      • Seems to be fine now.
    • Differentiate between smoke tests and actual tutorials/examples. I would categorize the current SDL/OpenAL "tutorials" in Silk 3 to be smoke tests since they really shouldn't be referenced as sources of best practices.

    Quality:

    • [/] Add some way of verifying our bindings are well polished.
      • These would mainly involve simple automated sanity checks that ensure our bindings our consistent. Could be done as a separate CLI project from SilkTouch.
      • [/] Check for missing namespaces.
      • [/] Check for spelling/casing issues? Identifiers like Sdl.PropGpuDeviceCreateDebugmodeBoolean are technically correct (native name is SDL_PROP_GPU_DEVICE_CREATE_DEBUGMODE_BOOLEAN, so Debugmode is "one" word), but we could have an audit tool that checks for these non-ideal cases so we can add manual overrides. Worth the effort? Probably not unless we care about perfecting the bindings.

    Completed/cancelled PRs

    Details

    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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions