[WIP] Convert from SharpDX to Silk.NET. #1715

Ethereal77 · 2023-07-18T20:34:24Z

PR Details

Replace SharpDX bindings for DXGI, Direct3D 11, Direct3D 12, the DirectX Shader Compiler, and any other use of SharpDX with Silk.NET bindings.

Description

SharpDX is the base for all the Direct3D (both 11 and 12) graphics frameworks in Stride. But SharpDX is no longer active nor mantained, the repository is archived, and the NuGets are still (and forever) netstandard2.0. Also, it is based on a class-based abstraction over the DirectX interfaces.

Meanwhile, Silk.NET is a new bindings library created to take advantage of modern .NET, use the modern C# performance-oriented primitives and features (like Span<T>, for example), and it's designed more as a raw bindings as close as possible to the underlying DirectX APIs, without class-based abstractions. Its main drawback however is that it is inherently unsafe (in the context of using pointers and memory management directly) That however is of no importance to Stride as it will be under the hood of the Stride.Graphics framework.

This PR consists of the following points:

Convert Direct3D 11 framework to Silk.NET.Direct3D11.
Convert Direct3D 12 framework to Silk.NET.Direct3D12.
Convert DirectX Shader Compiler to Silk.NET.Direct3D.Compilers.
Improve the documentation on DirectX-related methods and types, removing references to SharpDX or to the native constants, types, or functions where appropriate.
Introduce small convenience types and helper functions to aid in the implementation of interop improvements like this one, now and in the future.

Related Issue

This PR tries to solve issue #432. It is similar to PR #1123 by ykafia, but that one is pretty out of date at this point, so it was easier to start afresh branching the current master.

Motivation and Context

The motivation for converting to Silk.NET is twofold:

The SharpDX libraries are pretty solid and stable at this point. However its design filosophy (more to be used as a framework itself ala XNA) and its age makes us lose opportunities to improve performance, control memory allocations more tightly and take advantage of modern C#. Also it is no longer mantained, so no more bug fixes or improvements of any kind.
Silk.NET is actively mantained and uses all the utilities modern C# and .NET has to offer. As it is actively mantained it's easier to get bug fixes and improvements, and more importantly, access to future (and current) technologies we may be interested in (like DirectStorage, DXVA, etc).

If all goes well with this PR, you should not see a difference in Stride. Maybe better performance and memory consumption. The improvement is mainly to be more up to date and more inline with modern .NET.

Types of changes

Docs change / refactoring / dependency upgrade
Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)

Checklist

My change requires a change to the documentation.
I have added tests to cover my changes.
All new and existing tests passed.

ly3027929699 · 2023-10-21T09:39:30Z

i can't build this branch via some errors has not resolve

Eideren · 2023-10-21T14:53:18Z

@ly3027929699 Yeah, the PR is still marked as wip, you shouldn't expect it to work as is yet :P

Perksey · 2023-10-12T18:02:16Z

sources/engine/Stride.Graphics/Direct3D/GraphicsAdapterFactory.Direct3D.cs

+            HResult result = dxgi.CreateDXGIFactory2(debugFlag, SilkMarshal.GuidPtrOf<IDXGIFactory2>(), (void**) &factory2);
+
+            if (result.IsFailure)
+                result.Throw();
+
+            NativeFactory = factory2;
+            ComPtr<IDXGIFactory2> adapterFactory = new() { Handle = factory2 };


FWIW we have overloads now that can simplify this

ComPtr<IDXGIFactory2> adapterFactory = dxgi.CreateDXGIFactory2<IDXGIFactory2>(debugFlag);

It's mentioned in the 2.17 blog post: https://dotnet.github.io/Silk.NET/blog/apr-2023/silk2170.html

I've seen them. I'm first making it work and checking things, then I'll make it pretty using the overloads.

sources/engine/Stride.Graphics/Direct3D/DebugHelpers.Direct3D.cs

Kryptos-FR · 2025-02-24T10:50:40Z

~~@Ethereal77 I'm trying to merge master into this branch to solve the conflicts introduced by #2643. However, I don't seem to have the rights to push to your repo. Could you add me as a contributor?~~

nvm: I was able to fix the conflicts in the web editor

Ethereal77 · 2025-02-24T11:10:05Z

@Kryptos-FR I can indeed add you as a contributor. No problem with that.

