Atnam schrieb:
Läuft sowas normalerweise nicht immer über die GPU ? Da kenne ich mich tatsächlich nicht so gut aus. Mein Laienverständnis wäre z.B. das die externen Displays über die Display Engines laufen, das interne Display aber über die GPU. Warum sollte man die GPU Seite nicht auch einfach auf ein externes Display umleiten können?
Nein, ganz und gar nicht.
Klassischerweise hat eine GPU einen generischen Compute-Teil der einfach nur auf dem RAM der GPU arbeitet, dann den Ausgabe Teil ("Display Engine"), der vom RAM an alle Arten von Bildausgängen geht. Und typischerweise ein oder mehrere weitere Hardwarebeschleuniger die auch nur auf dem RAM Inhalt arbeiten.
Bei einer modernen dGPU ist das was du so mindestens auf dem Chip finden würdest. Aber bei SoCs / APUs, wo das mit der CPU gemischt wird, ist das auch flexibler. Der RAM ist ja auch geteilt. Und jeglicher Hardwarebeschleuniger der nur auf dem RAM Inhalt arbeitet kann großteilig unabhängig vom Rest an den Speicher angebunden werden. Intel zB hat bei Meteor Lake mit mehreren Tiles das aufgeteilt. Die Display Engine / Pipes sind dabei mit dem Memory Controller im zentralen Tile. GPU Compute und Media Engine(s) sind auf dem GPU Compute Tile und Phys für die Ausgabe des Bildes (via Ports) sind (mindestens großteilig) im IO Tile. Also es muss nicht alles so zusammenhängen wie wir das von klassischen dGPUs gewohnt sind.
Zu dem was die Display-Engine / Pipes normalerweise tun:
Ein Bildschirm hat Timings. So zB ein 4K60 Display nach CVT-RB Timingstandard hat 4000 Pixel pro Zeile und 2222 Zeilen. Die zusätzlichen Zeilen und Spalten sind "Blanks" die dafür da sind um das Timing für den Monitor sicherzustellen. Die Display-Pipe muss die Daten für jede Zeile rechtzeitig aus dem RAM erhalten. Evtl Konvertierungen durchführen zwischen Farbräumen und Formaten (RGB vs YCbCr, Chroma Subsampling, SDR nach HDR, Farbprofile die auf alle Pixel angewendet werden etc, Dithering). Und dann die Pixel der Reihe nach mit den korrekten Timings ausgeben. Und modernerweise (mit TB oder verschiedenen Möglichkeiten für Stecker-Standards) auch getrennt von wie die Signale physikalisch ausgegeben werden. Seit wir DSC haben, findet die DSC Kompression auch dort statt.
Die Display Pipes machen also vergleichsweise relativ wenig. Sie müssen am ehesten rechtzeitig die Speicherinhalte anfordern und evtl. in einer "Warteschlange" aufbewahren, bis sie wirklich gebraucht werden. Hauptsächlich Dinge pro Pixel verarbeiten (DSC ist ein wenig aufwendiger) und für die Timings permanent im Auge behalten bei welchem Pixel die Ausgabe aktuell ist (also wie viel der Pixel in der aktuellen Zeile wurden schon ausgegeben, in welcher Zeile ist die aktuelle Ausgabe und das vergleichen mit der Zeilen/Spaltennummer ab der das Bild/die Blanks/ Metadaten wie Audio anfängt etc.).
Deshalb würde ich von Display Pipes nicht erwarten, dass die sich groß oder überhaupt unterscheiden je nach max. Auflösung. Das ist nur ein einziger Zähler den dass beeinflusst. Das wichtigste dabei ist der Durchsatz, wie viele Pixel/sec die Pipeline verarbeiten kann. Und wie wir aus den Specs von Apple lesen können, ist da eher die Gesamtbandbreite aller Pipelines die alle gleichezeitig Daten aus dem Speicher brauchen limitierend (deshalb sehen wir so Dinge wie 2x 6K60 + 1x 4K60 oder alternativ 1x 6K60 + 1x 4K144. Das scheitert an der gesamten Datenmenge pro Sekunde die der Speichercontroller zuverlässig garantieren muss und eher nicht eine Limitierung der einzelnen Pipelines.
Hier könnte höchstens, wie wir am Beispiel Intel sehen können, mehrere Pipelines kombiniert werden, weil wir eh nicht alle Pipelines mit je ihrer maximalen Datenrate gleichzeitig betreiben können (wegen Limits auf die Summe aller). So sagt Intel zB dass sie 2 Pipelines kombinieren um 8K60 zu erreichen, was sie eh nur für 1 Display garantieren. Sie sagen leider nicht genau wie das im Detail umgesetzt wird. Ich würde hier darauf tippen, dass das hauptsächlich DSC betrifft und zB sowas macht, wie die Pixel-Zeilen werden abwechselnd von den 2 Pipelines geliefert, damit jede nur maximal den halben Durchsatz schaffen muss (und dementsprechend in Taktfrequenz oder Breite der Anbindung an den Speicher) nicht so breit sein muss.
Da wir, wenn wir Mac mini, Mac Studio und die Macbooks mit jeweils gleichem Prozessor vergleichen sehen können, das Apple alle Display Pipes auch für die externen Ausgänge nutzen kann (Mac Studio hat zB 1 TB Ausgang mehr als das Macbook mit M3 Max) gibt es keinen sinnvollen Grund warum das integrierte Display eine andere Implementierung haben sollte. Früher gab es da mit eDP noch Gründe, weil die Technik die in Adaptive Sync und DSC gemündet sind, dort angefangen haben um Leitungen und Strom zu sparen. Aber das können wir und auch Apple mittlerweile auf allen Anschlüssen. Ist also sowieso von jeder Display Pipe gefordert und kein Grund mehr warum man andere Hardware für das integrierte Display braucht.
Edit: und um die Software zu addressieren: die Software konfiguriert nur die Display Pipes. Danach arbeiten die autonom. Und die Software konfiguriert auch vorab wo die Outputstreams der Pipes hin geroutet werden (also zu welchem Port: eDP, HDMI, nativer DP output X für DP Alt mode, USB4-DP-In Adapter X). Und diese Verbindungen sind entweder in Hardware möglich oder eben ganz und gar nicht. Und das findet nach der Pipe statt und beeinflusst erstmal nicht, was die Pipeline selbst können muss. Außer evtl. sowas wie diese Pipeline kann ausschließlich zu diesem, langsamen Port gehen und deshalb muss sie nicht so schnell arbeiten können oder kann Features weglassen. Aber beim IC Floorplanning ist bald die größte Ersparnis in Entwicklungszeit, wenn du ein Modul designen kannst, dass du einfach gespiegelt, gedreht wiederverwenden kannst. Äußerst relevant für die GPU und CPU Cores zB. Dass du also anstatt das selbe Modul einfach 3 Mal zu verbauen eines 5% runter dummst, muss sich richtig auszahlen in Stromverbrauch oder Platzverbrauch, sonst lohnt das eher nicht und macht alles unnötig komplizierter.
Edit2: Wenn Apple natürlich ganz unkonventionell ist und die Display Engines viel mehr können als üblich, dann könnte das auch erklären, warum sie um Welten größer sein sollten als bei anderen Herstellern. Aber davon habe ich noch nichts gehört. Deshalb bleibe ich da eher konservativ und sage, solange die Anzahl der Einheiten noch nicht mal passt, ist das wahrscheinlich falsch und wird mit anderen Einheiten verwechselt.
