Not the integrated GPU

Field notes on a laptop display-topology migration, still mid-journey.

Two sockets, one controller

Three monitors, one laptop, and one USB dock old enough to be a bottleneck. Two of the three
monitors ran through it: a 4K panel and an ultrawide, both sharing one USB link with the keyboard,
the mouse, and Ethernet. The third monitor, a second 4K panel, was already wired natively straight
to the discrete GPU over HDMI, no dock involved.

The laptop has two USB-C sockets, and the working assumption going in was that a monitor plugged
into either one would land on the integrated graphics, the way a lot of thin-and-light laptops
route USB-C video. The two ports look identical. They aren't quite: one carries power delivery up
to 100W and DisplayPort 2.1, the other tops out at DisplayPort 1.4 with no power delivery at all.
Both are wired to the same USB controller underneath, the only one this laptop has. A different
configuration of the same chassis swaps one of those ports for Thunderbolt; this one doesn't, and
that was confirmed by checking the controller list directly rather than trusting the spec sheet for
this exact model.

The port routes to the discrete GPU, not the integrated one

Moving the ultrawide monitor from the old dock onto the power-delivery USB-C port — native
DisplayPort Alt Mode, the mode that carries real DisplayPort video directly over a USB-C connector,
no dock in between — settled the assumption by measurement instead of guesswork. The monitor came
up attached to the discrete GPU. Not the integrated graphics chip doing double duty on the internal
panel and the USB-C port both, which was the original assumption. A separate, dedicated card, the
same one already driving one of the 4K monitors over HDMI.

Display	Was driven by	Now driven by
Internal panel (2560×1600 · 165Hz)	integrated GPU	integrated GPU
4K panel, HDMI (3840×2160 · 60Hz)	discrete GPU	discrete GPU
Ultrawide (3440×1440 · 60Hz → 100Hz)	the dock	discrete GPU
4K panel, dock (3840×2160 · 60Hz)	the dock	the dock (cable ordered)

Four displays across three adapters, read out of dxdiag before and after the first move. Only the
ultrawide changed hands. The second 4K panel is still on the dock, waiting on a cable.

The other USB-C port hasn't been tested the same way yet. The reasonable guess is that it behaves
the same, since both ports sit on the same controller, but a guess is exactly the thing this whole
exercise exists to replace with a measurement, so it stays a guess until it's checked.

Faster the moment the dock was out of the path

With the ultrawide on its own native connection, dxdiag showed it running at 3440×1440. The old
dock connection had topped out at 60Hz for that monitor, full stop. There was no higher option to
select. The panel itself supports 100Hz; the dock's video path never exposed anything past 60,
because it wasn't sending real DisplayPort signal at all — it was compressing the whole desktop into
a video stream and shipping that over USB.

The refresh rate didn't jump to 100Hz on its own, though. Straight after the re-cable, the display
still reported 59.97Hz, because Windows carries a monitor's previous setting forward across a
different physical connection rather than picking the best one available. The "Choose a refresh
rate" dropdown listed nine options, four of them marked with an asterisk meaning the adapter
synthesised them rather than the monitor actually supporting them:

Refresh rate	Note
99.90 Hz	unmarked
75.03 Hz	adapter-synthesised
72.19 Hz	adapter-synthesised
70.07 Hz	adapter-synthesised
60 Hz
59.97 Hz	selected
59.94 Hz
56.25 Hz	adapter-synthesised
50 Hz

Picking the unmarked 99.90Hz by hand got a 100Hz reading in dxdiag afterward.

A cable upgrade doesn't come with an automatic refresh-rate upgrade attached. Somebody has to go
into the settings and pick it.

A tool that reported the wrong monitor entirely

One check along the way turned up something worth flagging on its own, separate from the dock:
Win32_VideoController, a common way of asking Windows what resolution and refresh rate a graphics
adapter is currently running, gave a confidently wrong answer in this exact multi-monitor setup. It
reported the
integrated graphics chip as running the ultrawide's resolution at 60Hz. The integrated chip was
never connected to that monitor at all. It was driving the laptop's own internal screen, at a
completely different resolution and refresh rate. dxdiag, read directly, had the real picture:
internal panel on the integrated chip, ultrawide hanging off the old dock. The first tool wasn't
lying about a number — it was reporting the wrong adapter's numbers as if they belonged to a monitor
they'd never touched.

Tool	Reported
Win32_VideoController	Integrated graphics, 3440×1440 at 60Hz — the ultrawide's mode, on an adapter that was never wired to it
dxdiag	Integrated graphics, 2560×1600 at 165Hz — the laptop's own internal panel, which is what it was actually driving

The same adapter, read two ways, on the same machine on the same day. I'd check with a second tool
before trusting a report like that in any setup with more than one screen.

The bandwidth math the dock was quietly doing

The old dock's USB link carries something like 4 gigabits a second, shared across both monitors, the
keyboard and mouse, and the network connection. A single 4K panel at 60Hz, uncompressed, needs
roughly 12.8 gigabits a second on its own. Two monitors, both routed through that one dock, meant
somewhere around 25 gigabits of raw pixel data getting squeezed into a 4-gigabit pipe, continuously,
the entire time both screens were on. Something has to give, and what gave was a real-time
compression pass running in software the whole time, on hardware never asked whether it minded.

Native DisplayPort Alt Mode over USB-C, by contrast, has room to spare: the standard this laptop's
faster port supports moves tens of gigabits a second, more than enough for one monitor at its native
resolution and refresh rate with nothing left to compress. Once the ultrawide moved off the dock,
its own share of that math simply stopped being a problem.

Where this actually stands

One monitor is done: natively connected, correctly identified as running off the discrete GPU, and
finally at the refresh rate it was always capable of. A cable for the second monitor, DisplayPort
this time rather than the general-purpose USB-C to USB-C cable currently in use, has been ordered
but not yet installed. Once it lands, the old dock drops out of the video path entirely and keeps
one job: charging and networking, which is what a general-purpose USB link is good at.

Nothing here was fixed by buying better hardware. The laptop, the monitors, and the faster port were
all already sitting there. The fix was checking which port actually did what, instead of assuming
the label on the box.

---

Originally published at thekilted.dev/not-the-integrated-gpu.