However, I still have changes locally that I have not yet pushed. I'm gradually distilling the changes from another repo I have. As this has taken more time than I wanted it to take initially it has been a bit of a mess, where most of the changes I've made to a "prototype" repo where I try things.
My plan is to rebase all this on Stride's master instead of merging master here.

So, with this in mind, if you merge master to this branch now you'll make my life a little miserable right now 😁

What I can do is push some of the changes I want to do today and then do a rebase to the current master. What do you think?

P.D: If you still want me to add you as contributor, as I said above, no problem.

Kryptos-FR · 2025-02-24T11:27:00Z

@Ethereal77 Oh oh. I saw your comment after merging master. You should be able to rebase on top of the commit before the merge to ignore it.

If you are unsure how to do it (and not want to mess with your local branches), if you add me as a contributor I can restore the remote branch to where it was before the merge.

Ethereal77 · 2025-02-24T12:02:36Z

Don't worry. I'll finish some changes I have in progress, rebase on master at the previous commit and force push. That would do it, isn't it?
I know I should have this branch as clean and as merge-ready as possible, but as it is now it's a little mess with more than 100 uncommitted files I'm slowly reviewing, cleaning, and pushing.
I also have many more modified files in which I've added or expanded documentation, but I wanted to add that progressively and on top of the more important changes (the Silk.NET conversion) instead of mixing them, with the hope that reviewing the changes is easier this way.

Ethereal77 · 2025-02-24T17:09:15Z

@Kryptos-FR I've rebased on latest master (except the last merge commit). Hope everything went well.

Kryptos-FR · 2025-02-24T17:14:48Z

@Ethereal77 looks like, except maybe the reference to Silk.NET.D3DCompiler in Directory.Package.props, shouldn't it be Silk.NET.Direct3D.Compilers instead?

Ethereal77 · 2025-02-24T22:22:26Z

It looks like the package was named Silk.NET.D3DCompiler but has been renamed recently (?). I've just upgraded to the latest Silk.NET version and now it is indeed named Silk.NET.Direct3D.Compilers.

Kryptos-FR · 2025-02-25T08:55:37Z

sources/engine/Stride.Graphics/Stride.Graphics.csproj

-    <PackageReference Include="SharpDX.Direct3D12" Condition="'$(TargetFramework)' == '$(StrideFramework)'" />
-    <PackageReference Include="SharpDX.D3DCompiler" Condition="'$(TargetFramework)' == '$(StrideFramework)' Or '$(TargetFramework)' == '$(StrideFrameworkUWP)'" />
    <PackageReference Include="Vortice.Vulkan" Condition="'$(TargetFramework)' == '$(StrideFramework)'" />
+    <PackageReference Include="Silk.NET.Direct3D11" Condition="'$(TargetFramework)' == '$(StrideFramework)' Or '$(TargetFramework)' == '$(StrideFrameworkUWP)'" />


UWP might be removed by #2450. Just to keep in mind in case it gets merged. No need to fix it now.

Kryptos-FR · 2025-02-25T08:56:29Z

sources/engine/Stride.Shaders.Compiler/Stride.Shaders.Compiler.csproj

  <ItemGroup>
    <ProjectReference Include="..\Stride.Shaders.Parser\Stride.Shaders.Parser.csproj" />
-    <PackageReference Include="SharpDX.D3DCompiler" Condition="'$(TargetFramework)' == '$(StrideFramework)' Or '$(TargetFramework)' == '$(StrideFrameworkUWP)'" />
+    <PackageReference Include="Silk.NET.Direct3D.Compilers" Condition="'$(TargetFramework)' == '$(StrideFramework)' Or '$(TargetFramework)' == '$(StrideFrameworkUWP)'" />


UWP might be removed by #2450. Just to keep in mind in case it gets merged. No need to fix it now.

Kryptos-FR · 2025-02-25T08:56:55Z

sources/engine/Stride.Video/Stride.Video.csproj

    <PackageReference Include="SharpDX.MediaFoundation" Condition="'$(TargetFramework)' == '$(StrideFramework)' Or '$(TargetFramework)' == '$(StrideFrameworkUWP)'" />
