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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: [email protected]
No game suggestions, friend requests, surveys, or begging.
No Let’s Plays, streams, highlight reels/montages, random videos or shorts.
No off-topic posts/comments, within reason.
Use the original source, no clickbait titles, no duplicates.
(Submissions should be from the original source if possible, unless from paywalled or non-english sources.
If the title is clickbait or lacks context you may lightly edit the title.)
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.