M5 Pro DCP bandwidth allocation: asymmetric 27,400/13,700 Mbps split between dispext0/dispext1 on dual 5K configuration

Is the 27,400/13,700 Mbps asymmetric allocation observed on dual 5K configurations the expected manifestation of the two-pipe architecture described in thread 814201, or a distinct allocation policy specific to dual-display scenarios?

Yes, it's the same general issue, though my "pipe" description there was more of a general analogy, not an engineering-level description.

Note that you're driving the first monitor at 144Hz:

5120x2880 @ 144Hz, Maximum Source Bandwidth: 27,400 Mbps, HDR enabled

...which is more than the 120Hz required to drive both monitors at 5K.

Is there a configuration approach that allows both displays to receive adequate bandwidth allocation?

I believe this would work if a hardware adaptor restricted the first monitor to 120Hz.

The WindowServer assertion failure in max_src_rect_width_by_pipes()

This is a known issue (r.170248892), but it seems to be tied to monitor hot plug, particularly while the machine is asleep, not display allocation.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Confirmed the configuration behavior with the first monitor manually set to 5120x2880 @ 120Hz before connecting the second monitor. Test results (both monitors connected, BetterDisplay 4.3.3 reports): First monitor (dispext0@B0000000):

Current Mode: 5120x2880 @ 120Hz Maximum Source Bandwidth: 27,400 Mbps Maximum Source Width: 7680 Allocation maintained after second monitor hotplug

Second monitor (dispext1@90000000):

Current Mode: 3840x2160 @ 120Hz Preferred Mode at connection level: 3840x2160 @ 120Hz, 13,700 Mbps Maximum Source Bandwidth: 13,700 Mbps Maximum Source Width: 6720 Cannot negotiate 5120x2880 at any refresh rate on the smaller pipe

Observations: The 120Hz cap on the first monitor prevents the runtime reallocation that previously occurred on second-monitor hotplug. However, the second monitor's connection-level preferred mode caps at 3840x2160 / 13,700 Mbps regardless of the first monitor's bandwidth consumption — the smaller pipe does not appear to receive additional bandwidth when the larger pipe is operating below its 27,400 Mbps ceiling. This is consistent with a fixed asymmetric two-pipe budget structure on M5 Pro (27,400 / 13,700 Mbps), rather than a shared pool that can rebalance based on demand. The BetterDisplay 4.3.3 allocation limits exposure (horizontal: 3360, 3840 pixels HiDPI / 6720, 7680 pixels LoDPI) is consistent with two sub-pipes of differing maximum widths. Connection topology note: Both monitors connect via USB-C, which on the 27GM950B is limited to DisplayPort 1.4 (OSD exposes DP 1.4 or DP 1.2 only — DP 2.1 is not available on the USB-C input). The DP 1.2 option caps the display at 4K, so a downward hardware cap on the first monitor isn't viable for preserving 5K capability on that connection.

Questions:

Is the 27,400 / 13,700 Mbps split a fixed M5 Pro DCP characteristic, or is there a configuration mechanism that allows the smaller pipe to receive additional bandwidth when the larger pipe is underutilized? Does the smaller pipe support 5120x2880 at any refresh rate, or is 3840x2160 @ 120Hz / 13,700 Mbps its maximum achievable mode regardless of OS state? Is the WindowServer assertion failure (r.170248892) expected to be addressed in a future macOS update, given that the underlying hotplug allocation logic appears tied to the same pipe assignment mechanism?

Confirmed the configuration behavior with the first monitor manually set to 5120x2880 @ 120Hz before connecting the second monitor.

How did you make this change? The problem here is that what matters ISN'T the monitors specific setting at a given moment, it's what the mac "sees" as it's valid configuration range. This can't really be done via software on that mac, or do I think most displays behave in a way that would make this work[1]. That's why I suggested a physical adaptor- it prevents the mac from "knowing" that the monitor is capable of a higher resolution

Is the WindowServer assertion failure (r.170248892) expected to be addressed in a future macOS update,

Per long standing policy, DTS generally doesn't talk about if/when any given bug will be fixed. However, as a general comment, WindowServer bugs, particularly crashes, are taken very seriously since their functional impact is broadly similar to a kernel panic (basically, the whole system "goes away"). In practice, that means two things:

1. Fixing them is given a fairly high priority, since the impact is so high.

