5 ms·

AMD openSIL open source firmware proof of concept

221 points by wmf 3y ago

seanw444 3y ago
Another solid move by AMD. Due to their attitude towards open-source in the GPU department, I haven't used an Nvidia graphics card in years. Their APUs kill pretty much all the competition. Their CPUs are excellent for price/performance, efficiency, and core-count. And now this? If they can prioritize getting more AI/ML and 3D modeling capability into their cards, going all-red would become the new clear meta.
- alanfranz 3y ago
  If. If they can proritize _and_ execute on that vision.
  - slt2021 3y ago
    there is also second mover advantage, where they just need to copy-cat the best part of nvidia's ML stack and dont waste time figuring out what works/what doesn't work. they will get users simply because they will be alternative to nvidia. Add good pricing strategy and it can be immediate success
    - msla 3y ago
      > there is also second mover advantage, where they just need to copy-cat the best part of nvidia's ML stack and dont waste time figuring out what works/what doesn't work. Seems like patents would stop that.
      - slt2021 3y ago
        didn't know nvidia patented matmul and dot product
        m00x 3y ago
        There's a lot more involved than matmul and dot products.
      - bmicraft 3y ago
        Didn't the Google v Oracle lawsuit end up confirming that you can't patent an API?
        slt2021 3y ago
        AMD doesnt have to implement CUDA api, they just need to make sure their compute framework works well with pytorch/tf/MLIR or whatever high level framework is being used. Cuda itself will change over time, so no reason for AMD to pick cuda, because nobody writes CUDA kernels by hand, they use high level frameworks
        woodson 3y ago
        But CUDA kernels are everywhere, not just in high-level frameworks. Look at DeepSpeed, for example, which is used in training LLMs.
        slt2021 3y ago
        So what? They can be replaced by amd kernels if there will be adequate tooling support
        deleted 3y ago
        [deleted]
        orra 3y ago
        No, it confirmed reimplementing an API is not copyright infringement. The patent claims were rejected simply because the Google implementations were written in such a way the patents did not apply.
    - fatfingerd 3y ago
      I'm actually happier if they deliver a mediocre GPU performance seamlessly. I would be as annoyed as the gamers to be priced out of a great desktop/video setup. If hype more fully occupied Nvidia's fragile race cars I'd have a nicer laptop.
  - justinjlynn 3y ago
    With Ryzen and their other recent products and their rapid pace of improvement, they certainly have developed a decent track record of that.
    - m00x 3y ago
      They're crushing it on hardware, but being left behind in the firmware/software.
      - justinjlynn 3y ago
        Getting Intel proprietary advantage in widely used open source packages and systems is something Intel has been very, very good at doing. I use POWER9 systems and... Yeah, the software porting situation has been rather annoying (especially in media processing libraries that rely on things like embree, opencolorio and the like)
- gdevenyi 3y ago
  One word. CUDA
  - justinjlynn 3y ago
    Valve's Proton/wine... Apple's M5 cpu. Software/hardware layers, especially system software and hardware interfaces that must remain stable and compatible essentially forever, aren't the strong lock in mechanisms everyone thinks they are.
    - m00x 3y ago
      That absolutely doesn't work in ML training.
      - imtringued 3y ago
        It would work if AMD focused on ROCm support for their consumer GPUs. The reason for that is quite simple. Angry consumers using your GPUs produces a lot of data that helps you design future GPUs and improve the drivers.
      - jjoonathan 3y ago
        It absolutely does, but AMD's execution on this front has been unmitigated dogshit for the last decade and now every engineer in this niche has a scar or five from giving AMD chance after chance after chance and then limping back to NVDA when the slog is just too much. Now that they have money, I'm hoping they can turn this around. I hear that they have... but I've always heard that and it has never been true. I need to see to believe, now.
        Pet_Ant 3y ago
        Are you referring to OpenCL?
        imtringued 3y ago
        https://www.phoronix.com/news/OpenCL-On-Mesa-Matrix https://www.phoronix.com/news/OpenCL-On-Mesa-Matrix
