The devices connected to the Thunderbolt dock would be sharing the bandwidth from one of the Thunderbolt ports on the Mac mini.What is the different between getting a M2 Mini + TB4 dock to expand the TB4 ports to four vs. getting M2 Pro with four TB4 ports?
True that! Say for example I have three SSDs. Here's the difference:Each Thunderbolt port on Apple Silicon Macs have dedicated bandwidth that’s not shared with the other ports.
Using a hub/dock might slow the speeds of external drives, etc. I've experienced this first-hand with my SanDisk 1 TB SSD, where if I have it plugged in directly to a USB-C port (the SSD isn't Thunderbolt), it gets the near-native speeds. However, when I plug it into a hub, it gets 50% of the native speed, so I'm losing quite a bit of performance when plugged into a hub. It could be a bottleneck with the hub though because it's a cheap piece of s**t. That's the difference I see every day, but there are probably many other differences I'm unaware of.
More like 44 Gbps for M2 and 88 Gbps for M2 Pro since data is limited to ≈22 Gbps per port (or maybe 24 or 25 Gbps in some cases).Total bandwidth of M2 Mac mini with two Thunderbolt 4 ports: 80Gbps
Total bandwidth of M2 Pro Mac mini with four Thunderbolt 4 ports: 160Gbps
The rest of the bandwidth of a Thunderbolt port can only be used for displays. The M2 and M2 Pro can only connect two displays to Thunderbolt.
That table very specifically says "Minimum PC video requirements". That implies for the whole PC and not for individual ports. Apple doesn't call the M2 MacBook Air Thunderbolt 4 because they only support one external display. But for the M2 Pro and Max they seem to be covered.To pass Thunderbolt 4 certification each TBv4 must be able to provide DisplayPort output. Either Apple is not passing TBv4 certification (and blowing smoke on specs page) or you can get as many displays as there are TB ports. Which means M2 Pro can do 4 display.
![]()
Frequently Asked Questions (FAQs) | Thunderbolt Technology Community
www.thunderbolttechnology.net
Can get away with starving off a port from video is a USB4 thing, not a TBv4 compliance.
That table very specifically says "Minimum PC video requirements". That implies for the whole PC and not for individual ports.
Apple doesn't call the M2 Thunderbolt 4 because they only support one external display. But for the M2 Pro and Max they seem to be covered.
Pretty sure they do certify the whole PC solution. For instance, they make it a requirement to have Intel VT-d DMA protection, that has nothing to do with the port but it is in the controller and the operating system.That is nonsense. It can't be the whole PC including other ports not in the standard. The TB standard is for the TB infrastructure. That' it. TB can't specify 'oh you gotta put another HDMI port" on the box (something not directly coupled to Thunderbolt).
I don't have the spec, but it certainly has to be more nuanced than that.However, one of the differences between USB4 sockets and Thunderbolt 4 socket is the latter is not suppose to under provision video out. That's way the previous M1 systems were "USB4 with Thunderbolt (3) ". They didn't meet TBv4 standards.
The change is that on the M2 Mac mini you can use both Thunderbolt 4 ports to drive two displays where previously it was one display on TB3 and one on HDMI. Now if you use both TB4 ports to drive displays, the HDMI port is unused.Go take a look at the Specs page. Apple does call the ports on the M2 Mini Thunderbolt 4 ports. That is a change from the M1 Mini. Either the M2 video out subsystem has been upgraded or Apple is duplicitously misusing the label.
More precisely, two 4K60 10bpc RGB displays from a single Thunderbolt port. This requirement means the Thunderbolt controller has two DisplayPort inputs and supports 40 Gbps. I suppose there's a seperate requirement that it can support HBR3 DisplayPort input (8K30 or 4K120).It's quite clear that the PC only needs to be able to output two 4K displays in total to be certified TB4.
The base M2 Mac mini does that. Apple far exceed that with support for one 6K and one 5K simultaneously over the two TB ports.
It doesn't need to be able to do two 4K60 displays from all Thunderbolt ports. For example, Intel Maple Ridge Thunderbolt 4 controller can do two 4K60 displays from a single Thunderbolt port or one from each Thunderbolt port but it can't do 4 total displays (two displays per Thunderbolt port).To pass Thunderbolt 4 certification each TBv4 must be able to provide DisplayPort output. Either Apple is not passing TBv4 certification (and blowing smoke on specs page) or you can get as many displays as there are TB ports. Which means M2 Pro can do 4 display.
Using your formula and value (pixel clock x 12 bits per pixel for DSC), I get the same result as you for the ASD, but not for the XDR:More like 44 Gbps for M2 and 88 Gbps for M2 Pro since data is limited to ≈22 Gbps per port (or maybe 24 or 25 Gbps in some cases).
The rest of the bandwidth of a Thunderbolt port can only be used for displays. The M2 and M2 Pro can only connect two displays to Thunderbolt. Display bandwidth is pixel clock x bits per pixel. bits per pixel is usually 30 but can be reduced to 12 for displays that support DSC.
4K60 = 16 Gbps
5K60 = 29 Gbps (LG UltraFine 5K - no other display can be connected to the same Thunderbolt port)
5K60 = 11 Gbps (Apple Studio Display)
6K60 = 15.4 Gbps (Apple Pro Display XDR)
Display bandwidth is mostly one way so it might reduce write performance if it exceeds 18 Gbps but have little effect on read performance.
You're only including active pixels. Some time is reserved for horizontal and vertical front porch, sync width, and back porch.Using your formula and value (pixel clock x 12 bits per pixel for DSC), I get the same result as you for the ASD, but not for the XDR:
ASD: 5120 x 2880 x 60 x 12/10^9 = 10.6 Gbps
XDR: 6016 x 3384 x 60 x 12/10^9 = 14.7 Gbps
6016x3384@60.000Hz 210.960kHz 1286.01MHz h(8 32 40 +) v(118 8 6 -)
8 bits + FRC or true 10bit use the same bandwidth. All 10bpc are transmitted and the display decides what to do with the bits.Also, does the fact that the XDR has a true 10-bit panel (as compared with the 8 bits +FRC used by the ASD) have any effect on bandwidth?
25.92 Gbps is the amount of data that can be sent for HBR3. Pixels are data. No adjustment is required, unless the data requires extra processing (if FEC is added).Elsewhere, you wrote that DP 1.4 allows "25.92 Gbps of video data before 8b/10b encoding". Does that mean we need to adjust that 25.92 Gbps figure and, if so, what is the bottom-line max video bandwidth of DP 1.4 and DP 2.0? I'm curious because I'm wondering what's the most each can drive without DSC.
I'm curious why a TB3/4 controller's 40 Gbps on the wire doesn't enable ≈77.37/2 = 38.69 Gbps of video data. Is it because TB3/4 doesn't have its own video protocol, and is thus limited to VESA's HBR3?25.92 Gbps is the amount of data that can be sent for HBR3. Pixels are data. No adjustment is required, unless the data requires extra processing (if FEC is added).
The 25.92 Gbps of data is turned into 32.4 Gbps on the wire because it takes 10b on the wire to encode 8b of data. This 8b/10b encoding doesn't exist while DisplayPort is tunnelled over Thunderbolt since Thunderbolt has its own method (64b/66b) of encoding bits on the wire.
DSC is usually combined with FEC (Forward Error Correction) which requires a small amount of overhead.
DisplayPort 2.0 uses 128b/132b encoding = 0.9696969696%. But there's some additional overhead (FEC is always enabled) that makes this more like 96.7%. So UHBR20 which is 80 Gbps on the wire is ≈77.37 Gbps of data.
https://en.wikipedia.org/wiki/DisplayPort
Right. Thunderbolt uses DisplayPort for video. Thunderbolt controllers currently handle two HBR3 x4 DisplayPort inputs. A GPU can send 25.92 Gbps of data to each input of the Thunderbolt controller as 32.4 Gbps HBR3. The Thunderbolt controller takes the 32.4 Gbps input and tunnels the 25.92 Gbps result. A Thunderbolt controller at the other end of the tunnel restores the 8b/10b encoding used by the display.I'm curious why a TB3/4 controller's 40 Gbps on the wire doesn't enable ≈77.37/2 = 38.69 Gbps of video data. Is it because TB3/4 doesn't have its own video protocol, and is thus limited to VESA's HBR3?
Given what you said about TB tunneling, if you are driving a montitor using a TB port, even with HBR3's 32.4 Gbps cap, why isn't the data transmission limit 32.4*64/66 ≈ 31.4 Gbps (less overhead) rather than 25.92 Gbps?
If you use an app like AllRez to look at the info provided by macOS on an Intel Mac about a display that is using DSC, you can see that the framebuffer is using 12bpc (36 bpp) and that DSC is using a target bpp of 12 which means the compression ratio is 3:1.And what's your basis for assuming a 30/12 = 2.5:1 compression ratio for Apple's DSC implementation? Has Apple said this is what they use?
I've seen 3:1 quoted as the maximum compression ratio for DSC, but if you're starting with 30 bits per pixel, the following table suggests 3.75:1 is the maximum. [VESA claims these are all visually lossless, but I would want to see multiple reliable independent studies before accepting this, particularly at the highest compression ratios.]
com.apple.CoreDisplay
called dscTargetBPP
that may allow changing the default from 12 to something else. Maybe 8 can work? I haven't checked when this preference actually gets used. I think CoreDisplay is for Intel Macs only?dscbpp=8
- for Catalina and later). If you're using Open Core or OCLP, then you can replace Lilu and WhateverGreen with my versions. If you use any other Lilu based kexts then they need to be recompiled using the headers from my Lilu.kext. That patch, in conjunction with the CheckTimingWithRange patch (add a boot-arg -cdfon
- For Tiger and later), can enable 4K240 and beyond on Intel Macs with a GPU that supports DSC (tested with 6800XT and Sequoia). DP to HDMI adapters are not tested.I did a bit more reading and came up with this summary of encoding:Right. Thunderbolt uses DisplayPort for video. Thunderbolt controllers currently handle two HBR3 x4 DisplayPort inputs. A GPU can send 25.92 Gbps of data to each input of the Thunderbolt controller as 32.4 Gbps HBR3. The Thunderbolt controller takes the 32.4 Gbps input and tunnels the 25.92 Gbps result. A Thunderbolt controller at the other end of the tunnel restores the 8b/10b encoding used by the display.
The 64b/66b encoding is for Thunderbolt data only. The GPU connected to the host Thunderbolt controller and the display connected to the peripheral Thunderbolt controller rely on DisplayPort 8b/10b encoding. Also note that Thunderbolt is actually 41.25 Gbps on the wire. The 40Gbps number is before the 64b/66b encoding is applied. Thunderbolt is maybe the only protocol that uses the pre-encoding bandwidth number when discussing it's link rate. USB 5 Gbps is actually 4 Gbps. USB 10 Gbps is actually 9.7 Gbps (actually more than twice is fast a USB 5 Gbps), SATA 6G is actually 4.8 Gbps, etc.
Ah, cool. So if you had two different displays that each needed, say, 19 Gbps, you couldn't drive both using two HBR3 connections on a single TB controller, because the DP protocols would require each HBR3 connection to be assigned 25.92 Gbps, i.e., you can't defeat the DP stuffing symbols with two different connections. But you can with a single connection, for displays that allow dual tiling.However, Apple can force two HBR3 connections over Thunderbolt for the Apple Pro Display XDR to support dual tile mode. One would think that two HBR3 connections would require 51.84 Gbps, but each tile of the XDR is only 648.91MHz (19.4673 Gbps) and Thunderbolt does not transmit the DisplayPort stuffing symbols that are used to fill the DisplayPort link rate. The stuffing symbols are recreated at the end of the tunnel. So the XDR can use 38.9346 Gbps of Thunderbolt in this mode.
Here I'm confused. The actual uncompressed data volume is 30 bpp (thats how you got 38.9346 Gbps for the uncompressed XDR). So if, with DSC, you're instead transmitting 12 bpp, the true compression ratio (original data volume/transmitted data volume) is 2.5:1, no?If you use an app like AllRez to look at the info provided by macOS on an Intel Mac about a display that is using DSC, you can see that the framebuffer is using 12bpc (36 bpp) and that DSC is using a target bpp of 12 which means the compression ratio is 3:1.
Right. HDMI 2.1 uses 16b/18b encoding so it would be 42.6666667 Gbps but it may use FEC which reduces that to ≈42 Gbps.*HDMI 2.1's "48 Gbps" is actually 42.0 Gbps of usable data ( https://en.wikipedia.org/wiki/HDMI )
I suppose if Apple can force dual HBR3 for a single display, they could do it for two displays. But they only choose to do it for the two tiles of a single Apple Pro Display XDR.Ah, cool. So if you had two different displays that each needed, say, 19 Gbps, you couldn't drive both using two HBR3 connections on a single TB controller, because the DP protocols would require each HBR3 connection to be assigned 25.92 Gbps, i.e., you can't defeat the DP stuffing symbols with two different connections. But you can with a single connection, for displays that allow dual tiling.
Not sure why you included the "and you're using a TB dock to drive two XDR's on a single port" part. Since the XDR uses DSC, you can connect two to a single Thunderbolt port. Or, if you have two XDRs running at 6K60 connected to the same Thunderbolt port, then it means they must be using DSC.This also means that Macs that always drive the XDR without DSC (unless, as was discussed above, your Mac supports DSC, and you're using a TB dock to drive two XDR's on a single port, like with the CalDigit TS4: https://www.caldigit.com/thunderbolt-station-4/).
Mac mini 2018 and 13 inch Mac Book Pro has Intel Graphics which is limited to HBR2.[NB: Apple also officially supports the XDR on the following Macs, but only with resolutions <6k: iMac Pro (2017); Mac Mini (2018); 13" MBP (2016–2019); 13" MBP with two TB3 ports (2020). I believe all of them have 40 Gbps TB3, but apparently the implementation you described to enable a 38.9346 Gbps data rate can't be done with them.]
No extraneous bits. The framebuffers are different.Here I'm confused. The actual uncompressed data volume is 30 bpp (thats how you got 38.9346 Gbps for the uncompressed XDR). So if, with DSC, you're instead transmitting 12 bpp, the true compression ratio (original data volume/transmitted data volume) is 2.5:1, no?
Or is this a case analogous to the way DP, etc. fudge the bandwidth? I.e., just as they are including extraneous dummy bits to inflate the link rates, is VESA including extraneous bits (in this case, the added 4 bpp needed for the frame buffer) to inflate the compression ratio?
On intel Macs, the default for DSC is always 12bpp. I suppose Apple could add special cases for specific displays when they are created. DSC@16bpp should be possible. I think the max is 63.9375 bpp (includes 4 fractional bits).I wonder how Apple will handle the expected 120 Hz 5k monitor, which requires ~55 Gbps uncompressed. Will they introduce it alongside a DP 2.0-capable Mac Pro? And for backwards compatability, will they use standard DSC compression (~22 Gbps), which would enable them to transmit it with a single HBR3 link? Or will they make use of a scheme like what they do with the XDR, which would enable a lower compression ratio to reduce the potential for artifacts? Does DSC offer lower compression ratios?
You should use a CVT-RB2 timing calculator. You can download and install edid-decode.The new XDR is rumored to be 7k, and also possibly 120 Hz. If they do use that res, I wonder if that's because it's also about the highest that can be run uncompressed at 120 Hz under TB5 (max data rate 120 Gbps, https://arstechnica.com/gadgets/202...ec-triples-bandwidth-to-120gbps-with-a-catch/ ). Extrapolating from the 6k data rate:
7k uncompressed @ 120 Hz: 39 Gbps x (7/6)^2 x 2 ~ 106 Gbps
7.4k uncompressed @ 120 Hz: 39 Gbps x (7.4/6)^2 x 2 ~ 119 Gbps
8k uncompressed @ 120 Hz: 39 Gbps x (8/6)^2 x 2 ~ 139 Gbps
width=$((7 * 1024))
height=$((width * 9 / 16))
refresh=120
edid-decode --cvt w=$width,h=$height,fps=$refresh,rb=2
CVT: 7168x4032 119.999978 Hz 16:9 512.160 kHz 3712.135000 MHz (RBv2)
Hfront 8 Hsync 32 Hback 40 Hpol P
Vfront 222 Vsync 8 Vback 6 Vpol N
pixelclock=3712.135000 # MHz
bc <<< "scale=3; $pixelclock * 12 / 1000"
44.545 # Gbps
bc <<< "scale=3; $pixelclock * 30 / 1000"
111.364 # Gbps
Two choices, just like for 6K: tile or DSC.But how would that work if TB5 is limited to using DP 2.0's UHBR20 (77 Gbps)? Are they going to tile the display like they do now with the XDR under TB4 & HBR3? Or will TB5 have its own video protocol so tiling is not needed?
This also means that Macsthatalways drive the XDR without DSC (unless, as was discussed above, your Mac supports DSC, and you're using a TB dock to drive two XDR's on a single port, like with the CalDigit TS4: https://www.caldigit.com/thunderbolt-station-4/).
Sorry for the delayed response. I corrected a typo (see strikeout) in case that was causing the confusion.Not sure why you included the "and you're using a TB dock to drive two XDR's on a single port" part. Since the XDR uses DSC, you can connect two to a single Thunderbolt port. Or, if you have two XDRs running at 6K60 connected to the same Thunderbolt port, then it means they must be using DSC.