AW: Mantle "entfesselt" Crossfire: AMD verabschiedet sich vom AFR-Modus - Mikroruckler adieu?
Bis auf deinen letzten Satz stimmt das soweit im großen und Ganzen. Von 200% Verbrauch usw kann man aber nicht ausgehen bei einer schlechten Skalierung.
Was du aber absolut richtig erkannt hast ist das PRoblem der Aufgabenstellungen, die Informationen über den Rest der Szene benötigen. Hier fällt Kommunikation an, wobei wirklich die Latenz das kritischere ist, und eher weniger die Bandbreite. Zumindest mit PCI-E 3.0 16x sollte sich das Problem in Grenzen halten.
Keine Ahnung, wie DX und OpenGL mit MultiGPU umgehen, aber ich gehe stark davon aus, dass die Datentransfers über die CPU laufen, und nicht direkt über die GPUs. Das bricht einem dann halt das Genick.
Zumindest bei früheren GPUs wäre dass dann etwa so abgelaufen:
GPU1/2 erstellt Daten -> GPU2/1 braucht Daten der jeweils anderen Karte -> GPU 1/2 schreiben Daten per DMA über PCI-E in einen Buffer im RAM der CPU -> auf der CPU wird ein Interrupt ausgelöst -> CPU löst einen Kernel-Trap aus -> CPU kopiert Daten nochmals innerhalb des CPU-RAMs (dieser Schritt kann eventuell ausfallen) -> CPU schreibt Daten per DMA über den PCI-E in den RAM der GPU -> GPU löst, wenn die Daten geschrieben sind, einen Interrupt auf der CPU aus -> CPU gibt den entsprechenden Prozess in die Queue der GPU -> GPU fängt an das PRoblem zu bearbeiten
Das ist halt SCHNARCH langsam....
Die heutigen GPUs sollten aber eigentlich RDMA mit zero-Copy machen können. Also nicht mal two-sided Communication, sondern one-sided Communication
GPU1/2 erstellen Buffer im RAM und tauschen Informationen über die Größen der Buffer und die Virtuellen/physikalischen Adressen zu den Buffern über die CPU aus. Das kann man alles zum Zeitpunkt des Programmstarts machen!
GPU1/2 erstellt Daten -> GPU1/2 schreiben per DMA über PCI-E die Daten in den vorher definierten Speicherbeireich der jeweils anderen GPU -> GPU 2/1 pollt entweder darauf, dass die Daten ausgetauscht wurden, oder wartet auf einen Interrupt über einen PCI-E Interrupt (MSI(-X)) -> GPU 2/1 verarbeitet entweder die Daten direkt, da in einer! der Queues schon der Auftrag von der CPU auf die Bearbeitung wartet, oder -> GPU löst Interrupt auf der CPU aus -> CPU schiebt Prozess in Queue -> GPU startet.
Man kann das mit dem was heutige GPUs alles an Hardware schon eh mit rum schleppen also deutlich beschleunigen. Man muss es eben "nur" implementieren und nutzen...
Ruyven, ich hatte mich ja im AMD-Review-Topic auch schon ausführlich geäußert. Das hier schlägt im Prinzip auch mit in diese Kerbe. Das lässt sich wunderbar kombinieren, bzw besser gesagt er ergänzt sich und ist ein logischer Schritt. Wenn ich mir so das anhöre, was jetzt über Mantle neu bekannt geworden ist, kann das schon sein, dass die da im Prinzip ziemlich genau das machen, was ich mir auch vorgestellt habe.
Die Graphics-Branche ist hier nur scheinbar etwas konservativer und langsamer, da man sich nicht auf einen gemeinsamen Nenner einigen kann. Ein bischen wie bei OpenCL. Gerade die AMD GPUs können eigentlich viel mehr als die Software-APIs zugänglich machen, weshalb man so manche alten Krücken nutzen muss um etwas zu erledigen, was heute eigentlich viel einfacher und eleganter lösbar wäre.
Was so ca möglich wäre, zeigt nVidia teilweise mit ihrer neuesten CUDA-Version. Das ist halt ein propritärer Standard, und Sie müssen auf niemanden Rücksicht nehmen. GPUDirect2.0 lebt ja z.B.unteranderem von Zerocopy.
Das ist schon ne feine Sache, aber an sich eigentlich nichts revolutionäres. Das ist eigentlich alles längst überfällig... Da wird sich in den nächsten 1-2 Jahren SEHR viel tun, auch von anderen Herstellern.
DA wird der eine oder andere noch die Hucke voll bekommen, weil die Konkurrenz nachzieht mit Features, oder diese sogar noch übertrifft. Aber lasst euch überraschen
). Aber entsprechend mies wäre auch die Skalierung einer derartigen Lösung:
