Measured: M4 Max multi-display allocation behavior with 3x 5K/165 panels (sticky pipes, synthesized modes, TB vs HDMI pooling)

[bnaert]

Measured: how the M4 Max display allocator actually behaves (3× 5K/165 panels + mixed configs)

This community — and discussion #4871 in particular — is where I found the only real prior art on macOS multi-display high-refresh limits, so I wanted to bring the data back here. I spent a week probing an M4 Max Mac Studio (macOS 27 Public Beta 2) with three LG 27GM950B panels (5120×2880 @ 165Hz native, DP 2.1/HDMI 2.1, DSC), plus a 4K/240 ASUS PG32UCDM3 and two QHD/144 ProArts for controls. Summary of what the allocator does, with the receipts condensed:

Findings

1. Per-display limits are soft. A single 27GM950B negotiates full native 5K @ 165 (2.43 Gpx/s) over both HDMI 2.1 and TB5 → USB-C-to-DP 2.1 cable — the monitor OSD confirms a genuine DP 2.1 link on the TB path. Apple documents 5K/120 as the single-display max; DSC makes the extra headroom real.

2. Two fast pipes, both claimable. Two GM9s run 5K/165 simultaneously (~4.87 Gpx/s) — one HDMI, one TB→DP. Apple's docs imply only one "fast class" display in 3+ display configs; in practice both fast pipes stay grantable.

3. Assignment is sticky and happens at enumeration. Once displays are connected, nothing re-deals the pipes. Concrete proof: in a triple config with the third display capped at 5K/60, manually dropping all three displays to 60Hz (2.65 Gpx/s total — headroom everywhere) still leaves the third display's mode list topping out at 60. Freeing bandwidth after the fact is invisible. Only physical replug re-enumerates.

4. Three distinct over-budget behaviors, never renegotiation:

• Refusal: with dual-165 held, a third GM9 on any TB port refuses to enumerate — no signal, no fallback mode.
• Basement demotion: hot-plugging into a marginally-over mix (2× GM9 + 2× QHD) drops the newcomer to a 3200×1800 @ 60 mode (~0.35 Gpx/s).
• Tailored synthesis: with 165/165 held and a 4K/240 panel plugged last on HDMI, macOS offers a fixed, synthesized 4K @ 97Hz as the top of the mode list (97/60/50/30/25/24). No standard timing exists at 97; it's computed.

5. The 97Hz mode is a continuous probe of the budget. 4K@97 ≈ 0.805 Gpx/s; add 2× 2.433 and the machine total is ~5.67 Gpx/s. It also retro-explains the GM9's 5K/60 grant on the same seat: 0.885 fits, 5K/65 (0.96) wouldn't — 60 was the largest EDID mode fitting the remainder, same algorithm. Working model: two priority fast pipes drawing first from a ~5.7 Gpx/s machine budget, third seat sized to the remainder.

6. Pooling by output path. With both fast grants on Thunderbolt, a third display on any TB port gets nothing, while the same panel on HDMI comes up at the remainder mode. The HDMI output behaves like an independent pipe — in the triple config it's the reason a third display exists at all.

7. Workaround that works without EDID tools: pre-setting the connected displays' refresh before hot-plugging the next display changes what the allocator grants (120/120 pre-set → third display enumerates instead of refusing). This is how the first triple config came up.

8. No Adaptive-Sync anywhere. None of these panels (full G-Sync/FreeSync on Windows) ever show a variable option on macOS in these configs — presumably the usual DP-only / no-HDMI-VRR / scaled+DSC interference constraints.

Full pixel-rate ledger

Config	Aggregate (Gpx/s)	Outcome
1× 5K165	2.43	✅ either port
2× 5K165	4.87	✅
2× 5K165 + 2× QHD144	5.92 req.	❌ newcomer demoted to 0.35
3× 5K165	7.30	❌ third refuses to enumerate
2× 5K120 + 5K60	4.42	✅ (via pre-set workaround)
2× 5K165 + 5K60	5.75	✅ best all-5K result
2× 5K165 + 4K@97 (synthesized)	5.67	✅ best mixed result
3× on Thunderbolt, any refresh	—	❌ no signal; third stream requires HDMI