2. We often defer shipping that fixes until the next major update ("macOS 27.0") instead of shipping it in a sofware update ("macOS 26.x").

given that the underlying hotplug allocation logic appears tied to the same pipe assignment mechanism?

To be clear, the crash appears to simply tied of display reconfiguration, not the low level pipe assignment. Keep in mind that the entire bandwidth allocation process happens in the kernel at the point the display is attached, so that entire process actually finished before the WindowServer was even told a new display existed, much less started to interact with it. Indeed, the crash here appears to be tied to the WindowServer not handling things properly after the display has been removed/reconfigured.

Does the smaller pipe support 5120x2880 at any refresh rate, or is 3840x2160 @ 120Hz / 13,700 Mbps its maximum achievable mode regardless of OS state?

Yes, it is possible for a MacBook Pro M5 to drive 2 displays 5K (5120 x 2880) at 120Hz. However, there is one qualifier to that. In my experience, our technical specifications for this are EXTREMELY precise, so if you're not doing EXACTLY what the specification says, I can't promise it will work. Here is the specification:

"One display up to a native resolution of 8K (7680 x 4320) at 60Hz, 5K (5120 x 2880) at 120Hz, or 4K (3840 x 2160) at 240Hz, plus a second display up to a native resolution of 5K (5120 x 2880) at 120Hz or 4K (3840 x 2160) at 200Hz over Thunderbolt or HDMI"

...which means one of the displays probably needs[2] to be on Thunderbolt/HDMI.

Is the 27,400 / 13,700 Mbps split a fixed M5 Pro DCP characteristic, or is there a configuration mechanism that allows the smaller pipe to receive additional bandwidth when the larger pipe is underutilized?

Neither. The issue isn't "fundamental" to the hardware, however, all of this is happening in the kernel immediately at connect time, which is why fixing it is not straightforward.

For the curious, their are a few different issues that make this complicated to address:

• Any new display is completely nonfunctional until the kernel finishes this configuration process, since user space can't draw to the screen until the kernel has create a display pipeline to that monitor.

• The system PRIMARY goal is to ensure that the user has some kind of functioning display, even at the cost of functionality.

• The nature of the display process and real world hardware means that the system doesn't actually have anyway to "know" whether or not a given configuration ACTUALLY works.

That dynamic is what, historically, lead to the system presenting it's timed "can you see this?" alert, which reset the display back to it's previous configuration if the user didn't approve the change prior to the timeout. That is, the best way to "know" the user can actually use the display you just configured is to present a dialog the user could only acknowledge if they were able to see the screen.

In any case, theoretically, the solution to for the user to setup the configuration they want and for the system to then save and reuse that configuration as need. However, the problem here is that this kind of "saved preferences" is MUCH harder to do in the kernel than it looks/seems.

The kernel doesn't have any general access to the disk/file system, particularly when it comes to display hardware, as the display needs to function before storage discovery even STARTS, not to mention that the volume is encrypted. Data can be stored in NVRAM, but that space is inherently quite limited.

Now, there is a standard solution to these issues, with the simplest form looking something like this:

• The kernel brings up the device in a "standard" way on it's own.

• A user space component/daemon detects the device and retrieves it's configuration data from the file system.

• That user space component send that configuration data into the kernel to the relevant driver.

• The kernel driver reconfigures based on that new configuration.

It's certainly possible for that same approach to be applied here, but the work is significant and hasn't yet happened, which is why the current situation exists.

[1] Theoretically, the display COULD do this, but I don't see any reason why the display vendor would.

[2] I'm a well aware of all the technical arguments that could be made about how/why USB-C could/should work. The issue here is that what ultimately determines the devices behavior isn't the buses capabilities, but the in kernel drivers implementation.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thank you.. Update with revised connection topology: Connection setup:

