7 ms·

> For various reasons, but nothing fundamental. "Hardware vendors being unwilling to make the drivers they write open source" is a pretty fundamental reason.

> For various reasons, but nothing fundamental. "Hardware vendors being unwilling to make the drivers they write open source" is a pretty fundamental reason. Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers? I don't think that realistically there's a third option. The open source community is not, for example, going to make their own high performance gpus.

snazz 6y ago
Plus, better isolation between driver code and other kernel code (which Fuchsia seems to bring; correct me if I'm wrong) would be good for everyone, since you can be relatively assured that running vendor-provided driver blobs is safe.
- zozbot234 6y ago
  "Isolation" of driver code that can talk to on-SoC hardware is just not very meaningful. You can only have real driver isolation if it's enforced on the hardware side via some IOMMU mechanism (or by keeping the hardware isolated on the USB bus, etc.), otherwise you're just adding pointless overhead for no real benefit.
  - goodthenandnow 6y ago
    Here you go: https://blog.quarkslab.com/playing-around-with-the-fuchsia-operating-system.html#process-isolation https://blog.quarkslab.com/playing-around-with-the-fuchsia-o...
  - entha_saava 6y ago
    I didn't get it. Don't we want, for example, wifi driver not to be able to access and corrupt (due to some bug) GPU driver's memory?
    - michaelmrose 6y ago
      Does this actually happen?
      - gigatexal 6y ago
        I’m sure it does when used to exploit devices.
    - exged 6y ago
      It's desirable, but typically hardware devices have DMA-capable buses that can read / write to arbitrary physical memory. So a buggy or malicious WiFi driver may be able to use the WiFi DMA hardware to write into the GPU driver's memory, and no pure software mechanism can stop it from doing so. IOMMUs solve this problem by giving hardware devices their own virtual address spaces.
cycloptic 6y ago
I would not say that is a fundamental reason. They have been willing to do it when the proper incentives are there. The incentive to keeping it closed source is primarily part of a strategy to sabotage their competitors, which I hope is not a behavior that anyone here is complicit in. Please don't work for hardware companies that do this, there are plenty of companies out there that know how to spend their money in other ways. >Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers? Neither of those are good options because even in the second case, there are still vast swaths of code that upstream is not going to touch out of fear of breaking things, the end result being that you still get stuck with unfixable kernel and driver bugs. >The open source community is not, for example, going to make their own high performance gpus. The open source community includes a lot of companies. The high-performance GPU companies are welcome to join this community any time they like.
- dontblink 6y ago
  That is an assumption. I think the simpler case is it's more work and exposes potential security vulnerabilities they don't care to patch or maintain. Function > all.
  - deleted 6y ago
    [deleted]
- fluffy87 6y ago
  This claim is wrong. It’s not about sabotaging competitors, it’s about being afraid that your competitors would steal your IP they gives you an advantage. Every Nvidia and Intel competitor (AMD) is probably already reverse engineering their binary drivers and binary libraries trying to steal their IP, so Intel and Nvidia’s fears are imo justified. If NVIDIA or Intel could easily protect their open source code from being stolen from AMD, the story would be different. But you can’t prevent somebody from reading even GPL code, being “inspired” by it, and writing something different enough that does the same thing with the same ideas. Like just look at the LLVM project were people look at what GCC code does every now and then for “inspiration”.
lain-dono 6y ago
> The open source community is not, for example, going to make their own high performance gpus. I think we should lower the entry threshold first. The open source and free GPU project was the first thing that came to my mind when I saw http://llhd.io/ http://llhd.io/. After all, one of the main problems with OpenHardware projects is the closed FPGA ecosystem.
- sam_bristow 6y ago
  It's pretty amazing how far the open source FPGA tooling has come in the last few years. I'd even go so far as to say some parts of the open source ecosystem have surpassed the commercial tools. Still a long way to go of course, but I'm pretty positive about the direction things are heading.
NOGDP 6y ago
> The open source community is not, for example, going to make their own high performance gpus. Of course it will.
- VikingCoder 6y ago
  The first GPU came out twenty one years ago. Why on Earth do you think all of a sudden we're going to get something we've never gotten before?
  - pabs3 6y ago
    The RISC-V community is already working on GPUs, some of them open: https://github.com/felsabbagh3/Vortex https://github.com/felsabbagh3/Vortex https://news.ycombinator.com/item?id=22492902 https://news.ycombinator.com/item?id=22492902 https://libre-riscv.org/3d_gpu/ https://libre-riscv.org/3d_gpu/
    - sharpneli 6y ago
      Doesn’t look that good to me. The Vortex is not a GPU. They call it GPGPU, meant purely for running OpenCL kernels, doesn’t have a graphics pipeline at all, which is kinda important part of a GPU.
      - liuliu 6y ago
        I am not so sure about that. GPU has been slowly moving away from having a fixed graphics pipline at all in the past a few years. See the recent Nanite technology from Unreal 5: http://c0de517e.blogspot.com/2020/05/some-thoughts-on-unreal-5s-nanite-in.html http://c0de517e.blogspot.com/2020/05/some-thoughts-on-unreal...
        sharpneli 6y ago
        They use compute shaders for triangles that cover 1 pixel as rasterization always does 2x2 due to derivative calculations etc so there is overhead. For larger triangles they do go trough the rasterization pipeline as usual because it is so much faster. Another crucial thing is texture mapper. That thing is really fast and usable even in the compute pipeline. Image support is (was?) largely optional in OpenCL. Also I remember the last time people talked about this. PS3 was not originally supposed to have a GPU at all because the Cell processor was so powerful. In the end they had to ram in an actual GPU. While the Cell was just fine for vertex processing it did choke terribly in rasterization due to lack of TMU and dedicated HW rasterizer. EDIT: I also want to emphasize the difference of target markets. On AMD one can go to the Nanite path for some of the rasterization. One must remember that it is a non battery powered device. Memory bandwidth is really power hungry. For mobile, the likely target market for the Vortex and similar, one really wants to do tile based rendering. Ideally the way IMG does it. Even though theoretical flops of modern mobile GPU’s is higher than some old discrete ones their memory bandwidths are way lower, so no running Crysis on modern mobile even though flops would indicate it would match a good discrete GPU back in the days.
naasking 6y ago
> Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers? I don't think that realistically there's a third option A phone in which the kernel never needs to be updated, like with the seL4 microkernel.
- terminalcommand 6y ago
  Most BIOS are also closed source. If I used a microkernel primitive enough not to require changes, I could live with not updating the kernel unless there is a security bug. A third solution could be to require device manufacturers to share their source code with a trusted third party (such as google/certification authority). This third party will make sure that the driver does not include any harmful code and provide signed binaries. Binaries could also be updated for newer versions that way, even if the original manufacturer loses interest/goes bankrupt. If the IP gets stolen, the device manufacturer could sue this third party, therefore business people will also feel secure. It is not ideal, but I could be able to live with this solution.

snazz 6y ago

Plus, better isolation between driver code and other kernel code (which Fuchsia seems to bring; correct me if I'm wrong) would be good for everyone, since you can be relatively assured that running vendor-provided driver blobs is safe.

zozbot234 6y ago
"Isolation" of driver code that can talk to on-SoC hardware is just not very meaningful. You can only have real driver isolation if it's enforced on the hardware side via some IOMMU mechanism (or by keeping the hardware isolated on the USB bus, etc.), otherwise you're just adding pointless overhead for no real benefit.
- goodthenandnow 6y ago
  Here you go: https://blog.quarkslab.com/playing-around-with-the-fuchsia-operating-system.html#process-isolation https://blog.quarkslab.com/playing-around-with-the-fuchsia-o...
- entha_saava 6y ago
  I didn't get it. Don't we want, for example, wifi driver not to be able to access and corrupt (due to some bug) GPU driver's memory?
  - michaelmrose 6y ago
    Does this actually happen?
    - gigatexal 6y ago
      I’m sure it does when used to exploit devices.
  - exged 6y ago
    It's desirable, but typically hardware devices have DMA-capable buses that can read / write to arbitrary physical memory. So a buggy or malicious WiFi driver may be able to use the WiFi DMA hardware to write into the GPU driver's memory, and no pure software mechanism can stop it from doing so. IOMMUs solve this problem by giving hardware devices their own virtual address spaces.

cycloptic 6y ago

I would not say that is a fundamental reason. They have been willing to do it when the proper incentives are there. The incentive to keeping it closed source is primarily part of a strategy to sabotage their competitors, which I hope is not a behavior that anyone here is complicit in. Please don't work for hardware companies that do this, there are plenty of companies out there that know how to spend their money in other ways. >Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers? Neither of those are good options because even in the second case, there are still vast swaths of code that upstream is not going to touch out of fear of breaking things, the end result being that you still get stuck with unfixable kernel and driver bugs. >The open source community is not, for example, going to make their own high performance gpus. The open source community includes a lot of companies. The high-performance GPU companies are welcome to join this community any time they like.

dontblink 6y ago
That is an assumption. I think the simpler case is it's more work and exposes potential security vulnerabilities they don't care to patch or maintain. Function > all.
- deleted 6y ago
  [deleted]
fluffy87 6y ago
This claim is wrong. It’s not about sabotaging competitors, it’s about being afraid that your competitors would steal your IP they gives you an advantage. Every Nvidia and Intel competitor (AMD) is probably already reverse engineering their binary drivers and binary libraries trying to steal their IP, so Intel and Nvidia’s fears are imo justified. If NVIDIA or Intel could easily protect their open source code from being stolen from AMD, the story would be different. But you can’t prevent somebody from reading even GPL code, being “inspired” by it, and writing something different enough that does the same thing with the same ideas. Like just look at the LLVM project were people look at what GCC code does every now and then for “inspiration”.

lain-dono 6y ago

> The open source community is not, for example, going to make their own high performance gpus. I think we should lower the entry threshold first. The open source and free GPU project was the first thing that came to my mind when I saw http://llhd.io/ http://llhd.io/. After all, one of the main problems with OpenHardware projects is the closed FPGA ecosystem.

sam_bristow 6y ago
It's pretty amazing how far the open source FPGA tooling has come in the last few years. I'd even go so far as to say some parts of the open source ecosystem have surpassed the commercial tools. Still a long way to go of course, but I'm pretty positive about the direction things are heading.

NOGDP 6y ago

> The open source community is not, for example, going to make their own high performance gpus. Of course it will.

VikingCoder 6y ago
The first GPU came out twenty one years ago. Why on Earth do you think all of a sudden we're going to get something we've never gotten before?
- pabs3 6y ago
  The RISC-V community is already working on GPUs, some of them open: https://github.com/felsabbagh3/Vortex https://github.com/felsabbagh3/Vortex https://news.ycombinator.com/item?id=22492902 https://news.ycombinator.com/item?id=22492902 https://libre-riscv.org/3d_gpu/ https://libre-riscv.org/3d_gpu/
  - sharpneli 6y ago
    Doesn’t look that good to me. The Vortex is not a GPU. They call it GPGPU, meant purely for running OpenCL kernels, doesn’t have a graphics pipeline at all, which is kinda important part of a GPU.
    - liuliu 6y ago
      I am not so sure about that. GPU has been slowly moving away from having a fixed graphics pipline at all in the past a few years. See the recent Nanite technology from Unreal 5: http://c0de517e.blogspot.com/2020/05/some-thoughts-on-unreal-5s-nanite-in.html http://c0de517e.blogspot.com/2020/05/some-thoughts-on-unreal...
      - sharpneli 6y ago
        They use compute shaders for triangles that cover 1 pixel as rasterization always does 2x2 due to derivative calculations etc so there is overhead. For larger triangles they do go trough the rasterization pipeline as usual because it is so much faster. Another crucial thing is texture mapper. That thing is really fast and usable even in the compute pipeline. Image support is (was?) largely optional in OpenCL. Also I remember the last time people talked about this. PS3 was not originally supposed to have a GPU at all because the Cell processor was so powerful. In the end they had to ram in an actual GPU. While the Cell was just fine for vertex processing it did choke terribly in rasterization due to lack of TMU and dedicated HW rasterizer. EDIT: I also want to emphasize the difference of target markets. On AMD one can go to the Nanite path for some of the rasterization. One must remember that it is a non battery powered device. Memory bandwidth is really power hungry. For mobile, the likely target market for the Vortex and similar, one really wants to do tile based rendering. Ideally the way IMG does it. Even though theoretical flops of modern mobile GPU’s is higher than some old discrete ones their memory bandwidths are way lower, so no running Crysis on modern mobile even though flops would indicate it would match a good discrete GPU back in the days.

naasking 6y ago

> Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers? I don't think that realistically there's a third option A phone in which the kernel never needs to be updated, like with the seL4 microkernel.

terminalcommand 6y ago
Most BIOS are also closed source. If I used a microkernel primitive enough not to require changes, I could live with not updating the kernel unless there is a security bug. A third solution could be to require device manufacturers to share their source code with a trusted third party (such as google/certification authority). This third party will make sure that the driver does not include any harmful code and provide signed binaries. Binaries could also be updated for newer versions that way, even if the original manufacturer loses interest/goes bankrupt. If the IP gets stolen, the device manufacturer could sue this third party, therefore business people will also feel secure. It is not ideal, but I could be able to live with this solution.