(For contrast: the same three panels on an RTX 5090 run 165/165/165 at 10-bit — the limits above are allocator behavior, not the panels or links.)

Questions for people who know the internals

1. Does anything in IOKit / the display pipeline corroborate the "two fast pipes + remainder seat + ~5.7 Gpx/s budget" model, or is there a better framing?
2. Is there a reason the HDMI path acts as an independent pipe while the TB side refuses a third stream outright?
3. The BetterDisplay-shaped question: since assignment is decided at enumeration, could a pre-connection EDID override (presenting a panel as, say, 6K/60-class) coax the TB side into granting a third TB stream? Sticky assignment means the override must exist before connect — is that feasible with BetterDisplay's EDID tooling today?
4. Remaining discriminating experiment I can run: whether 2× QHD/144 at plain native (no supersampling) coexist with 165/165/60 — pipe model says yes (~each fits a standard slot), pure aggregate budget says no (~6.8 total). Happy to test and report back, along with any other configs people want probed.

Full writeup with the step-by-step receipts: https://gist.github.com/bnaert/14a4ad2e3ab5ece3a3520fe44a928fb9

[chiptoma]

Edit, 29/08: the arithmetic below is wrong. I was working cost out from active pixels when the allocator uses total pixels including blanking, so every number in this comment is about 5.7% light. Corrected in the follow-up. Short version: there is no 86 Hz ceiling and no headroom band, it is an exact 13,700, and a mode list that bottoms out at 90 takes two controllers rather than one, which makes 165 / 90 / 85 and 90 / 90 / 86 below impossible. The topology findings, the sleep re-deal and the EDID notes still stand.

Thanks for writing this up. It was the only prior art I could find and it stopped me returning three monitors I'd assumed were faulty.

I ran the same panels on a different topology for two weeks and ended up with the constants behind the behaviour you measured. Short version:

• Machine: MacBook Pro 16" M4 Max (Mac16,5), macOS 27.0 beta (26A5416b), 3× 27GM950B, two TB5 ports + built-in HDMI
• Result: 165 / 85 / 85, all three native 5120×2880, stable through cold boot, restart and sleep (and dock replug — not reliable, see edit)
• The limits aren't a Gpx/s budget. They're four pipes with constants published in IOKit
• One of your findings doesn't hold here: HDMI is not required for a third display

---

The model

Every external display controller publishes its limits. One command:

ioreg -l -w0 | grep -a MaxDisplayBandwidthLimitKey

node	MaxGP	MaxGPLite	MaxGPSum
disp0	12800	3900	23000	built-in panel
dispext0–dispext3	13700	3900	21400	four external controllers

Units are 10⁵ active px/s, so one pipe = 1.37 Gpx/s. MaxGPSum caps pipes within one controller. It is not a per-display ceiling. Reading it that way predicts 144 Hz as the maximum, which a measured 165 Hz refutes.

A display is granted a seat of one or two pipes. BetterDisplay already reports it as Maximum Source Bandwidth, and it only ever takes two values:

13700  = one pipe
27400  = two pipes

What each mode costs, and therefore what it's granted:

Mode	Units	Seat
5K @ 60	8,847	13700
5K @ 85	12,534	13700
5K @ 90	13,271	13700
5K @ 120	17,695	27400
5K @ 144	21,234	27400
5K @ 165	24,330	27400

Four pipes, and a 165 Hz display eats two of them. So:

Config	Pipes
165 / 85 / 85	4	✅ in use
165 / 90 / 85	4	❌ 5 pipes, 90 takes a pair. See edit
90 / 90 / 86	3	❌ 5 pipes, 90 takes a pair. See edit
two panels @ 165	4	✅ both hold 27400
165 / 165 / anything	5+	❌ third never enumerates
3 × 165	6	❌ impossible

