Unlike in Windows, in Linux the graphics UI concerns are outside the kernel, so graphics layers sit pretty close to the hardware, so even just from that higher performance was already expected as the adaptor layers such as Wine/Proton improved because the kernel itself is faster and gets less in the way.
Then, of course, the Linux kernel tends to be developed by people with lots of experience, overseen by people genuinelly at the Software Architecture level of experience and given its architecture benefits from know-how both from the server-side and the front-end sides of software development.
My point being that the Linux architecture is not only far more mature and controlled by far more experienced people than the Windows one, but it also gets way less in the way of graphics applications trying to squeeze as much performance as possible from the system hence in Linux improving such graphics applications or the adapter layers for them can go further in delivering better performance than in Windows were the kernel becomes a performance bottleneck sooner.
What we’re seeing now is those two effects delivering, especially once the Wine/Proton adaptor layers matured and entered a stage of more performance and stability improvements than feature implementations.
Unlike in Windows, in Linux the graphics UI concerns are outside the kernel
That’s not exactly correct. In Linux kernel talks to hardware and user space driver talks to kernel.
There absolutely is a kernel driver for AMD and Intel cards. It’s just there’s very clean separation between userspace driver that exposes APIs to the applications and kernel driver (which is part of the kernel, literally) that talks to hardware.
This allows inplementing all sorts of APIs without modifying the kernel driver. In principle you could make Playstation or Nintendo switch graphic API driver in userspace and it could work with existing AMD/Intel chips
Unlike in Windows, in Linux the graphics UI concerns are outside the kernel
is in the sense that the Linux Kernel isn’t in any way form or shape optimized for any kind of graphics features, unlike in Windows. The software design concerns about graphical interfaces are in user space and, as you say, the “kernel talks to hardware and user space driver talks to kernel”.
I don’t see how what I wrote is inconsistent with what you wrote: the kernel only delivers access to the graphics and leaves to user space the details of what’s done with it, most notably (by comparison with Windows) all the software design concerns from having a graphical user interface - I just described in high-level Software Architecture terms the “why” for the “how” that you described in Software Design terms.
Granted, with GPUs the complexity is so much more than with traditional systems (such as networking or data stores) that a lot of the performance improvement happens is in the graphics drivers, which is not quite kernel but kernel-adjacent, so it’s a little less perfectly split between kernel-space and user-space than what I wrote made it seem.
Unlike in Windows, in Linux the graphics UI concerns are outside the kernel, so graphics layers sit pretty close to the hardware, so even just from that higher performance was already expected as the adaptor layers such as Wine/Proton improved because the kernel itself is faster and gets less in the way.
Then, of course, the Linux kernel tends to be developed by people with lots of experience, overseen by people genuinelly at the Software Architecture level of experience and given its architecture benefits from know-how both from the server-side and the front-end sides of software development.
My point being that the Linux architecture is not only far more mature and controlled by far more experienced people than the Windows one, but it also gets way less in the way of graphics applications trying to squeeze as much performance as possible from the system hence in Linux improving such graphics applications or the adapter layers for them can go further in delivering better performance than in Windows were the kernel becomes a performance bottleneck sooner.
What we’re seeing now is those two effects delivering, especially once the Wine/Proton adaptor layers matured and entered a stage of more performance and stability improvements than feature implementations.
That’s not exactly correct. In Linux kernel talks to hardware and user space driver talks to kernel.
There absolutely is a kernel driver for AMD and Intel cards. It’s just there’s very clean separation between userspace driver that exposes APIs to the applications and kernel driver (which is part of the kernel, literally) that talks to hardware.
This allows inplementing all sorts of APIs without modifying the kernel driver. In principle you could make Playstation or Nintendo switch graphic API driver in userspace and it could work with existing AMD/Intel chips
is in the sense that the Linux Kernel isn’t in any way form or shape optimized for any kind of graphics features, unlike in Windows. The software design concerns about graphical interfaces are in user space and, as you say, the “kernel talks to hardware and user space driver talks to kernel”.
I don’t see how what I wrote is inconsistent with what you wrote: the kernel only delivers access to the graphics and leaves to user space the details of what’s done with it, most notably (by comparison with Windows) all the software design concerns from having a graphical user interface - I just described in high-level Software Architecture terms the “why” for the “how” that you described in Software Design terms.
Granted, with GPUs the complexity is so much more than with traditional systems (such as networking or data stores) that a lot of the performance improvement happens is in the graphics drivers, which is not quite kernel but kernel-adjacent, so it’s a little less perfectly split between kernel-space and user-space than what I wrote made it seem.