5 ms·

> The silver lining of using this complicated DCP interface is that DCP does in fact run a huge amount of code – the DCP firmware is over 7MB! It implements com

> The silver lining of using this complicated DCP interface is that DCP does in fact run a huge amount of code – the DCP firmware is over 7MB! It implements complicated algorithms like DisplayPort link training, real-time memory bandwidth calculations, handling the DisplayPort to HDMI converter in the Mac mini, enumerating valid video modes and performing mode switching, and more. It would be a huge ordeal to reverse engineer all of this and implement it as a raw hardware driver, so it is quite likely that, in the end, we will save time by using this higher-level interface and leaving all the dirty work to the DCP. In particular, it is likely that newer Apple Silicon chips will use a shared DCP codebase and the same interface for any given macOS version, which gives us support for newer chips “for free”, with only comparatively minor DCP firmware ABI updates. How interesting: by moving some of the driver to firmware, Apple has effectively made it easier for OSs like Linux to have good support for the hardware, because the OS<->hardware protocol operates at a higher level of abstraction and may work across multiple chips. The trade-off is that the protocol is not stable and so Linux has to decide which versions it will support, and make sure the OS driver always matches the version of the hardware firmware: > As a further twist, the DCP interface is not stable and changes every macOS version! [...] Don’t fret: this doesn’t mean you won’t be able to upgrade macOS. This firmware is per-OS, not per-system, and thus Linux can use a different firmware bundle from any sibling macOS installations.

edeion 5y ago
If I recall correctly, high end hard drives used a protocol called SCSI in the 90s that was mostly embedded in hardware.
- minedwiz 5y ago
  Somewhat related, SSDs run an entire microcontroller on-board to translate from I/O requests from the OS to proper use of the flash hardware.
  - vlovich123 5y ago
    If I recall correctly that’s not the case on Apple platforms. They do the translation themselves across raw NAND.
    - monocasa 5y ago
      No, there's firmware on the Apple NVMe drives doing FTL, etc. and exposing a traditional block device.
      - my123 5y ago
        It's on the main SoC on M1. (ANS2 block, with the FW being loaded by iBoot1) NVMe exposed as an MMIO device directly, not as a PCIe one.
        vlovich123 5y ago
        My knowledge was about the first iPhone since I swear I sat next to the guy implementing it (I was an intern at the time). Maybe Apple was just writing the FW themselves and I’ve misremembered? Apple devices definitely have better I/O performance than any other mobile device from what I recall.
neilalexander 5y ago
> How interesting: by moving some of the driver to firmware, Apple has effectively made it easier for OSs like Linux to have good support for the hardware, because the OS<->hardware protocol operates at a higher level of abstraction and may work across multiple chips. If I am remembering right, this was the original idea behind UEFI drivers too — you could in theory write drivers that the firmware would load and they would present a simpler/class-compatible interface to whatever operating system was loaded after that. I think Apple did pretty much this on Intel Macs for a number of things.
- mehrdada 5y ago
  Even legacy BIOS effectively served a similar purpose before the functionality provided ended up being too limited. The name BIOS, Basic Input/Output System, in fact focuses on this functionality of serving the I/O function calls more than initialization/booting the system. Of course these days a modern OS just ignores the BIOS and drives the hardware itself once booted (at least partially due to the fact its design predates protected mode).
- erincandescent 5y ago
  > If I am remembering right, this was the original idea behind UEFI drivers too — you could in theory write drivers that the firmware would load and they would present a simpler/class-compatible interface to whatever operating system was loaded after that. I think Apple did pretty much this on Intel Macs for a number of things. Not really; pretty much every UEFI driver shuts itself down when you call ExitBootServices, which is necessary before you can do virtual addressing (as required by every OS) (My memory is fuzzy but I think the one exception is UNDI/the network driver, but you never want to use UNDI to drive your network card except out of desparation)
