4 ms·

Apple has a very complicated Display Controller design Can anyone in the know give more information here? Why would Apple want to do this? What could they be d

Apple has a very complicated Display Controller design Can anyone in the know give more information here? Why would Apple want to do this? What could they be doing that's so complicated in the display controller?

gjsman-1000 4y ago
https://twitter.com/marcan42/status/1549672494210113536 https://twitter.com/marcan42/status/1549672494210113536 and https://twitter.com/marcan42/status/1415360411260493826?lang=en https://twitter.com/marcan42/status/1415360411260493826?lang... and https://twitter.com/marcan42/status/1526104383519350785 https://twitter.com/marcan42/status/1526104383519350785 As to why? Well, if it ain't broke don't fix it from iPhone, but it is still a bit of a mystery. In a nutshell from those threads: 1. Apple's DCP silicon layout is actually massive, explaining the 1 external display limit 2. Apple implements half the DCP firmware on the main CPU and the other half on the coprocessor with RPC calls, which is hilariously complicated. 3. Apple's DCP firmware is versioned, with a different version for every macOS release. This is also why Asahi Linux currently uses a "macOS 12.3" shim, so they can focus on the macOS 12.3 DCP firmware in the driver, which will probably not work with the macOS 12.4+ DCP firmware or the macOS 12.2- firmware. I can totally see why Apple doesn't want people using their low-level Metal implementation that deals with the mess yet.
- chongli 4y ago
  Yeah it makes perfect sense that they don't want to expose any of that complexity to 3rd parties and risk constant breakage with new models. I'm just really curious about what sort of complex logic they have going on in that silicon.
- phire 4y ago
  The complexity with the firmware split across the main CPU and a coprocessor seems to be a historical artefact. Seems the DCP driver was originally all on the main CPU, and when apple got these cheap coprocessor cores, they took a lazy approach of just inserting a simple RPC layer in the middle. The complexity for Asahi comes from the fact that it's a c++ API that can change very dynamically from version to version. And yes, these ARM coprocessor cores are cheap, apple have put at least 16 of them [1] on the M1, on top the 4 performance and 4 efficiency cores. They are an apple custom design that implement only the 64bit parts of the ARMv8 spec. I'm not entirely sure why the actual DCP is so big, but it's not because of the complex firmware. Potentially because the DCP includes enough dedicated RAM to store an entire framebuffer on-chip. If so, they will be doing this because it allows for lower power consumption. The main DRAM could be put in a power-saving mode and kept there for seconds or even minutes at a time without having to wake it up multiple times per frame, even when just showing a static image. [1] https://twitter.com/marcan42/status/1557242428876537856 https://twitter.com/marcan42/status/1557242428876537856
  - throwaway08642 4y ago
    @marcan42 said that on the M1 MacBook Pro models, the DCP also implements hardware-level antialiasing for the notch and rounded display corners.

gjsman-1000 4y ago

https://twitter.com/marcan42/status/1549672494210113536 https://twitter.com/marcan42/status/1549672494210113536 and https://twitter.com/marcan42/status/1415360411260493826?lang=en https://twitter.com/marcan42/status/1415360411260493826?lang... and https://twitter.com/marcan42/status/1526104383519350785 https://twitter.com/marcan42/status/1526104383519350785 As to why? Well, if it ain't broke don't fix it from iPhone, but it is still a bit of a mystery. In a nutshell from those threads: 1. Apple's DCP silicon layout is actually massive, explaining the 1 external display limit 2. Apple implements half the DCP firmware on the main CPU and the other half on the coprocessor with RPC calls, which is hilariously complicated. 3. Apple's DCP firmware is versioned, with a different version for every macOS release. This is also why Asahi Linux currently uses a "macOS 12.3" shim, so they can focus on the macOS 12.3 DCP firmware in the driver, which will probably not work with the macOS 12.4+ DCP firmware or the macOS 12.2- firmware. I can totally see why Apple doesn't want people using their low-level Metal implementation that deals with the mess yet.

chongli 4y ago
Yeah it makes perfect sense that they don't want to expose any of that complexity to 3rd parties and risk constant breakage with new models. I'm just really curious about what sort of complex logic they have going on in that silicon.
phire 4y ago
The complexity with the firmware split across the main CPU and a coprocessor seems to be a historical artefact. Seems the DCP driver was originally all on the main CPU, and when apple got these cheap coprocessor cores, they took a lazy approach of just inserting a simple RPC layer in the middle. The complexity for Asahi comes from the fact that it's a c++ API that can change very dynamically from version to version. And yes, these ARM coprocessor cores are cheap, apple have put at least 16 of them [1] on the M1, on top the 4 performance and 4 efficiency cores. They are an apple custom design that implement only the 64bit parts of the ARMv8 spec. I'm not entirely sure why the actual DCP is so big, but it's not because of the complex firmware. Potentially because the DCP includes enough dedicated RAM to store an entire framebuffer on-chip. If so, they will be doing this because it allows for lower power consumption. The main DRAM could be put in a power-saving mode and kept there for seconds or even minutes at a time without having to wake it up multiple times per frame, even when just showing a static image. [1] https://twitter.com/marcan42/status/1557242428876537856 https://twitter.com/marcan42/status/1557242428876537856
- throwaway08642 4y ago
  @marcan42 said that on the M1 MacBook Pro models, the DCP also implements hardware-level antialiasing for the notch and rounded display corners.