What happens these days is that GPU buffers are mapped into user space, where they are filled with textures and drawing commands. Then, they are submitted to the kernel GPU scheduler for execution. See e.g.https://lwn.net/Articles/283798.
These days you don't even submit them via a kernel call these days; you've got your own GPU MMU context so you can kind of just go to town within your own process.
That's sort of the whole point behind Mantle/Vulkan/Metal/DX12.
Does this actually happen with enough regularity to care?
In the cases where it does, I imagine it's a situation where you're actually doing 3D-accelerated renders of the user interface. In which case, when the graphics subsystem craps out, hasn't your running system been rendered effectively unusable anyway?
I get that this is a nice idea in theory, but does it actually improve anything practical in practice?
The Linux i915 driver manages to hard freeze my laptop every few days without any 3D games or even a compositing window manager ... It would be lovely to take it out of the kernel and isolate it with IOMMU.
Right, but that's my point. You're playing a game and the display crashes — I guess it's nice in theory that the rest of your system stayed up, but you're still more than likely just going to reboot, no?
If not, how exactly do you plan to restart the graphics process?
Windows automatically restarts the GPU driver after a crash; the screen goes black for a few seconds and then all the windows come back up. It can also upgrade the GPU driver without a reboot. It's not used often but it's pretty handy.
I think that was the moment I realised I liked Windows 7 more than XP. Installed new graphics drivers, expected "you must reboot your system", instead the screen went black (I had a moment of 'oh crap') and then came back up with 'installation complete.' Very impressive if you're used to XP.
This impressed me a lot a couple of months ago, when my GPU driver started crashing about every 5 seconds while playing a game, and Windows kept restarting it, without even killing the game. The performance was abysmal of course, but still pretty neat.
If the OS itself doesn't automatically recover the graphics process, you could always fire up your OS's built-in screen reader and use it like a blind person until you can get the graphics back up and running.
"The graphics drivers for Fuchsia also exist as user-space services. They are logically split into a system driver and an application driver. The layer of software that facilitates communication between the two is called Magma, which is a framework that provides compositing and buffer sharing. Also part of the graphics stack is Escher, a physically-based renderer that relies on Vulkan to provide the rendering API"
Depends on the OS design. It's really not a good design, but you could run everything in ring0 (x86), supervisor mode (ARM), etc. However, now any fault (user or OS) could halt your system and you have no memory protection or process separation.
You've also have Singularity style software isolated processes where the OS statically verifies memory safety so that it can safely run all of the code in ring 0.
No. GPUs typically work over the PCIE bus, and one can talk to PCIE via user space as well. In legacy systems like Linux the mapping of virtual to physical address and generation of scatter-gather-lists (SGLs) resided in the kernel. If one moves the same functionality to the user space without loss in performance (which is what magenta seems to do), there's no benefit to kernel GPU drivers.
Then there's the whole "GPL mafia" in the Linux world who'd like to force vendors to open up their drivers by moving as much of the critical pieces to the kernel as possible. In theory, you cannot write a kernel driver without violating the GPL. Fuchsia will have no such impositions. If someone wants to open their driver up, they could. If they believe their offering is superior, and a secret sauce needs protecting, they can keep it closed
Having control over the virtual to physical address mapping and scatter-gather lists for GPUs is effectively equivalent to kernel-level access anyway, though, because it lets you carry out DMA to and from arbitrary physical memory addresses. Some proprietary drivers for mobile GPUs have even given this level of access to untrusted user processes in the past leading to privilege escalation to root.
Unfortunately, the GPL mafia is right, and hardware vendors will continue to abuse their users with proprietary blobs unless they are forced into change.
AMD is finally changing. Unfortunately, The amdgpu-pro limbo right now is not ideal... but I am very excited for the future.
AMDGPU is already very usable. I remember ~5-10 years of waiting to use my Radeon 9600 with a recent kernel until the free Radeon driver was finally up to snuff. Catalyst and fglrx were awful.
Proprietary drivers just don't make sense. They are practically unmaintainable.
It certainly is. "Business" just needs to internalize the fact that baking a bigger cake gets you more cake than fighting like a starved peasant over crumbs.
I wonder why the BSDs haven't caught on for embedded appliances and phones while Linux did with a more restrictive and less business friendly license. Sure some companies like iXSystems and Juniper adopted BSDs, but the vast majority used Linux.
The manpower behind Linux is superior. Not sure if it's the "vast majority", but for many business cases following the GPL(v2) rules simply is not a problem.
Both the PS4 and the Nintendo Switch run on FreeBSD, by the way.
>Both the PS4 and the Nintendo Switch run on FreeBSD, by the way.
Not exactly from what I've read, the PS4 runs 'Orbis OS' which is based upon FreeBSD 9, meanwhile the Nintendo Switch is using the network stack from FreeBSD, but also stuff from Android and the custom OS they wrote for 3DS.
Linux was available under a free license earlier (and alone) and as such developed a huge lead in community that no free OS has caught up with; that has quality, choice, and skill availability impacts that generally dwarf licensing issues for businesses.
In my opininon, any particular license can only be friendly or unfriendly towards particular business models but not towards business in general.
Some businesses feel threatened by some open source licenses and other businesses are using the same open source licenses to do the threatening.
The funding for many important open source projects comes from global corporations that use it as part of their strategy, sometimes dominating entire industries based on open source.
A large number of small consulting businesses are based entirely on open source software as well.
Open source is not meant to be anti-commercial, nor would that make any sense, because "commercial" is what most of us do to make a living. That is not what takes away anyone's freedoms.
What does take away many freedoms is the fact that none of the widely used open source licenses fulfill their original purpose.
Linking rights to distribution once meant that users of the software got those rights. Now, in the age of the data center, end users get no rights at all and software can be modified freely by those who run the data centers without granting anyone access to those modifications.
Software has become more opaque than it has ever been before since the dawn of the PC age. Even without access to source code we had more control over Microsoft Excel than we now have over anything that runs in a data center, regardless of whether it is nominally "open source" or not.
"Being business-friendly is shit". --> Who pays your bills mate? Fairies or a business who employs you, pays you a salary and you know, the inherent Darwinist biological urge to move up the food (value) chain to survive built into all living beings?
Dumb question, does this mean that it's limited to software rendering only? You need to go through the kernel to talk to the GPU, right?