- adrian_b 3y ago
  This is indeed good, but for now it is just a small step towards restoring their previous documentation transparency. Before Zen, AMD published for each CPU the very useful "BIOS and Kernel Developer’s Guide". Starting with the first Zen, this previously public information has become secret. Hopefully, with OpenSIL equivalent information will become public again.
  - userbinator 3y ago
    equivalent information will become public again. I'm not so hopeful, because it seems to have become common for companies to replace information with open source code, which amounts to nothing more than "put this constant in this register" with no detailed explanation of the why. I'd much rather they publish actual documentation than OSS.
    - delusional 3y ago
      Why not both? Good documentation with a reference implementation seems like the optimal choice. They're going to have to write the reference implementation anyway.
JonChesterfield 3y ago
Sounds great! I don't know what this is but there's a linked page at https://community.amd.com/t5/business/empowering-the-industry-with-open-system-firmware-amd-opensil/ba-p/599644 https://community.amd.com/t5/business/empowering-the-industr... which looks like a reasonable place to find out. Edit: I still don't know what this is. Could someone who does leave a comment to enlighten the rest of us?
- wmf 3y ago
  This is code to initialize an Epyc server processor. If you combine openSIL and EDK2 you can create a completely open source "BIOS" for a server.
gary_0 3y ago
This sounds relevant to what the Oxide Computer guys are doing (the Cantrill Crew, the Keepers of the Solaris Flame, etc). They're building AMD EPYC servers open-source style, and it sounded like they were making some headway in getting AMD to allow alternatives to the "proprietary vendor blobs" way of doing hardware.
- bcantrill 3y ago
  We are not using OpenSIL directly, but as a strong believer in the need for open source software at the lowest layers of the stack (i.e., silicon initialization and platform enablement), we are hugely supportive of this effort. Providers of silicon have embraced open source to varying degrees; AMD is showing that they understand the importance of open source (unlike several other vendors one might be able to name!) -- and we believe that customers will be the winners.
  - panick21_ 3y ago
    Would you eventually switch to OpenSIL or do you think staying with the minimal custom solution solution is better for your usecase.
    - bcantrill 3y ago
      No, we won't: OpenSIL is trying to solve a different problem in that it's still providing for systems that are ultimately booting yet other systems (and therefore have need for interfaces like UEFI, ACPI, etc.) By contrast, we are building a holistic system in which hardware and software are co-designed[0][1] -- we are not seeking to boot arbitrary systems and therefore don't need the abstractions that have been invented for that boundary. We remain strongly supportive of OpenSIL because we believe that this is the kind of innovation that open source platform enablement allows: when the lowest layers of the system are open, we allow for different approaches -- we need not all be confined by PC-era abstractions. [0] https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-not-to-open-it-the-need-for-holistic-systems/ https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-... [1] https://oxide-and-friends.transistor.fm/episodes/holistic-boot https://oxide-and-friends.transistor.fm/episodes/holistic-bo...
tester756 3y ago
What is the difference between this and https://github.com/tianocore/edk2 https://github.com/tianocore/edk2
- wmf 3y ago
  This is low-level code specifically to initialize AMD Epyc processors. EDK2 is higher-level processor-independent firmware code. You need both to build usable firmware.
- panick21_ 3y ago
  This is the UEFI boot flow: https://raw.githubusercontent.com/tianocore/tianocore.github.io/master/images/PI_Boot_Phases.JPG https://raw.githubusercontent.com/tianocore/tianocore.github... Currently AMD provides AGESA, and that is basically PEI part of the diagram. EDK2 is more like the DXE so on. OpenSIL will now replace AGESA in all AMD products and make that low level open source and serve as the PEI part. OpenSIL will also enable not just UEFI flow, but also Coreboot/Linuxboot and other open source boot alternatives.
temptemptemp111 3y ago
[dead]
unnah 3y ago
This is good news. However, the repo doesn't seem to contain any ARM code for the platform security processor (PSP), so I suppose that part would remain an encrypted binary blob?