-    <PackageReference Include="SharpDX.Direct3D11" Condition="'$(TargetFramework)' == '$(StrideFramework)' Or '$(TargetFramework)' == '$(StrideFrameworkUWP)'" />
-    <PackageReference Include="SharpDX.Direct3D12" Condition="'$(TargetFramework)' == '$(StrideFramework)'" />
+    <PackageReference Include="Silk.NET.Direct3D11" Condition="'$(TargetFramework)' == '$(StrideFramework)' Or '$(TargetFramework)' == '$(StrideFrameworkUWP)'" />


UWP might be removed by #2450. Just to keep in mind in case it gets merged. No need to fix it now.

Kryptos-FR · 2025-02-25T08:57:08Z

sources/tools/Stride.Graphics.RenderDocPlugin/Stride.Graphics.RenderDocPlugin.csproj

    <ProjectReference Include="..\..\engine\Stride.Graphics\Stride.Graphics.csproj" />
    <PackageReference Include="Microsoft.Win32.Registry" />
-    <PackageReference Include="SharpDX.Direct3D11" Condition="'$(TargetFramework)' == '$(StrideFramework)' Or '$(TargetFramework)' == '$(StrideFrameworkUWP)'" />
+    <PackageReference Include="Silk.NET.Direct3D11" Condition="'$(TargetFramework)' == '$(StrideFramework)' Or '$(TargetFramework)' == '$(StrideFrameworkUWP)'" />


UWP might be removed by #2450. Just to keep in mind in case it gets merged. No need to fix it now.

microsoft/microsoft-ui-xaml#9983 (comment)
there is also the idea to make it available again

Ethereal77 · 2025-02-25T14:14:18Z

Yeah, I'm following the issue on UWP support. Will remove any reference entirely if not needed anymore.

Ethereal77 · 2025-02-26T15:52:37Z

I'm starting to upload most of the changes that I think are mostly ready.

As Direct3D 11 and 12 share a common way of doing things, I'm pushing just D3D 11 and DXGI for now. D3D 12 will come a bit later when I get feedback on D3D11.

I've just started with the Buffer class with the code changes. I have ready the added/improved documentation I've also writing, and I want to push it in a separate commit.

The question is: Should I do the documentation pass now? Or postpone it for a later time?
I ask this because the documentation is hugely verbose and will make more difficult reviewing the changes. There are a lot of additions also, so it will appear as a lot of green in diffs.

VaclavElias · 2025-02-26T16:41:24Z

Thank you @Ethereal77. Lots of updates here. I would be ok with docs later but in this case I woud like a feedback from @Eideren or @Kryptos-FR regarding the docs because in some cases it might be very important.

Kryptos-FR · 2025-02-26T17:22:27Z

I think it's fine to push the documentation here. As long as it's on a separate commit, it's always possible to do an offline review that ignore that particular commit.

But let's wait for @Eideren's point of view. I'm not a graphics expert so my review will be a bit more superficial, and is less likely to be encumbered by lots of comments 😅.

Eideren · 2025-03-01T16:06:25Z

Yep, I agree with @Kryptos-FR, if you already have the docs, might as well include it. My thinking is that it may also help the reviewer

* GraphicsException is the base of all exceptions for Stride.Graphics * GraphicsDeviceException is now the base exception for when GraphicsDevice.Status is the culprit

* Also, some more ComPtrs instead of pointers

* To aid in debugging of resource lifetimes

* Also add the ability to set a name for a Graphics Resource in construction

* For now, non-configurable

* Also improves some of the debug facilities to better identify resources in logs and debugger

* Improve the documentation on Stride.Core types related to memory / disposables / reference counting * Improve the documentation on platform type enums

xen2 · 2025-09-18T05:19:55Z

@Ethereal77 Curious, what's the state of this PR? (seeing it's still marked as draft)
Are there still unfinished parts? Or it's mostly testing from now on?
I was wondering if this could be part of 4.3 release (which will also contain .NET 10 upgrade)

xen2 · 2025-09-18T08:35:48Z

@Ethereal77 Also, considering the huge amount of effort, we would like to offer a bounty of $1500 (at least) once this task is completed.
I have just added money to the OpenCollective project: https://opencollective.com/stride3d/projects/stride3d-silknet
https://opencollective.com/stride3d/projects/stride3d-silknet

Ethereal77 · 2025-09-19T19:02:51Z

