4 ms·

Bandwidth wise it’s possible but the M1 doesn’t support it. It only supports a single display “scan out” on thunderbolt. Plus a second that must be via HDMI. T

Bandwidth wise it’s possible but the M1 doesn’t support it. It only supports a single display “scan out” on thunderbolt. Plus a second that must be via HDMI. The issue as I understand it is the lack of ability for 2 “scan out engines” to run and output at the same time. Given the MacBook Air/Pro support only 1 external display I imagine the HDMI port connects to the hardware that would otherwise connect to the internal LCD. Hence why the mini can do 2 but the MacBooks only 1. I hope this limitation to be lifted in the next generation. It’s the only reason I haven’t purchased one. I want 3 external monitors on a MacBook Pro.

my123 6y ago
For an actual Thunderbolt display (contrasted to the DisplayPort alternate mode), the sole DisplayPort controller shouldn't be a limitation, as render offscreen + DMA to the device would work just fine in that case. Think that Apple did this to not have to say "you can use two of those displays that are plugged in over Type-C, but not those two other displays... that are also plugged in over Type-C".
- eqvinox 6y ago
  > For an actual Thunderbolt display (contrasted to the DisplayPort alternate mode), the sole DisplayPort controller shouldn't be a limitation, as render offscreen + DMA to the device would work just fine in that case. No, that's not how this is implemented. The difference between a Thunderbolt display and a DP-alt-mode display is that the TB one decodes the additional DP-in-TB layer to get at the DisplayPort data. And since it does TB to do that, it can (but doesn't have to) implement PCIe & USB functions too. TB displays do not implement a PCIe endpoint for the actual display contents and don't have any DMA capability. The DisplayPort stream is wrapped inside TB packets (with some empty bits being left out, e.g. H/Vblank); the Display (or TB dock/hub) just decodes the packets back into DisplayPort. ... which means the host needs to be able to encode a particular number of DP streams into the TB connection, and depending on the silicon and its connections this may only be 1 stream. The only way around that would be with DisplayPort MST support, since that's only one GFX->TB stream for DP :) Thunderbolt essentially transports 3 kinds of packets over its connection: - TB native packets (bit of a FireWire followup, kinda) - PCIe packets - DisplayPort packets
  - my123 6y ago
    Very interesting... I wonder why they went that way instead of PCIe... (I assumed that TB always meant that PCIe endpoints were used for Thunderbolt)
    - eqvinox 6y ago
      The DisplayPort over TB link is very much synchronous/isochronous to the source; it's transported over TB at explicitly scheduled intervals and there are almost no buffers at the source and destination. PCIe would've needed larger buffers at the very least, and would need quite a bit of QoS mangling (there isn't really a bandwidth reservation system on PCIe, so best you could do would be to just give it highest priority)... which also means more places to fail & get wonky. Also, there's no preexisting standard for framebuffers over PCIe.

my123 6y ago

For an actual Thunderbolt display (contrasted to the DisplayPort alternate mode), the sole DisplayPort controller shouldn't be a limitation, as render offscreen + DMA to the device would work just fine in that case. Think that Apple did this to not have to say "you can use two of those displays that are plugged in over Type-C, but not those two other displays... that are also plugged in over Type-C".

eqvinox 6y ago
> For an actual Thunderbolt display (contrasted to the DisplayPort alternate mode), the sole DisplayPort controller shouldn't be a limitation, as render offscreen + DMA to the device would work just fine in that case. No, that's not how this is implemented. The difference between a Thunderbolt display and a DP-alt-mode display is that the TB one decodes the additional DP-in-TB layer to get at the DisplayPort data. And since it does TB to do that, it can (but doesn't have to) implement PCIe & USB functions too. TB displays do not implement a PCIe endpoint for the actual display contents and don't have any DMA capability. The DisplayPort stream is wrapped inside TB packets (with some empty bits being left out, e.g. H/Vblank); the Display (or TB dock/hub) just decodes the packets back into DisplayPort. ... which means the host needs to be able to encode a particular number of DP streams into the TB connection, and depending on the silicon and its connections this may only be 1 stream. The only way around that would be with DisplayPort MST support, since that's only one GFX->TB stream for DP :) Thunderbolt essentially transports 3 kinds of packets over its connection: - TB native packets (bit of a FireWire followup, kinda) - PCIe packets - DisplayPort packets
- my123 6y ago
  Very interesting... I wonder why they went that way instead of PCIe... (I assumed that TB always meant that PCIe endpoints were used for Thunderbolt)
  - eqvinox 6y ago
    The DisplayPort over TB link is very much synchronous/isochronous to the source; it's transported over TB at explicitly scheduled intervals and there are almost no buffers at the source and destination. PCIe would've needed larger buffers at the very least, and would need quite a bit of QoS mangling (there isn't really a bandwidth reservation system on PCIe, so best you could do would be to just give it highest priority)... which also means more places to fail & get wonky. Also, there's no preexisting standard for framebuffers over PCIe.