Monitor 1: Mac built-in HDMI 2.1 port → LG-supplied Ultra High Speed HDMI cable (48 Gbps certified) → LG 27GM950B HDMI input set to "HDMI 2.1 PC" mode Monitor 2: Mac TB5 port → Silkland DP80 USB-C cable → LG 27GM950B USB-C input (DP Alt Mode, monitor's USB-C input is limited to DP 1.4 per OSD)

Initial state (both monitors connected, no third-party software intervention): Monitor 1 (HDMI): 5120x2880 @ 120Hz HiDPI, YCbCr 4:4:4 Limited Range, 27,400 Mbps allocation. Monitor 2 (USB-C): 3840x2160 @ 120Hz HiDPI, RGB Full Range, 13,700 Mbps allocation. The kernel selected 4K HiDPI as the default mode on the smaller-allocation pipe — 5K HiDPI was not offered by macOS natively. After forcing HiDPI 5K on Monitor 2 via BetterDisplay 4.3.3: Monitor 2 transitioned to: 5120x2880 @ 60Hz HiDPI (VRR 48-60Hz), HDR10 RGB Full Range, 13,700 Mbps allocation. So the dual 5K HiDPI configuration is only achievable when a third-party utility (BetterDisplay) overrides the default macOS mode selection on the secondary display. Without that override, macOS defaults to 4K HiDPI on the smaller-allocation pipe. Full BetterDisplay 4.3.3 report data (both monitors, after HiDPI override on Monitor 2): Monitor 1 (HDMI, dispext0@B0000000):

Current Mode: 5120x2880 @ 120Hz HiDPI (VRR 48-120Hz) Color Mode: HDR10_444LimitedRange Maximum Source Bandwidth: 27,400 Mbps Maximum Source Width: 7680 Transport Type: hdmi Preferred Mode: 5120x2880 @ 165Hz, 27,400 Mbps

Monitor 2 (USB-C, dispext2@0):

Current Mode: 5120x2880 @ 60Hz HiDPI (VRR 48-60Hz) Color Mode: HDR10_RGBFullRange Maximum Source Bandwidth: 13,700 Mbps Maximum Source Width: 6720 Transport Type: dp Preferred Mode: 3840x2160 @ 120Hz, 13,700 Mbps

Observations: The asymmetric 27,400/13,700 Mbps allocation persists regardless of which monitor uses HDMI versus USB-C. Changing the connection type for one monitor changed which pipe each monitor received, but did not resolve the asymmetry. The kernel's default mode selection on the smaller-allocation pipe defaults to 4K HiDPI — the 5K HiDPI mode is only accessible via third-party override, and only achievable at 60Hz with VRR/HDR encoding due to the 13,700 Mbps ceiling.

Does the M5 Max chip exhibit the same asymmetric two-pipe allocation behavior, or does it provide symmetric pipe allocation between two external displays? Specifically, would the same dual 5K configuration (one HDMI 2.1 + one USB-C DP Alt Mode, identical to the topology described above) result in both displays receiving equivalent bandwidth allocation natively, with both at 5K HiDPI as default selections, on M5 Max?

The documented architectural difference (M5 Max showing four entries in MaxSrcRectWidthForPipe vs M5 Pro's two) suggests M5 Max may have additional sub-pipes available, but the underlying kernel allocation logic you described would still apply to either chip. Whether this results in symmetric, native dual 5K HiDPI for the described topology on M5 Max is the specific question.

Forgot to add the 4k connection vs 5k Connection via one connection on HDMI 2.1 and the other USB-C/TB changes depending on which connection is connected to the mac first.

OK. So what you're describing isn't about the kernel. More specifically, this ONLY works:

After forcing HiDPI 5K on Monitor 2 via BetterDisplay 4.3.3: Monitor 2 transitioned to: 5120x2880 @ 60Hz HiDPI (VRR 48-60Hz), HDR10 RGB Full Range, 13,700 Mbps allocation. So the dual 5K HiDPI configuration is only achievable when a third-party utility (BetterDisplay) overrides the default macOS mode selection on the secondary display.

...because the kernel's pipe configuration allowed enough bandwidth to support that configuration. What IS being caused by the kernel is that you're not able to take the second monitor to 120Hz. I believe that's a side effect of the display configuration the first monitor is presenting, notably:

Maximum Source Width: 7680

The documented architectural difference (M5 Max showing four entries in MaxSrcRectWidthForPipe vs M5 Pro's two) suggests M5 Max may have additional sub-pipes available,

Yes, it does.

but the underlying kernel allocation logic you described would still apply to either chip.

Yes, it would.

Whether this results in symmetric, native dual 5K HiDPI for the described topology on M5 Max is the specific question.

It's hard to be entirely certain without testing, but I believe the M5 Max would end up driving both of these monitors at 5k/120Hz

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thank you for the direct answer on M5 Max behavior — that's the specific data point I needed for the configuration decision. Closing this out as resolved. — Reza