The PR is almost done. I'm running the test projects and correcting / fixing some small quirks. My intent is to have it ready as soon as possible. I can rebase it and push the current state if people want to start testing / reviewing.

I'm currently tracking down some tests that fail with invalid output (wrong alpha blending due to some zeroed-out description struct), or produce exceptions due to wrong parameters, but right now ~90% of the graphics tests pass with resulting images similar to reference.

Also, considering the huge amount of effort, we would like to offer a bounty of $1500 (at least) once this task is completed.

Thank you. I appreciate it.

Ethereal77 · 2025-09-19T19:10:46Z

Btw, tests are quite difficult to debug with RenderDoc since the migration to Avalonia (it throwns an exception inside the MicroCom interop layer of AvaloniaUI). Attach to running process doesn't work either for some reason. That is making finding some problems a little hard.

Do someone know how to make it work? I've seen GameTestBase have some mechanism to dump RenderDoc captures, but don't know how it works exactly.

Ethereal77 · 2025-09-19T19:19:29Z

Oh, and another thing that crossed my mind the other day @xen2 (for a different PR, not this one)

Would it make sense to, for the graphics tests when the platform is Direct3D, to use WARP as the adapter? If the goal is to test the renderer and catch regressions, the GPU is not very important, just the results of the rendering. WARP is always present, it is slower, but for tests ran sporadically it won't matter much, and it would make the need to still count with that GTX 960 redundant. Finally, as WARP is software based, everyone that runs the tests will get a consistent 1:1 output unless there are true regressions or changes.

(with WARP I mean the Windows Advanced Rasterization Platform)

Eideren · 2025-09-19T22:12:56Z

We have this section in the manual about render doc https://doc.stride3d.net/latest/en/manual/troubleshooting/profiling.html?q=renderdoc#use-renderdoc not sure how useful that could be in your particular case but might as well share just in case

Ethereal77 · 2025-09-23T20:54:52Z

I've managed to get the tests to generate a RenderDoc capture by forcing it in GameTestBase (although it can also be done via an environment variable). With this, I can now review the tests that are behaving strangely.

Ethereal77 mentioned this pull request Sep 14, 2023

Fix DX11 shared textures #1759

Merged

7 tasks

Perksey reviewed Oct 21, 2023

View reviewed changes

ykafia mentioned this pull request Nov 18, 2023

[WIP] Direct3D with Silk.NET #1123

Closed

7 tasks

Ethereal77 force-pushed the directx-silk branch from f7e2a18 to 61d0f67 Compare June 30, 2024 20:47

Ethereal77 force-pushed the directx-silk branch from 485258e to 0433695 Compare September 24, 2024 14:10

Ethereal77 force-pushed the directx-silk branch from 31a2882 to 5a60210 Compare November 11, 2024 23:43

Aggror linked an issue Dec 9, 2024 that may be closed by this pull request

Convert from SharpDX to Silk.NET #432

Open

Eideren mentioned this pull request Feb 7, 2025

Silk.NET D3D Discussion #1176

Open

mahdikshk reviewed Feb 20, 2025

View reviewed changes

sources/engine/Stride.Graphics/Direct3D/DebugHelpers.Direct3D.cs Outdated Show resolved Hide resolved

Kryptos-FR mentioned this pull request Feb 22, 2025

refactor: Nullable and Modernization for Core projects #2643

Merged

8 tasks

Ethereal77 force-pushed the directx-silk branch from 6cba522 to d81d300 Compare February 24, 2025 17:03

Kryptos-FR reviewed Feb 25, 2025

View reviewed changes

Arc-huangjingtong mentioned this pull request May 16, 2025

WIP: feat: Add transparent window api #2784

Draft

8 tasks

Ethereal77 added 5 commits July 13, 2025 17:16

Separate GraphicsException in two

2996b46

* GraphicsException is the base of all exceptions for Stride.Graphics * GraphicsDeviceException is now the base exception for when GraphicsDevice.Status is the culprit

Small fix in SwapChainGraphicsPresenter for Direct3D 12

25d9344

Improve and document some of the Stride.Games types related to graphics

bdc9fca

Refactor ShaderCompiler to use ComPtrs

bbb805b

Documentation pass for ShaderCompiler

2718ab5