Exactly one display can hold a pair, so exactly one can exceed 90 87 Hz.

---

The third seat has a hard ceiling: 86 Hz — retracted, see edit

Worth its own section because it's the number I'd most like others to check. One EDID ladder per rate, each tested against a dock replug and a cold boot:

Rate	Units	Margin	Replug	Cold boot
85	12,534	5.6%	✅	✅	reliable
86	12,681	4.4%	✅	✅	highest passing rate
87	12,829	3.3%	❌
88	12,976	2.2%	❌	✅	passed cold boot, died on first replug
90	13,271	0%		❌

The allocator wants 4 to 5 percent headroom below the refusal point. Two things worth stealing: cold boot is not the hardest test, re-enumeration is, and 12,976 is intermittent rather than dead, which is why 88 and 90 both looked fine before they weren't.

---

Your three questions

1. Does IOKit corroborate the model? Yes, above. Your framing is right in shape. The mechanism is quantised rather than continuous, and the quanta are published.

2. Why does HDMI act as an independent pipe? Here it doesn't, and this contradicts your finding 6. On this machine the output path makes no difference at all. Every combination gives every panel an identical 13700 seat, 4 lanes, 16.00 bpp:

Topology
HDMI + 2× TB5 direct	✅
HDMI + one wing direct + one on the hub	✅
centre on USB-C, no HDMI connected at all	✅
all three on USB-C	✅
all three on one hub, single Mac port	❌ third refused at any rate

That last row is the only real path limit, and it isn't bandwidth: two displays per Thunderbolt port, which Apple documents for M1 to M4 Pro/Max. A count limit, so no refresh reduction helps.

Your Studio granting 165/165/60 needs a fifth pipe, and your Result 7 says where it is. Mine has no fifth pipe because the built-in HDMI port is internally a DisplayPort link into a converter chip (Data source: DisplayPort to HDMI converter, HBR3, 25.92 Gbps). It works, 165 Hz included. What it costs is compression:

Path	DSC target
built-in HDMI @ 85 Hz	16.00 bpp
built-in HDMI @ 90 Hz	12.00 bpp
built-in HDMI, top end	8.00 bpp
USB-C, or DP UHBR20 @ 165	16.00 bpp

3. Could a pre-connection EDID override change the grant? Yes, but you shrink the ladder rather than enlarge it. Apple's own DTS engineer describes this method in developer forums thread 814201:

the EDID Emulator then side steps this issue by forcing the initial display to use only one pipe, freeing up a second pipe for the other display

The rule that makes a triple config permanent:

Every single-pipe display's top mode must fit one pipe, because any of them may be dealt last. Exactly one display may hold a pair, and it is exempt, since a pair is satisfiable from any two remaining pipes.

Cap both wings at 85, leave the centre's ladder topping out at 165, and deal order stops mattering.

---

One correction to your finding 3

Assignment at enumeration is right and it's the key insight in your post. But display sleep also re-deals the map, not just physical replug. An 80-minute unattended idle, everything attached and untouched:

21:20-21:36   stable, all three 13700, DSC 16.00
21:39:55      two panels each reallocate to 27400
              the third's bandwidth field goes empty
21:40-22:40   continuous re-enumeration
22:40:43      key pressed, one panel absent for a poll
22:41:17      all three back at 13700, DSC 16.00

With the third panel quiescent, the other two each grabbed a full pair. On wake they must release before the third can re-enter, and that release is a race. It won that night; the mornings a panel is missing are the same race lost.

That's why your finding 7 workaround is real but fragile. It holds until the monitors first blank.

Two side findings from the same capture: the panels never de-enumerated during sleep (display count held at 3, so LG's Deep Sleep does not drop HPD), and the dock was not involved (AC power throughout, the hub's 10G NIC never disappeared).

---

If you build ladders, four things that cost me time