221 points by wmf 3y ago

Another solid move by AMD. Due to their attitude towards open-source in the GPU department, I haven't used an Nvidia graphics card in years. Their APUs kill pretty much all the competition. Their CPUs are excellent for price/performance, efficiency, and core-count. And now this? If they can prioritize getting more AI/ML and 3D modeling capability into their cards, going all-red would become the new clear meta.

alanfranz 3y ago
If. If they can proritize _and_ execute on that vision.
- slt2021 3y ago
  there is also second mover advantage, where they just need to copy-cat the best part of nvidia's ML stack and dont waste time figuring out what works/what doesn't work. they will get users simply because they will be alternative to nvidia. Add good pricing strategy and it can be immediate success
  - msla 3y ago
    > there is also second mover advantage, where they just need to copy-cat the best part of nvidia's ML stack and dont waste time figuring out what works/what doesn't work. Seems like patents would stop that.
    - slt2021 3y ago
      didn't know nvidia patented matmul and dot product
      - m00x 3y ago
        There's a lot more involved than matmul and dot products.
    - bmicraft 3y ago
      Didn't the Google v Oracle lawsuit end up confirming that you can't patent an API?
      - slt2021 3y ago
        AMD doesnt have to implement CUDA api, they just need to make sure their compute framework works well with pytorch/tf/MLIR or whatever high level framework is being used. Cuda itself will change over time, so no reason for AMD to pick cuda, because nobody writes CUDA kernels by hand, they use high level frameworks
        woodson 3y ago
        But CUDA kernels are everywhere, not just in high-level frameworks. Look at DeepSpeed, for example, which is used in training LLMs.
        slt2021 3y ago
        So what? They can be replaced by amd kernels if there will be adequate tooling support
        deleted 3y ago
        [deleted]
      - orra 3y ago
        No, it confirmed reimplementing an API is not copyright infringement. The patent claims were rejected simply because the Google implementations were written in such a way the patents did not apply.
  - fatfingerd 3y ago
    I'm actually happier if they deliver a mediocre GPU performance seamlessly. I would be as annoyed as the gamers to be priced out of a great desktop/video setup. If hype more fully occupied Nvidia's fragile race cars I'd have a nicer laptop.
- justinjlynn 3y ago
  With Ryzen and their other recent products and their rapid pace of improvement, they certainly have developed a decent track record of that.
  - m00x 3y ago
    They're crushing it on hardware, but being left behind in the firmware/software.
    - justinjlynn 3y ago
      Getting Intel proprietary advantage in widely used open source packages and systems is something Intel has been very, very good at doing. I use POWER9 systems and... Yeah, the software porting situation has been rather annoying (especially in media processing libraries that rely on things like embree, opencolorio and the like)
gdevenyi 3y ago
One word. CUDA
- justinjlynn 3y ago
  Valve's Proton/wine... Apple's M5 cpu. Software/hardware layers, especially system software and hardware interfaces that must remain stable and compatible essentially forever, aren't the strong lock in mechanisms everyone thinks they are.
  - m00x 3y ago
    That absolutely doesn't work in ML training.
    - imtringued 3y ago
      It would work if AMD focused on ROCm support for their consumer GPUs. The reason for that is quite simple. Angry consumers using your GPUs produces a lot of data that helps you design future GPUs and improve the drivers.
    - jjoonathan 3y ago
      It absolutely does, but AMD's execution on this front has been unmitigated dogshit for the last decade and now every engineer in this niche has a scar or five from giving AMD chance after chance after chance and then limping back to NVDA when the slog is just too much. Now that they have money, I'm hoping they can turn this around. I hear that they have... but I've always heard that and it has never been true. I need to see to believe, now.
      - Pet_Ant 3y ago
        Are you referring to OpenCL?
        imtringued 3y ago
        https://www.phoronix.com/news/OpenCL-On-Mesa-Matrix https://www.phoronix.com/news/OpenCL-On-Mesa-Matrix
