6 ms·

>They are drawing everything in userspace with fast graphics render... Dumb question, does this mean that it's limited to software rendering only? You need to

by desdiv 10y ago

>They are drawing everything in userspace with fast graphics render... 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?

mankash666 10y ago
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
- michaelmrose 10y ago
  You make open source drivers sound like a bad thing.
  - cbsmith 10y ago
    No, but pushing that agenda via architectural level changes is not exactly a way to get a good architecture.
    - icebraining 10y ago
      An architecture is a structural design made to achieve certain goals. They just happen to have another goal to achieve.
      - cbsmith 10y ago
        It's even bad by that standard. When you compromise the function of the system to achieve that kind of goal, you end up losing out on both.
  - mankash666 10y ago
    offering no alternative but "open source" on Linux is certainly not the most business friendly way to go about it.
    - milesrout 10y ago
      Being business-friendly is not a goal, and shouldn't be a goal.
      - dragonwriter 10y ago
        > Being business-friendly is not a goal Sure, it is, for lots of people. Even, apparently, the FSF, hence the reason non-consumer products are not subject to anti-tivoization rules in GPLv3.
        milesrout 10y ago
        Being business-friendly is not and should not be anyone's goal in licensing software. Being business-friendly is shit.
        fauigerzigerk 10y ago
        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.
- makomk 10y ago
  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.
  - rwmj 10y ago
    Not with IOMMU (Intel VT-d and similar).
    - monocasa 10y ago
      And GPUs these days have their own MMUs too.
- thomastjeffery 10y ago
  Unfortunately, the GPL mafia is right, and hardware vendors will continue to abuse their users with proprietary blobs unless they are forced into change.
  - TheOtherHobbes 10y ago
    How long has the GPL Mafia been saying this? Do you see many vendors being forced into change?
    - frozenport 10y ago
      Typically only big vendors can afford not to change
    - bonzini 10y ago
      For GPUs, AMD is changing and even nVidia is using Nouveau for some chipsets. For non-GPUs, only some WiFi drivers are out-of-tree (Realtek and Broadcom).
    - thomastjeffery 10y ago
      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.
- andrepd 10y ago
  The "GPL mafia", how dare they demand their software's license be respected!?
peter-m80 10y ago
"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"
rayiner 10y ago
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 https://lwn.net/Articles/283798.
- monocasa 10y ago
  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.
ClashTheBunny 10y ago
In addition to the other comments, I would be excited about a graphics driver not being able to take out my system.
- stouset 10y ago
  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?
  - Torgo 10y ago
    Yes? I haven't played games in a while, but when I did, crashes were frequent enough to be annoying, and ~100% of the time it was video drivers.
    - stouset 10y ago
      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?
      - thomastjeffery 10y ago
        Lot's of options here: ssh from my phone and restart the driver. Go to a fallback ui, and restart the driver. Have a system util notice the driver is misbehaving incorrectly, and restart it.
      - wmf 10y ago
        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.
deaddodo 10y ago
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.
- monocasa 10y ago
  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.
- andrewmchen 10y ago
  You only have to run the privileged process that talks to the GPU in ring0 right?

by desdiv 10y ago

mankash666 10y ago

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

michaelmrose 10y ago
You make open source drivers sound like a bad thing.
- cbsmith 10y ago
  No, but pushing that agenda via architectural level changes is not exactly a way to get a good architecture.
  - icebraining 10y ago
    An architecture is a structural design made to achieve certain goals. They just happen to have another goal to achieve.
    - cbsmith 10y ago
      It's even bad by that standard. When you compromise the function of the system to achieve that kind of goal, you end up losing out on both.
- mankash666 10y ago
  offering no alternative but "open source" on Linux is certainly not the most business friendly way to go about it.
  - milesrout 10y ago
    Being business-friendly is not a goal, and shouldn't be a goal.
    - dragonwriter 10y ago
      > Being business-friendly is not a goal Sure, it is, for lots of people. Even, apparently, the FSF, hence the reason non-consumer products are not subject to anti-tivoization rules in GPLv3.
      - milesrout 10y ago
        Being business-friendly is not and should not be anyone's goal in licensing software. Being business-friendly is shit.
        fauigerzigerk 10y ago
        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.
makomk 10y ago
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.
- rwmj 10y ago
  Not with IOMMU (Intel VT-d and similar).
  - monocasa 10y ago
    And GPUs these days have their own MMUs too.
thomastjeffery 10y ago
Unfortunately, the GPL mafia is right, and hardware vendors will continue to abuse their users with proprietary blobs unless they are forced into change.
- TheOtherHobbes 10y ago
  How long has the GPL Mafia been saying this? Do you see many vendors being forced into change?
  - frozenport 10y ago
    Typically only big vendors can afford not to change
  - bonzini 10y ago
    For GPUs, AMD is changing and even nVidia is using Nouveau for some chipsets. For non-GPUs, only some WiFi drivers are out-of-tree (Realtek and Broadcom).
  - thomastjeffery 10y ago
    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.
andrepd 10y ago
The "GPL mafia", how dare they demand their software's license be respected!?

peter-m80 10y ago

"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"

rayiner 10y ago

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 https://lwn.net/Articles/283798.

monocasa 10y ago
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.

ClashTheBunny 10y ago

In addition to the other comments, I would be excited about a graphics driver not being able to take out my system.

stouset 10y ago
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?
- Torgo 10y ago
  Yes? I haven't played games in a while, but when I did, crashes were frequent enough to be annoying, and ~100% of the time it was video drivers.
  - stouset 10y ago
    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?
    - thomastjeffery 10y ago
      Lot's of options here: ssh from my phone and restart the driver. Go to a fallback ui, and restart the driver. Have a system util notice the driver is misbehaving incorrectly, and restart it.
    - wmf 10y ago
      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.

deaddodo 10y ago

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.

monocasa 10y ago
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.
andrewmchen 10y ago
You only have to run the privileged process that talks to the GPU in ring0 right?