1. Each input is a separate product ID with its own factory ladder. HDMI 0x5CF7 = 165/144/60, DP 0x5CF8 = 165/120/60, USB-C 0x5CF9 = 144/120/60. An override binds per input, so moving the cable to a different socket on the monitor silently drops it.
2. Always keep a custom ladder applied. Strip it and the factory fallback goes to 4K@120, not 5K@60, because macOS prefers a CTA-block 4K timing over a lower-rate 5K one. A ladder whose lowest rung is 5K means a bad allocation costs refresh, not resolution.
3. A custom EDID carries the serial of the panel it came from. Apply panel A's blob to B and B reports as A permanently. Since BetterDisplay matches on vendor + serial, the relabelled panel keeps matching the wrong profile and can't identify its way out. Check for three distinct serials after every cable move.
4. The USB-C input's DP version selector tops out at 1.4 (1.4 or 1.2, no 2.1), so HBR3 is that input's ceiling, matching LG's own 5K144 spec. The DP input offers 2.1 and trains UHBR20 ×4 at 77.58 Gbps.

---

A test for your Studio: I think 165/165/86 is available — number superseded, see the follow-up

Your third display landed on 60 Hz. I don't think that was a bandwidth ceiling, I think it was your panel's ladder. There is no rung between 60 and 120 on any input (see item 1 above), and 120 needs two pipes. The allocator took the largest mode the panel offered that fit one pipe. That's 60 on every input.

If so your third seat has been running at 68% of capacity. Cap that panel's EDID at 86, replug all three. If 86 doesn't take, walk down 85, 80, 75. Whatever appears measures your third seat exactly.

I'd say 60/40 it works outright. The doubt is your 4K@97: that's only ~8,050 units, well inside a whole 13700 pipe, so a full pipe should have offered far more. Something narrower is binding on your third seat and I can't tell what from here. Your constants would show it:

ioreg -l -w0 | grep -a MaxDisplayBandwidthLimitKey
sysctl -n hw.model
sw_vers -productVersion

