AW: Mantle "entfesselt" Crossfire: AMD verabschiedet sich vom AFR-Modus - Mikroruckler adieu?
Keiner kann dir sagen, wie hoch die Datenraten über die Brücke waren. Wenn das nur einige MB/S waren, dann kannste das auch knicken. So viele Kontakte waren es ja nicht, und es sah auch nicht nach differenziellen Leitungspaaren aus usw. Also viel würde ich da nicht erwarten.
Man soll nichts ausschließen. Aber ich halte es für unwahrscheinlich, dass man auch mit noch soviel Überlegungen etwas daran wird ändern können, dass auf GPU A berechnete Informationen sich nicht im VRAM von GPU B befinden und da auch nicht hinkönnen, solange es kein Interface zwischen den GPUs gibt, dess Bandbreite sich in Größenordnungen bewegt, die man sonst nur von Grafikspeicher kennt.
Also das kann gar nicht sein bzgl der Bandbreiten.
1. muss über das normale SI ja auch die Texturzugriffe erledigt werden
2. muss über das SI ja auch das ganze Z-Buffer usw usf Sach drüber laufen
3. brauchst du ja nicht alle Informationen, sondern nur einen Bruchteil davon. Die Frage ist halt wie groß der ist
Also mehr als 10% von der Bandbreite des SI würden mich überraschen. Und das passt halt relativ gut in nen PCI-E 3.0 16x Interface
Wieso nicht? Die schlechte Skalierung hat man ja nicht, weil die GPUs Däumchen drehen, sondern weil eine GPU Berechnungen durchführen muss, die die andere parallel auch berechnet. Das bedeutet doppelten Aufwand, in diesem Teil der Pipeline aber keinerlei Geschwindigkeitsgewinn gegenüber Single-GPU.
Richtig.
Du gehst aber davon aus, dass die GPUs eben die Sachen auch wirklich doppelt berechnen müssen. Das macht aber nur Sinn, wenn du durch eigene Berechnung auch wirklich schneller bist, als "einfach" auf die Daten per Transfer zu warten.
Früher/heute ist es klar notwendig gewesen, dass jeder seine Daten selbst berechnet, weil eben immer der Umweg über den CPU-RAM genommen werden musste, und auch die Interconnects langsamer waren.
Ganz abgesehen davon konnten die GPUs nicht mit virtuellen Adressen umgehen usw usw. Du hättest also auch große Probleme gehabt, überhaupt auf die Daten zu zu greifen. Sprich du hättest sehr wahrscheinlich immer die gesamten Buffer hin und her kopieren müssen, ganz gleich davon wieviel du wirklich brauchst.
Mit den Techniken, die man für bindless Textures usw usf alles eh schon in er GPU integriert hat, kannste auch einen globalen Adressraum aufspannen, und dann wirklich direkt die Daten dir holen, die du brauchst, und auch wirklich NUR die Daten die du brauchst. Da kannste unglaublich viel Bandbreite einsparen.
Die GPUs von heute kannste nicht mehr mit denen von vor 3-4 Jahren vergleichen. Da hat sich bzgl. der Hardwarefähigkeiten sehr sehr viel getan. Das Problem ist nur, die APIs sind nicht nachgekommen, warum auch immer...
Afaik machen DX und OpenGL da rein gar nichts. Die sprechen einen Multi-GPU-Verbund wie eine einzelne Grafikkarte an
Gut, das ist nämlich auch mein Stand.
- der Rest bleibt dem Treiber überlassen, der somit schon heute all die Möglichkeiten hat, die du als Potential für die Zukunft ansiehst.
Das Problem ist hier aber deine API, also das Programmiermodell, das hinter steht. Das bricht dir das Genick, weil du eben nicht die nötigen Informationen hast, um die Sachen um zu setzen. Es muss ja IMMER! funktionieren unter allen Konstellationen. So was treibt dich in den Wahnsinn, wenn du es nicht expliziet im Programmiermodell schon berücksichtigst. Man könnte also zwar theoretisch machen, aber die Aussichten auf Erfolg würde ich als sehr sehr sehr sehr sehr gering bezeichnen. Da ist es einfacher nen komplett neuen Standard durch zu drücken, als sowas rein über nen Treiber machen zu wollen.
Dual-GPU-Grakas sind afaik sogar in der Lage, die interne Kommunikation über den PCIe-Switch laufen zu lassen, ohne den PCIe-Controller in der CPU zu belasten.
Das hat nichts mit Dual-GPU-Grakas an sich zu tun, sondern liegt rein daran, dass da ne PCI-E Bridge auf der Karte drauf ist, und man Device-to-Device Communication über die Treiber forciert, bzw eben über PCI-E Packages und entsprechende Config der Bridge einen Multicast macht, also DAten an beide schreibt.
Das ist ne reine PCI-E Geschichte und ist bzgl der Software eigentlich komplett transparent. Also manche Sachen sogar für den GPU-Treiber. Es kommt da drauf an, wie die die Sachen mit den Adressen geregelt haben. Das ist eigentlich nur eine entsprechender Config der DMA Engine und dann kümmert sich der PCI-E Hardwarelayer darum, dass das nicht über den CPU-Controller läuft.
Das ist ganz lustig, wie PCI-E da teilweise mit scheinbarer "Magic" arbeitet
Ich hatte da in den letzten 1,5 Jahren so manche Situation, wo ich gedacht habe, der PCI-E Hardwarelayer würde mir Probleme machen, aber es lief dann einfach.
Man sollte echt nicht glauben, was die PCI-E Hardware so alles rein über den Transportlayer abwickelt!
Mehr kann ich dazu aber mal wieder leider nicht sagen
Ich persönlich glaube aber, dass du die Bandbreite unterschätzt. Für Beleuchtungsberechnungen braucht GPU 2 eben nicht nur ein paar Daten von GPU 1 (und das mit möglichst wenig Latenz), sondern GPU 2 braucht die komplette Levelgeometrie und sämtliche Lichtquellen, die GPU 1 schon berechnet hat, denn es gibt meines Wissens nach kein Format, mit dem GPU 1 "nur" das Lichtfeld als solches übergeben könnte, dass vom GPU1-Teil des Levels ausgeht.
Das ist soweit ich das überblicken kann richtig. Aber du musst auch schauen, was Mantle kann. Du hast nicht mehr die ganzen unterschiedlichen Buffertypen, sondern nur noch einen. Der Programmierer kann sich also sowas "einfach" basteln, wenn er will. Zumindest seh ich jetzt keinen Grund, warum das nicht gehen sollte.
Stattdessen müssen sämtliche Grundlagen des Beleuchtungsprozesses eingespeißt werden und dann von GPU2 z.T. noch einmal nachvollzogen werden, weil möglicherweise Verschattung aus Level-Teil1 sich nur in Teil2 auswirken. Und wenn jetzt noch Reflektionen hinzukommen, kann es sein, dass GPU2 anschließend ein vergleichbares Paket zurückschicken muss - das bei multiplen Reflektionen oder Streuung ggf. dazu führt, dass GPU1 noch einmal Teile der zuvor übergebenen Daten aktualisieren muss,...
Wie gesagt, Mantle scheint da viel mehr Freiheiten zu geben. Da lassen sich schon recht einfach viele Konzepte überlegen, wie man das verhindern/umgehen kann. Vieles davon läuft auf die gleichen Vorgehensweisen wie bei bindless Textures raus.
Man muss es halt "nur" implementieren und performant zum laufen bekommen, was eine heiden Arbeit ist. Wenns dann aber mal läuft steckst du natürlich die Konkurrenz, die so was nicht nutzt/hat in die Tasche.
Ein wichtiger Punkt sei hier nochmal angemerkt. Wie es scheint ermöglicht Mantle komplett asyncrones arbeiten. Das sieht DX und meines Wissens nach OpenGL an sich nicht vor. Hier nimmt man "einfach" die Fähigkeit von GCN (müsste eigentlich seit derHD5k Serie sogar sein), das man mehrere Queues hat, in die man Aufgaben reinsteckt und dann eben sogar outoforder abarbeiten kann.
Wie gesagt, die Hardware kann eigentlich VIEL mehr als die "normalen" Graphics-APIs aktuell vorsehen.
PS: Reflektionen und Spiegelungen sehe ich auch noch als eines der größeren Probleme an, wobei man sich da auch wieder Lösungen überlegen kann. Man kann der GPU mit den Daten der Spiegelung ja mitteilen, welche Geometrie der Bereich der Spiegelung hat usw. Dann kümmert die sich selbst darum, die Spiegelung/Reflextion mit den Daten zu verrechnen. Die Bilddaten für die Ausgabe muss man ja eh hin und her schieben.
Oder, komplett anderes Beispiel: Auf der GPU generierte Geometrie, z.B. Tesselation oder Displacement-Mapping auf Objekten, die sich durch beide Bildhälften ziehen. Ein Torbogen kann leicht das Level überspannen und besteht vielleicht nur aus einer Tesselationsanweisung und seinen Endpunkten - die nicht in den Aufgabenbereich der gleichen GPU fallen.
Ja, Objekte die über Grenzen hinweg gehen sind spannend, da Sie eben nicht soo einfach zu behandeln sind.
Hier spielt aber auch wieder die vermutliche asyncronität von Mantle rein. Das erleichtert halt die Lastverteilung.
Ich lass mich da gerne eines besseren belehren, aber ich glaube nicht, dass man die Interaktionen zwischen zwei Levelteilen so klein machen kann, dass PCIe damit locker fertig wird. Nicht ohne Grund redet z.B. auch niemand von mehr von Tile Based Rendering, obwohl gerade Iris Pro und die Xbox 1 massiv davon profitieren könnten.
Also meines Wissens nach ist Tile-Based-Rendering gerade wieder top aktuell. Man will ja z.B. unterschiedliche Bildteile mit unterschiedlichen Auflösungen rendern, um Performance raus zu holen. Stichwort Overlays usw.
Wenn es denn so ohne weiteres möglich wäre, eine Szene häppchenweise zu berechnen.
DX haben Overlayfunktionen gefehlt, die die Hardware eigentlich schon sehr sehr lange kann... Das wurde meistens aber nur in professioneller OpenGL Software verwendet, da man dafür eben auch die Profikarten gebraucht hat... Ich wollte mal bei nem OepnGL Projekt Overlay nutzen, weil ich die Funktion in den OpenGL Specs gefunden hatte und so nützlich fand. Leider musste ich herausfinden, das Consumerhardware die nicht unterstützt... AMD und nVidia wissen halt, wie Sie ihre teuren Profikarten absetzen...
Ansonsten kommen durch DX11.2 aber die Handwerkzeuge um genau das zu ermöglichen. Die APIs sind hier einfach viel viel viel zu langsam in ihrer Entwicklung...
Das sollte sogar ohne explizites CF möglich sein, denn da berechnen dann ja wirklich beide GPUs das komplette Bild. Mit ein bißchen Trixerei könnte man vermutlich sogar ein Auge von Nvidia und das andere von AMD versorgen lassen (Fanboys sähen dann natürlich nur noch 2D
). Aber entsprechend mies wäre auch die Skalierung einer derartigen Lösung:
De facto hat jede GPU die volle Arbeit, die ein Bild mit der hälfte der Gesamtauflösung erfordert. Also wo eine Single-GPU-Karte 1920x1080 berechnet, hat eine Hälfte eines Päärchens nur 970x1080 zu bearbeiten. Aber zwischen HD und FHD liegt eben nicht unbedingt ein großer FPS-Unterschied.
(Für die Rift ist es natürlich so oder so die einzige Option, AFR-Lag wäre intollerabel)
Ja, das sollte eigentlich ohne Probleme möglich sein
Nur müssen die Daten dann trotzdem zur jeweiligen GPU - liegen Daten die GPU B braucht (hardwaremäßig) im Speicher der GPU A, müssen diese um zur GPU B zu gelangen trotzdem über das Interface (PCIe) zur GPU B - PCIe ist aber deutlich langsamer als die direkte Verbindung GPU <--> VRAM - und genau da liegt der Haken dieser Theorie.
Ja es ist langsamer, du musst, wenn du es intelligent implementierst, aber auch nur einen winzigen Bruchteil an Daten transferieren.
