The two DisplayPorts on the card are inputs, you run a loopback cable (or two) from the GPU to the USB4 card and it muxes the video into one (or both) of the USB4 outputs.

Loopback cables are a bit clunky, but it does mean there's no pressure on the PCI-E bus from moving the pixels from the GPU to the USB4 card.

I bet if they put the displayport inputs on the inside with an optional passthru bracket in the box to get them out of the case as needed, we'd start to see GPUs offered with internal displayport outputs too.

Basically the CD-ROM analog audio cable all over again.

Thats kinda lame... I was hoping there was software support for the GPU to share the framebuffer RAM with the USB4 controller, and there being some way for the OS to prioritize some fixed bandwidth to make sure it doesn't get starved.

Apple kinda has this in their M1/M2 SoC's where the GPU is entirely separate from the stream-data-from-ram-to-the-display logic.

Sounds like something that would be a pain to get broad OS/driver support for – and all just for the sake of avoiding a small external loopback cable?

Well it also means you can have as many displays as you like...

And put displays onto hubs and cable extenders.

What's the use case for this kind of setup?

connecting usb-c-only external monitor / vr goggles

so you need to have video signal and power on one usb-c output.

> Does that mean my screen goes blank if I ever get contention on the bus?

The monitor has a framebuffer of it's own.

Otherwise how could it display the OSD (On Screen Display)?

It's not really a framebuffer, but a tiny bit of RAM that just gets scanned out on the applicable parts of lines when the OSD is active --- certainly not the whole screen.