Currently gnome-shell is taking 135MB of ram, with other gdm/gnome related background services ranging in 700KB-3.2MB each to like 20MB together.
And it's as snappy as my sway config I log into depending on the needs.
I just spammed virtual desktop changes, opening Files, browsing, and it's as snappy as it is in sway.
I think gnome is getting a lot of unfair performance criticism online as it looks like something that would be slow.
Maybe it was slow back in the starting gnome3 days.
Maybe there are some heavy differences in how distros package it? (arch btw)
... though I will say that from my experience it's the KDE that's the slow one. I don't have it installed currently on this machine but had in the past and have it on my steam deck(which is stronger then this laptop).
It feels sluggish and I have this bouncing cursor wait animation in my head right now just thinking about it.
It's mostly on us, the developers.
Vulkan is fully supported on windows.
I would say that if you want to have multi-platform support just use Vulkan.
Covers most of the platforms(especially if you include MoltenVK)[0].
Though, for games, if you want to support Xbox, that usually throws a curveball into API choice planning. As that might be more important of a target than Linux/Android/Mac/iOS(maybe even combined) for your game. So if you already have to support DX for that..
I think saying that DX was first so it's Vulkan that was reinventing the wheel is incorrect with historical context.
AMD and DICE developed a prototype API called Mantle. Which is what both DX and Vulkan are based on.
Both Vulkan(glNext back then) and DX12 were announced around the same time. VK came a bit later as standards are usually slower in coming to decisions but it's not like VK was reinventing anything from DX.
I remember we were having a laugh reading early DX12 documentation as it was in parts just copied from Mantle with names unchanged in places!
> DirectX 12 was announced by Microsoft at GDC on March 20, 2014, and was officially launched alongside Windows 10 on July 29, 2015.
> Vulkan 1.0 was released in February 2016.
What people forget is that Mantle was basically a proprietary AMD API that they wanted and developed until, well, the release of Metal in 2014 and DX 12 in 2015.
Only then did they "graciously" donated Mantle to Khronos for the development of modern APIs.
Vulkan was not just late. It suffers from the same issues as OpenGL before it: designed by committee, lackluster support from the major players.
AMD indicated from the beginning they wanted it to become the universal API.
Opening stuff up formally also takes time. So it all was going towards Vulkan in one form or another and no one was forcing MS to push DX12 NIH while this was happening.
And counter to your point, despite Mantle being "proprietary", MS directly used it to create DX12 (same as Vulkan used it), so AMD clearly didn't have any complaints about that.
> AMD indicated from the beginning they wanted it to become the universal API.
Was it an indication or was there any actual work done? Such as supporting anything else but AMD cards for example, inviting others to collaborate etc.?
> despite Mantle being "proprietary", MS directly used it to create DX12
I can't remember the term for it: what do you call when a single company develops something with little to no external input and collaboration, even if it's sorta kinda open?
As for "NIH"... Microsoft has/had a much bigger investment and interest in new gaming APIs than the few AMD cards that Mantle supported. And they already had their own platform, their own APIs etc. Makes sense for them to move forward without waiting for anyone
Over time the work was obviously done for Mantle → Gl Next → Vulkan. And that's becasue AMD were positive about this idea. Their initial presentation of Mantle was in that vein, i.e. to kickstart the progress of the common API.
MS just decided to do that whole thing for their NIH in parallel using parts of Mantle practically verbatim. It wouldn't have been possible without AMD basically allowing it.
Ah you are right, I forgot that they both were announced at around the same time. It just feels like Vulkan took forever. To the point where some teams at my job had to use OpenGL even for greenfield projects for quite a while after Vulkan was first announced (even when they wanted to use Vulkan).
I wonder if that means that dx12 and Vulkan could have a good interop/compatibility story, since they both have similar origins.
I would guess that if DX didn't exist the iteration on VK side would just be faster. Through extensions, like you've mentioned.
In the end it might have even speed up the adoption of such features. Currently if you have a multiplatform engine, even though windows is like 99% of your PC player base it's still sometimes a tough decision to just use a feature that you can't support on all your targets.
But are you saying that compared to DX or just in general?
We're talking here about potential DX replacement, not about design in general and the bulk of it is very similar for both APIs.
There are some small quirks from Vulkan being made to be easily extensible which in the end I consider worth it.
I personally like how consistent the API is in both patterns and naming. After using it for a while, it's easy to infer what function will do from the name, how it will handle memory, and what you'll need to do with that object after the fact.
I think for Gamedev windows is mostly good just because that's where most of your players are.
Tooling was historically also better from a GUI perspective. With nicer to-use debuggers. Now on Linux you can use Jetbrains products if you need them.
Vulkan is just as much an industry standard as DirectX 12 is. I did a lot of work with both. Choosing between them is often just a matter of being already used to one when it comes to PC support.
You'll have to do DX for Xbox support and that's sometimes a bigger player base for you than Android/Linux/Switch/Mac(MoltenVK), though.
As a game developer, I can see how DX12 got a lead. As a Linux user, I'm a bit salty that it's being chosen so often! As we could have all united on an open multiplatform API :(
Currently gnome-shell is taking 135MB of ram, with other gdm/gnome related background services ranging in 700KB-3.2MB each to like 20MB together.
And it's as snappy as my sway config I log into depending on the needs.
I just spammed virtual desktop changes, opening Files, browsing, and it's as snappy as it is in sway.
I think gnome is getting a lot of unfair performance criticism online as it looks like something that would be slow. Maybe it was slow back in the starting gnome3 days. Maybe there are some heavy differences in how distros package it? (arch btw)
... though I will say that from my experience it's the KDE that's the slow one. I don't have it installed currently on this machine but had in the past and have it on my steam deck(which is stronger then this laptop). It feels sluggish and I have this bouncing cursor wait animation in my head right now just thinking about it.
reply