Anyone with an M4 Pro, M3 Max or M5 Max, that output would be useful too. (For anyone tempted to upgrade for this: Apple's M5 Max display table is character-for-character identical to M4 Max. The only change is displays per Thunderbolt port, 2 → 4.)

---

@waydabber, two small things, take or leave.

BetterDisplay already reports Maximum Source Bandwidth, and the MaxGP* constants are one ioreg read away. Showing "granted seat vs pipe budget", or warning when a requested mode would cross a pipe boundary (the 86 → 90 step), would have saved me two weeks.

Also a reporting bug: on a UHBR10 link the report shows Link encoding: 8b/10b and computes effective bandwidth as 40 × 0.8 = 32.00 Gbps. DP 2.1 mandates 128b/132b for all UHBR rates, so the true figure is 38.79. Reproducible arithmetic fingerprint if you want to chase it.

None of this was measurable without the CLI. Thank you for it.

[waydabber]

Thank you, this is a really useful write-up!

[chiptoma]

Right, I need to correct this properly. The numbers in my comment above are wrong.

The allocator isn't counting active pixels, it's counting total pixels including blanking. So for the GM9 that's 5280 × 2962 = 15,639,360, not 5120 × 2880. Everything I posted is about 5.7% light.

Mode	I said	Actually	Seat
5K @ 85	12,534	13,293	13700
5K @ 87	12,829	13,606	13700
5K @ 88	12,976	13,763	27400
5K @ 90	13,271	14,075	27400
5K @ 165	24,330	25,805	27400

The 90 Hz row is the one that matters. 14,075 is over 13,700 but under 27,400, so a 90 Hz display doesn't sit in one pipe the way I said. It takes two. Which means a mode list that bottoms out at 90 doesn't degrade gracefully when it can't get its top mode, it just quietly eats a second controller and something else doesn't come up.

I had 165/90/85 and 90/90/86 in my table as working. Neither can be, they're both 5 pipes. So if you were building EDIDs off my numbers: nothing above 85 as the lowest mode. I ended up pulling 30 files out of my own library.

The headroom thing

I also said the allocator wants 4 to 5 percent headroom below the limit and put a margin column in to back it up. There's no headroom. That was me fitting a rule to bad arithmetic. It's a hard step:

cost ≤ 13700  →  one controller
cost ≤ 27400  →  a pair
otherwise     →  refused

And you don't have to infer it, the allocator logs its own budgets at init:

AED: platform ext display pipe limits:
     max_bw_single=13700  max_bw_double=27400  max_bw_limited=0

max_bw_limited is 0, so there's no third budget either, which I'd also wondered about.

That puts the one-pipe ceiling at 87.60 Hz for 5K. The reason I think it's exact rather than roughly-there is a 4K sweep I'd done on the same panels and never connected to this: 150 works at 13,266, 155 fails at 13,708. Eight units over. You don't get that out of a percentage rule.

87 Hz works, and the dock was the problem

I reported 87 failing a dock replug. It doesn't. 13,606, well inside, and it survives a cold boot and two replugs.

What was actually failing was my OWC hub not coming back on the Thunderbolt bus. I've since had that at 85, and once with the hub not in the TB tree at all and nothing in the Thunderbolt logs, so the host was never even offered a link. Never had anything to do with refresh rate. Which also means "stable through dock replug" comes out of my summary, because it isn't.

Where 13700 lives

Went looking for it after all this. It's not in the kernel, not in any kext, not in the device tree. It's in the DCP firmware, Firmware/dcp/t604xdcp.im4p, as immediates:

mov w10, #0x3584             ; 13700  external GP
mov w10, #0x3200             ; 12800  internal GP
mov x9, #0x28f5c28f5c28f5c3  ; ceil(2^68/100) — divide by 100
cset w0, hs                  ; return (limit/100) >= requested

Note the divide. It compares in units of 10 Mpx/s, so 13700 is really 137, and anything from 13700 to 13799 behaves the same.

Signed firmware, so there's nothing to patch. There are 317 runtime properties in there you can set by boot-arg and I went through the lot of them, none is this. So it's still capping the EDID or nothing, same as before, but at least I've stopped wondering.

@bnaert, revised test

My "cap it at 86" was built on the ceiling I've just retracted, so ignore the number. The reasoning under it still holds I think: your 60 wasn't a bandwidth ceiling, it was what your EDID was offering. There's no mode between 60 and 120 on any input of that panel and 120 needs two pipes, so 60 was just the biggest single-pipe mode on the list.

Worth doing now because the answer tells us something either way. If your fifth pipe is another dispext you should get 87. If macOS is handing you the internal dcp that a Studio isn't otherwise using, that's 12,800 and you'd top out around 81. Cap at 85, replug all three, then try 87.

Your 4K@97 still bothers me though. Blanking-inclusive that's only about 8,600 units, nowhere near either limit, so something narrower is constraining that seat and I can't see what from here.

Checking your own machine

ioreg -rlw0 | grep -a MaxDisplayBandwidthLimitKey
sysctl -n hw.model; sw_vers -productVersion -buildVersion

Use the -r. Without it ioreg roots at the tree root and a class that's plainly there reads as absent. Cost me an evening and two wrong conclusions.

The max_bw_* line only prints at init so you need persist-debug and a reboot:

sudo log config --subsystem com.apple.driver.AppleDisplayManager \
     --mode "level:debug,persist:debug"
# reboot, then
log show --last boot --predicate 'eventMessage CONTAINS "pipe limits"' --style compact
sudo log config --subsystem com.apple.driver.AppleDisplayManager --mode "level:default"

Still after M4 Pro / M3 Max / M3 Ultra / M5 Max numbers if anyone's got them.

macOS 27.0 26A5421a, MacBook Pro 16 M4 Max, 3 × 27GM950B, all read-only. Running 165/85/85. 87 is there on the wings and I'm not using it, two hertz on the panels either side of me isn't worth two more custom EDIDs to reapply every time Apple ships a beta.