adrian_b 3y ago
This is indeed good, but for now it is just a small step towards restoring their previous documentation transparency. Before Zen, AMD published for each CPU the very useful "BIOS and Kernel Developer’s Guide". Starting with the first Zen, this previously public information has become secret. Hopefully, with OpenSIL equivalent information will become public again.
- userbinator 3y ago
  equivalent information will become public again. I'm not so hopeful, because it seems to have become common for companies to replace information with open source code, which amounts to nothing more than "put this constant in this register" with no detailed explanation of the why. I'd much rather they publish actual documentation than OSS.
  - delusional 3y ago
    Why not both? Good documentation with a reference implementation seems like the optimal choice. They're going to have to write the reference implementation anyway.

JonChesterfield 3y ago

Sounds great! I don't know what this is but there's a linked page at https://community.amd.com/t5/business/empowering-the-industry-with-open-system-firmware-amd-opensil/ba-p/599644 https://community.amd.com/t5/business/empowering-the-industr... which looks like a reasonable place to find out. Edit: I still don't know what this is. Could someone who does leave a comment to enlighten the rest of us?

wmf 3y ago
This is code to initialize an Epyc server processor. If you combine openSIL and EDK2 you can create a completely open source "BIOS" for a server.

gary_0 3y ago

This sounds relevant to what the Oxide Computer guys are doing (the Cantrill Crew, the Keepers of the Solaris Flame, etc). They're building AMD EPYC servers open-source style, and it sounded like they were making some headway in getting AMD to allow alternatives to the "proprietary vendor blobs" way of doing hardware.

bcantrill 3y ago
We are not using OpenSIL directly, but as a strong believer in the need for open source software at the lowest layers of the stack (i.e., silicon initialization and platform enablement), we are hugely supportive of this effort. Providers of silicon have embraced open source to varying degrees; AMD is showing that they understand the importance of open source (unlike several other vendors one might be able to name!) -- and we believe that customers will be the winners.
- panick21_ 3y ago
  Would you eventually switch to OpenSIL or do you think staying with the minimal custom solution solution is better for your usecase.
  - bcantrill 3y ago
    No, we won't: OpenSIL is trying to solve a different problem in that it's still providing for systems that are ultimately booting yet other systems (and therefore have need for interfaces like UEFI, ACPI, etc.) By contrast, we are building a holistic system in which hardware and software are co-designed[0][1] -- we are not seeking to boot arbitrary systems and therefore don't need the abstractions that have been invented for that boundary. We remain strongly supportive of OpenSIL because we believe that this is the kind of innovation that open source platform enablement allows: when the lowest layers of the system are open, we allow for different approaches -- we need not all be confined by PC-era abstractions. [0] https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-not-to-open-it-the-need-for-holistic-systems/ https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-... [1] https://oxide-and-friends.transistor.fm/episodes/holistic-boot https://oxide-and-friends.transistor.fm/episodes/holistic-bo...

tester756 3y ago

What is the difference between this and https://github.com/tianocore/edk2 https://github.com/tianocore/edk2

wmf 3y ago
This is low-level code specifically to initialize AMD Epyc processors. EDK2 is higher-level processor-independent firmware code. You need both to build usable firmware.
panick21_ 3y ago
This is the UEFI boot flow: https://raw.githubusercontent.com/tianocore/tianocore.github.io/master/images/PI_Boot_Phases.JPG https://raw.githubusercontent.com/tianocore/tianocore.github... Currently AMD provides AGESA, and that is basically PEI part of the diagram. EDK2 is more like the DXE so on. OpenSIL will now replace AGESA in all AMD products and make that low level open source and serve as the PEI part. OpenSIL will also enable not just UEFI flow, but also Coreboot/Linuxboot and other open source boot alternatives.

temptemptemp111 3y ago

[dead]

unnah 3y ago

This is good news. However, the repo doesn't seem to contain any ARM code for the platform security processor (PSP), so I suppose that part would remain an encrypted binary blob?