Ethereal77 force-pushed the directx-silk branch 2 times, most recently from 6641453 to 40b9fcd Compare July 13, 2025 19:18

Ethereal77 added 3 commits July 14, 2025 14:02

Minor fixes and updates after rebase on 'master'

1a4872d

Fix and improve some Equals() that would cause a NRE

63e182e

Fix Release on a null COM pointer

3594b4a

* Also, some more ComPtrs instead of pointers

Ethereal77 force-pushed the directx-silk branch from 40b9fcd to 3594b4a Compare July 14, 2025 14:49

Ethereal77 added 2 commits July 14, 2025 20:32

Fix other APIs so they are up to the latest changes

bae46e1

Improve DebugHelpers and add a flag to log name changes

b8efb56

* To aid in debugging of resource lifetimes

anpin mentioned this pull request Jul 17, 2025

Linux Support tixl3d/tixl#77

Open

Ethereal77 added 8 commits July 17, 2025 20:17

Add debug names for Graphics Resources when debugging

7a30f76

* Also add the ability to set a name for a Graphics Resource in construction

Add D3D Info Queue message processing when debugging

42f1c1c

* For now, non-configurable

Minor refactor of PrimitiveQuad

7fe5f95

Documentation pass

61e7e51

Fix some resource leaks from misusing reference counting + Dispose

a8cb50a

* Also improves some of the debug facilities to better identify resources in logs and debugger

Fix a NRE exception due to using an incorrect loop bound

2e47ba1

Small improvements, documentation and cleanup

1ebe1fc

* Improve the documentation on Stride.Core types related to memory / disposables / reference counting * Improve the documentation on platform type enums

Improve PipelineStateCache to better use COM pointers

20c8037

VaclavElias mentioned this pull request Sep 13, 2025

[Chore] - Stride.Graphics - Upgrade/Remove SharpDX #2891

Open

Uh oh!

[WIP] Convert from SharpDX to Silk.NET. #1715

Are you sure you want to change the base?

[WIP] Convert from SharpDX to Silk.NET. #1715

Uh oh!

Conversation

Ethereal77 commented Jul 18, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Details

Description

Related Issue

Motivation and Context

Types of changes

Checklist

Uh oh!

ly3027929699 commented Oct 21, 2023

Uh oh!

Eideren commented Oct 21, 2023

Uh oh!

Perksey Oct 12, 2023

Choose a reason for hiding this comment

Uh oh!

Ethereal77 Oct 24, 2023

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Kryptos-FR commented Feb 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Ethereal77 commented Feb 24, 2025

Uh oh!

Kryptos-FR commented Feb 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Ethereal77 commented Feb 24, 2025

Uh oh!

Ethereal77 commented Feb 24, 2025

Uh oh!

Kryptos-FR commented Feb 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Ethereal77 commented Feb 24, 2025

Uh oh!

Kryptos-FR Feb 25, 2025

Choose a reason for hiding this comment

Uh oh!

Kryptos-FR Feb 25, 2025

Choose a reason for hiding this comment

Uh oh!

Kryptos-FR Feb 25, 2025

Choose a reason for hiding this comment

Uh oh!

Kryptos-FR Feb 25, 2025

Choose a reason for hiding this comment

Uh oh!

IXLLEGACYIXL Feb 25, 2025

Choose a reason for hiding this comment

Uh oh!

Ethereal77 commented Feb 25, 2025

Uh oh!

Ethereal77 commented Feb 26, 2025

Uh oh!

VaclavElias commented Feb 26, 2025

Uh oh!

Kryptos-FR commented Feb 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Eideren commented Mar 1, 2025

Uh oh!

xen2 commented Sep 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xen2 commented Sep 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Ethereal77 commented Sep 19, 2025

Uh oh!

Ethereal77 commented Sep 19, 2025

Uh oh!

Ethereal77 commented Sep 19, 2025

Ethereal77 commented Jul 18, 2023 •

edited

Loading

Kryptos-FR commented Feb 24, 2025 •

edited

Loading

Kryptos-FR commented Feb 24, 2025 •

edited

Loading

Kryptos-FR commented Feb 24, 2025 •

edited

Loading

Kryptos-FR commented Feb 26, 2025 •

edited

Loading

xen2 commented Sep 18, 2025 •

edited

Loading

xen2 commented Sep 18, 2025 •

edited

Loading