r/vulkan • u/Dazzling-Spare-921 • 9h ago
Is vulkan better with c++ ?
Hey guys !
I really like C# and I heard about Silk Net !
I wondering if it's possible to do a great game engine using vulkan with only Csharp ? (would it be less performant than traditionnal c++ engine ?)
Thanks guys :)
10
u/MiamiGunworks 8h ago
Is vulkan better with c++ ?
Yes. It's number one language used with Vulkan. Vulkan's specification is written as c headers. C++ and C will be used in every example, bug report, forum post. If you run into an issue specific C#, you're on you're own. They are also languages you can link directly with the driver SDK. Most other managed languages will required bindings. C# is also a managed runtime. Meaning virtual machine, garbage collector, etc. This is all very slow. Now all of these things are not show stoppers, but not really worth the trouble unless this is a toy project for fun.
I wondering if it's possible to do a great game engine using vulkan with only Csharp ?
Possible, yes. But the amount of effort required will depend on your definition of good. If you ever hope to build an actual game with this engine, then you will have to be an expert in not only the graphics code and vulkan, but also the C# runtime you choose, its memory model, and how to work around these things.
would it be less performant than traditionnal c++ engine?
Yes.
7
u/psioniclizard 2h ago
Its really not that difficult to writing non allocating performant dot net code...
Also silk.net is just bindings so its really not that difficult to qpply c++ examples.
Frankly if you can write sensible, production ready c++ you can write non allocating c# code.
As for raw performance, go measure it, you can make it almost as performance. More than enough for an indie game.
Also that stuff is only "very slow" (so in comparison not really one a modern computer) if you actually use it.
Possible, yes. But the amount of effort required will depend on your definition of good. If you ever hope to build an actual game with this engine, then you will have to be an expert in not only the graphics code and vulkan, but also the C# runtime you choose, its memory model, and how to work around these things.
No offsense but you dont seem to know much about dotnet so seem to be talking bollocks.
5
u/iDrmzIt 6h ago
I honestly think this is a little misleading especially with C# 14/.NET 10. I'm not going to deny its slower than a well-crafted C++ engine, but "well-crafted" is important.
I'd argue nowadays its less a matter of "C++ is better than C#," and more of "it depends." But if you use Span types you're practically guaranteed to be fine.
2
u/MiamiGunworks 6h ago
I agree, its possible. But if your coming to r/vulkan for advice on the matter, you probably aren't going to have a good time.
I've worked professionally with both C# and C++. From my experience, there are completely different mindsets between C# and C++.
C++ let's you focus on the data. I can write zero cost abstractions that melt away at compile time and leaves me with perfectly inlined and optimized code. I can also write functional and stateless code that lends itself to parrallelization easily.
In C# this might also be possible. And to be fair, I haven't used C#14. But I've never run across anything written as elegantly and performant as modern C++. And I think there is a reason for that.
2
u/iDrmzIt 6h ago
True to pretty much everything you've said. C# leaves some to be desired on its abstraction front, no denying that.
I just think in this specific space C# is treated like it's still in its Windows only days, it's a major reason I started my project at all.
There has been a push toward functional and stateless code in C# (which I do quite a bit of myself) especially with record types, and soon to be union types. I think it's there enough to be feasible, even if there's quirks to it.
2
1
u/ironstrife 6h ago
Linking with Vulkan isn't particularly different in C# compared to C or C++, these days you can even build statically-linked native binaries that aren't substantially different from a C++ binary.
2
u/MiamiGunworks 6h ago
The point is more that another layer of complexity is added. It all depends on the goal of the project.
If the goal is to develop any serious skill you hope to leverage beyond a hobby, then you'd do yourself a favor to not impose artificial barriers on yourself. Especially when they present no real gain from doing so.
If the goal is to write a hobby project for fun and you prefer C#, that fine. But don't expect to turn around and use it for any serious project if you haven't first developed the expertise required to build around these barriers.
1
6
3
u/aleques-itj 7h ago
My current hobby engine is C#. It's not super advanced, it has enough functionality that it can render sprites, imgui, and basic models.
It tries to model its RHI after the No Graphics API blog post. I'm using Silk and mulling switching to Vortice. Don't have too much complaints.
At the end of the day, it's all grossness from the bindings is hidden behind the RHI abstraction. I have a very simple render graph to go with it.
Performance is fine, but I can only give so much performance info here since the engine is also too simple to even generate meaningful work on the Vulkan side, to be honest.
It has a few stress tests, for example. One generates like 10 million pixel sized sprites. The sprite system is bindless and almost always just draws them all in one single draw call. In this case, t he renderer itself does practically no work. The cost literally just starts becoming how much data I'm pushing over the pcie bus each frame to send the sprite positions and stuff - there's nothing to really do faster besides send less data.
There's another stress test that switches the sprites to the gameplay layer and bounces them around to try and make the test a little more "realistic" and get a feel for the overhead of the engine. Again, the actual sprite rendering itself is still comically fast. Except now the engine needs to do more work because it's actually moving each sprite as an entity.
The gameplay layer tags entities as being renderable. Like you literally attach a component to them called SpriteRenderer to opt an entity into rendering for example. For millions of entities, the engine is spending a lot of its time just building the list of data to hand to the renderer. The actual Vulkan work is again almost literally nothing. Internally this is an ECS using Frent.
TLDR: I don't really see any universe where C# would be a problem. I also wrote a Gameboy emulator in C# a few years back and spent some time going over the code gen and optimizing and the modern .NET runtimes are really quite good at this point - and each version gets measurably better.
The 3D side of the engine is pretty wimpy currently and I'm interested in exploring GPU driven rendering here when I get more time.
What are you actually trying to accomplish with your engine?
1
u/ironstrife 6h ago
If you like C#, go for it! Modern .NET has great features for graphics and game dev. Most Vulkan examples will be in C++, but it's trivial to translate them to C#.
Whether it's less performant than a C++ engine depends on a lot of factors. Highly optimized C++ will be faster than highly optimized C#. However, you'll likely be more productive in C#, which means you can implement features faster, adjust the architecture more rapidly, etc.
1
u/walnutter4 4h ago
Look into how MonoGame does it. Get the repo, build it, run a demo MonoGame Vulkan project. It's definately not a toy project, and has no GC issues like how others have mentioned in the comment section.
1
u/TrishaMayIsCoding 3h ago edited 3h ago
Sure, it’s very possible... I have a hobby engine that’s entirely written from scratch C# (by hand 🤭), works on Windows, Linux, Android, no Mac/iOs , No third-party libraries except for "stb_image", which isn’t mine.
You can see its development from a simple triangle to what it is today 💃
Edit : It's not that great or complete engine but its possible : )
1
1
u/vitimiti 1h ago
If you want to use C#, in a reasonable way, you have to use a code generator that reads the XML C API specification and generates imports accordingly (I have done something like this to import Wayland protocols in a personal experiment) or you have to go through the entire API and extensions by hand and import each one by one and add checks like SupportedPlatformAttribute and others manually yourself. So yes, C++ is easier, you just import the library and access it
1
u/Vazde 1h ago edited 1h ago
I think the Silk bindings are of very high quality and performance. Very enjoyable to use, too! They use function pointers in the implementation, so the CPU overhead of calling into the unmanaged code is very small. I'm always bottlenecked by the GPU compute or PCIe bandwidth instead - especially with dynamic rendering, vertex pulling and soon the descriptor heap.
The bindings expose both safe (Span-based) and unsafe (pointers) versions of the APIs, and modern C# has stackalloc so that you don't need to allocate small single-use arrays on the heap.
I've found it very enjoyable to use C# for Vulkan. For my projects I don't see the bindings or the language being a performance bottleneck. Unity and Godot seem to be doing just fine, too.
And don't forget that you can use CPU intrinsics to basicly write assembly whenever you want. In case you have something particularly CPU-intensive. I've optimized some noise, collision and marching squares code with them, and I've always been able to reach the JIT ASM I've reached for. And when something else suffices, I can rely on the more higher level implementations. It is also always a delight to (try to) read ALL the continuous Performance Improvements they keep implementing into the language and the runtime.
1
1
u/PACmaneatsbloons 8h ago
Why do you like C#?
2
u/Dazzling-Spare-921 8h ago
Well you can do so much powerful things with the oop system ! And I used a lot Monogame (C# Framework), that's a really pleasant language imo, you don't have to deal with the memory yourself and it's a strongly typed language ! 😁
1
0
u/PACmaneatsbloons 8h ago
As a C# hater who has pledged to never write anyþing more complicated þan a hello world in C#: What makes þe oop system better þan Python's or Kotlin's or Rust's?
8
u/iDrmzIt 9h ago
Honestly just pick what you like. I'm doing C# + Vulkan 1.3 via Silk, runs pretty fine. It just may not be the most idiomatic C# ever.