skavi 5y ago
I remember hearing about how the M1 Macs were very quick to get displays running when they were plugged in and to change the display configuration. I guess the DCP is why.
- marcan_42 5y ago
  No, moving it to a coprocessor doesn't really have an impact here. That's just down to their software stack being good.
  - skavi 5y ago
    The iOS software stack? Because the way I heard it, the M1 Macs are noticeably faster than other Macs at these tasks.
    - marcan_42 5y ago
      Their display controller driver, regardless of what CPU it runs on.
webmobdev 5y ago
> Apple has effectively made it easier for OSs like Linux to have good support for the hardware Wow, that's a tall stretch of a conclusion, bordering on ignorance, when the reality is that the M1 only supports macOS! Apple fans shouldn't be blind to the fact that developers are trying to reverse engineer the M1 to run Linux on it. (And they have a long way to go before they succeed). Apple has not even published any literature that can help system developers create and run alternative OSes on it. And this is by design - the M1 (and all Arm processor based macs) are designed to be a a closed box like their other iDevices. (Honestly, except for an academic interest, I believe open source developers are wasting their time trying to support such a useless "closed" piece of hardware, and instead should be boycotting it - or we'll end up losing control over our desktop computers too as other manufacturers move towards this model too). > On most mobile SoCs, the display controller is just a piece of hardware with simple registers. While this is true on the M1 as well, Apple decided to give it a twist. They added a coprocessor to the display engine (called DCP), which runs its own firmware (initialized by the system bootloader), and moved most of the display driver into the coprocessor. But instead of doing it at a natural driver boundary… they took half of their macOS C++ driver, moved it into the DCP, and created a remote procedure call interface so that each half can call methods on C++ objects on the other CPU! Talk about overcomplicating things… Reverse engineering this is a huge challenge ....
- scrollaway 5y ago
  Oh boy if we didn't even try to reverse engineer things to bring closed systems to the open world ... Where would we even be? I don't think we'd have gotten past UNIX.
  - webmobdev 5y ago
    That's a fair point. I am thinking from the other end - if these efforts were instead redirected at supporting open hardware systems, how much more beneficial it would be for the open movement? By reverse engineering closed systems, you are adding value to it but not changing its nature - you are not really making it "open" (the next iteration will just "close" it again). Meanwhile, Apple just uses these reverse engineering effort cleverly for PR for the M1 through social media marketing. In effect, you are just helping a trillion dollar company design better closed systems while helping them make more money (by attracting naive Linux users to spend money on their hardware). There are open systems that are struggling because they don't have talented developers working on their projects. Wish these developers would instead work on these projects - Sailfish OS, PineOS, Librem - Purism etc. For example, there are a lot of Intel / Arm tablets that either run only Windows or Android. It would be nice to run one of these Linux based mobile OS distros on it, and create a genuine alternate to the Android / ios duopoly on Tablets, right?

edeion 5y ago

If I recall correctly, high end hard drives used a protocol called SCSI in the 90s that was mostly embedded in hardware.

minedwiz 5y ago
Somewhat related, SSDs run an entire microcontroller on-board to translate from I/O requests from the OS to proper use of the flash hardware.
- vlovich123 5y ago
  If I recall correctly that’s not the case on Apple platforms. They do the translation themselves across raw NAND.
  - monocasa 5y ago
    No, there's firmware on the Apple NVMe drives doing FTL, etc. and exposing a traditional block device.
    - my123 5y ago
      It's on the main SoC on M1. (ANS2 block, with the FW being loaded by iBoot1) NVMe exposed as an MMIO device directly, not as a PCIe one.
      - vlovich123 5y ago
        My knowledge was about the first iPhone since I swear I sat next to the guy implementing it (I was an intern at the time). Maybe Apple was just writing the FW themselves and I’ve misremembered? Apple devices definitely have better I/O performance than any other mobile device from what I recall.

neilalexander 5y ago

> How interesting: by moving some of the driver to firmware, Apple has effectively made it easier for OSs like Linux to have good support for the hardware, because the OS<->hardware protocol operates at a higher level of abstraction and may work across multiple chips. If I am remembering right, this was the original idea behind UEFI drivers too — you could in theory write drivers that the firmware would load and they would present a simpler/class-compatible interface to whatever operating system was loaded after that. I think Apple did pretty much this on Intel Macs for a number of things.

mehrdada 5y ago
Even legacy BIOS effectively served a similar purpose before the functionality provided ended up being too limited. The name BIOS, Basic Input/Output System, in fact focuses on this functionality of serving the I/O function calls more than initialization/booting the system. Of course these days a modern OS just ignores the BIOS and drives the hardware itself once booted (at least partially due to the fact its design predates protected mode).
erincandescent 5y ago
> If I am remembering right, this was the original idea behind UEFI drivers too — you could in theory write drivers that the firmware would load and they would present a simpler/class-compatible interface to whatever operating system was loaded after that. I think Apple did pretty much this on Intel Macs for a number of things. Not really; pretty much every UEFI driver shuts itself down when you call ExitBootServices, which is necessary before you can do virtual addressing (as required by every OS) (My memory is fuzzy but I think the one exception is UNDI/the network driver, but you never want to use UNDI to drive your network card except out of desparation)

skavi 5y ago

I remember hearing about how the M1 Macs were very quick to get displays running when they were plugged in and to change the display configuration. I guess the DCP is why.

marcan_42 5y ago
No, moving it to a coprocessor doesn't really have an impact here. That's just down to their software stack being good.
- skavi 5y ago
  The iOS software stack? Because the way I heard it, the M1 Macs are noticeably faster than other Macs at these tasks.
  - marcan_42 5y ago
    Their display controller driver, regardless of what CPU it runs on.

webmobdev 5y ago

> Apple has effectively made it easier for OSs like Linux to have good support for the hardware Wow, that's a tall stretch of a conclusion, bordering on ignorance, when the reality is that the M1 only supports macOS! Apple fans shouldn't be blind to the fact that developers are trying to reverse engineer the M1 to run Linux on it. (And they have a long way to go before they succeed). Apple has not even published any literature that can help system developers create and run alternative OSes on it. And this is by design - the M1 (and all Arm processor based macs) are designed to be a a closed box like their other iDevices. (Honestly, except for an academic interest, I believe open source developers are wasting their time trying to support such a useless "closed" piece of hardware, and instead should be boycotting it - or we'll end up losing control over our desktop computers too as other manufacturers move towards this model too). > On most mobile SoCs, the display controller is just a piece of hardware with simple registers. While this is true on the M1 as well, Apple decided to give it a twist. They added a coprocessor to the display engine (called DCP), which runs its own firmware (initialized by the system bootloader), and moved most of the display driver into the coprocessor. But instead of doing it at a natural driver boundary… they took half of their macOS C++ driver, moved it into the DCP, and created a remote procedure call interface so that each half can call methods on C++ objects on the other CPU! Talk about overcomplicating things… Reverse engineering this is a huge challenge ....

scrollaway 5y ago
Oh boy if we didn't even try to reverse engineer things to bring closed systems to the open world ... Where would we even be? I don't think we'd have gotten past UNIX.
- webmobdev 5y ago
  That's a fair point. I am thinking from the other end - if these efforts were instead redirected at supporting open hardware systems, how much more beneficial it would be for the open movement? By reverse engineering closed systems, you are adding value to it but not changing its nature - you are not really making it "open" (the next iteration will just "close" it again). Meanwhile, Apple just uses these reverse engineering effort cleverly for PR for the M1 through social media marketing. In effect, you are just helping a trillion dollar company design better closed systems while helping them make more money (by attracting naive Linux users to spend money on their hardware). There are open systems that are struggling because they don't have talented developers working on their projects. Wish these developers would instead work on these projects - Sailfish OS, PineOS, Librem - Purism etc. For example, there are a lot of Intel / Arm tablets that either run only Windows or Android. It would be nice to run one of these Linux based mobile OS distros on it, and create a genuine alternate to the Android / ios duopoly on Tablets, right?