Der PLX Chip ist mit PCIe 2.0 x16 an die NB angebunden, beim AM3+ sind ja die PCIe Lanes noch nicht in der CPU.
Die Aussage war eine Veranschaulichung für DragonTear... Nicht mehr und nicht weniger.
Wenn man da Controllerkarten wie eine RAID Controller einbaut, dann hat man gleich gar keine Vorteil, denn die Grakas mögen bei stimmten Konfigurationen noch von der Fähigkeit des PLX profitieren auch eine Kommunikation nur zwischen den Karten zu ermöglichen, aber die Controller werden nie untereinander kommunizieren und selbst wenn man darüber die Daten liest die dann zur Graka gehen, wird das immer über die CPU gesteuert erfolge, einen Treiber der was anderes könnte, wäre mir nicht bekannt. Bei I/O Karten wäre also der PCIe 2.0 x16 dann immer der Flaschenhals wo alles durch muss.
Es geht um die Flexibilität... Hast du nur 16 PCIe 3.0 Lanes, wie bei Intel im Mainstream aktuell, musst du dich ansträngen, deine Hardware entsprechend anzubinden. Das ist bei Gamerkisten kein wirkliches Problem, machst du mehr damit, allerdings schon.
Das der Brückenchip keine Bandbreite dazuzaubert, ist logisch und jedem hier klar. Er bietet allerdings einen Flexibilitätsvorteil.
Nicht so wirklich, denn der Uplink ist ein Flaschenhals und damit hast Du nicht nur eine erhöhte Latenz (wenn auch nur 100ns), sondern auch eine geringere Gesamtbandbreite als die Summe der Bandbreiten der einzelnen Slots.
...
Aber alle müssten sich die Anbindung zur NB und damit zur CPU von PCIe 2.0 x16 teilen. Die beiden Grakas könnten noch untereinander kommunizieren, die müssten dann auch in je einem Slots der am PLX hängt betrieben werden, aber ein RAID Controller und eine SSD in Slots am PLX wurden das niemals tun, selbst wenn die Daten von einem zum anderen kopiert werden, die Treiber unterstützen es nicht, die SW puffert sowieso im RAM und nur auf dem Weg über die CPU kann der Virenfinder die Daten auch überhaupt prüfen.
Dein Argument baut einzig und allein darauf, dass du NUR Bandbreite untereinander benötigst... Die Realität sieht da eher anders aus. Da brauchst du die Bandbreite bspw. von der SSD, aber nicht vom Raidcontroller, dann mal vom Raidcontroller, aber nicht von der SSD. -> es wird häufig einfach nicht gleichzeitig die Bandbreite zugeschoben. Genau so wenig, wie wenn du dann noch mit der Kiste spielst, deine beiden HighEnd GPUs am Limit tuckern, du gleichzeitig noch Daten von der PCIe SSD zum Raidcontroller und zurück überträgst.
Wie gesagt, der Uplink wird nicht breiter -> das bestreiter aber auch niemand. Es geht um die Flexibilität, die man gewinnt.
PS: aber selbst wenn du das gleichzeitig wollen würdest -> PCIe ist FullDulex fähig, nur so nebenbei... Das heist, die Bandbreite ist pro Richtung gleichzeitig nutzbar -> das macht 8GB/sec beim PCIe 2.0 16x Uplink im Up- UND! im Download. -> Ein Copyjob von der fiktiven PCIe SSD mit 4x 3.0 Anbindung zu einem Raidcontroller (mit sagen wir SAS SSDs) würde im Zweifelsfall also eher an der Leseleistung der PCIe SSD als am Uplinkslot scheitern.
Ohne PLX Chip sähe eine mögliche Lösung allerdings so aus, dass die PCIe SSD bestenfalls an einem nativen PCIe Slot klemmen würde, der Raidcontroller ebenso -> je nach Laneanzahl vom Board -> 16 bei Intel und FM2(+) von AMD sowie 32 bei AM3+ würdest du da schnell ziemlich alt aussehen. Nämlich weil es nicht genügend Lanes gibt, um deine Geräte mit vollem Speed anzubinden. Um so neuer die Geräte, desto besser -> blöd wirds bspw., wenn dein Raidcontroller noch PCIe 1.x oder 2.0 8x nutzt... Dann BRAUCHST du die Lanes native -> ein Brückenchip würde dir diesen Zwang abnehmen.
Versuch gern mal ein System mit zwei GPUs + anständigem Raidcontroller + PCIe SSD aufzubauen. -> da bleibt atm nur x99 -> und selbst das ist schon schwierig, weil die Laneaufteilung ohne Brückenchip oftmals total für den Hintern ist... GPUs im Doppelpack direkt untereinander und sowas wird dort gern gemacht. Abschalten der anderen Slots bei Bestückung usw. usf.