Gerüchte rund um R700

Die Kollegen von Fudzilla berichteten vergangene Woche bereits mehrfach von Details zu AMD-ATIs R700-Chip. Dieser kommt wohl im 45nm Prozess und wird aller Voraussicht nach als Radeon HD 4000-Serie den Markt erobern. Ihre Leistung von knappen 2 Teraflops wird eine R700XT mit Hilfe von 4 und mehr Cores erreichen.

» Beitrag lesen

Hoffentlich passt das Konzept auch preislich, 3dfx hat es damals das Genick gebrochen.

Zitat von Hornet331

ihmo wird das konzept sehr fraglich werden, vorallem wenn das teil über cf angesprochen wird. Wenn cf nicht funzt -> singelcore performance....

ich hoff ja dass das nicht der fall sein wird. oder hab ichs überlesen? da stand nix von der verwendeten parallelisierungstechnik, oder?

Multicore ist die Zukunft in _jeder_ "computation heavy" Anwendung. War nur eine Frage der Zeit, bis auch GPUs diesen Weg gehen, wo sie doch eh schon massivst parallelisierte Recheneinheiten besitzen.

Ob so eine Multicore-GPU dann SLI/CF verwendet ist eigentlich vollkommen "wurscht", solange dass dann OHNE Mainboardsupport funktioniert. Aber ich denke diesen Schritt geht ja bereits die 3870X2, zumindest hab ich noch nirgendwo gelesen, dass die Karte nur auf CF Boards lauffähig sein soll.

Fraglich ist halt, wie schnell solche GPUs dann auch von den Entwicklern ausgenutzt werden. Ohne speziell entwickelte Engines spielt sich dabei nämlich fast gar nichts ab, siehe CF/SLI aktuell.

4 x R670 on a DIE = R700XT?

Also die vierfache Leistung einer HD 3850 halte ich für die Highend-Modelle der HD-4000 Serie für durchaus realistisch.

Zitat von mr.nice.

4 x R670 on a DIE = R700XT?

Also die vierfache Leistung einer HD 3850 halte ich für die Highend-Modelle der HD-4000 Serie für durchaus realistisch.

laut gerücheten hat die gpu ~300mio transistoren (also ~RV610/620 niveau ohne UVD etc.)

Zitat von Hornet331

Derzeit ist es alleinig eine frage des treibers der das verwaltet.

richtig.

Zitat von vanHell

Zur zeit können sie sowas auch garnicht ausnutzen weils keine API für den (kontrollierten) zugriff auf die 2te GPU gibt. Atm liegt es nur an den Treibern.

richtig.

Zitat von Hornet331

cf/sli support hat rein garnichts mit der engien der entsprechenden software zu tun.

falsch.

Das ist genau das gleiche, wie mit threaded Software im allgemeinen: Wenn du ein Programm schreibst, dass nur einen Thread hat, dann bringt deiner Anwendung für sich betrachtet eine Multi-Core (oder auch nur Multi-Threaded wie beim P4) genau _gar nichts_. Dem User, der mehr als eine Anwendung offen hat, bringt das natürlich sehr wohl etwas, weil die Ressourcen weniger knapp sind, aber deine Software wird nicht besser performen als auf einer Single-Core CPU.

Genau das gleiche gilt auch für Multithreading auf der Grafikarte, nur wer spielt schon 2 oder mehr Spiele gleichzeitig?

Jetzt widerspreche ich mir kurz noch selber, und sage, dass es bei der Grafik doch nicht gleich ist. Warum? Weil beim Rendering der Szene _relativ_ wenige Bildpunkte von einander abhängig sind. Es lässt sich also auch bei einer Single(graphics)threaded Engine ein Layer dazwischen schieben (SLI/CF) und Requests auf einzelne Cores umleiten, und so die Performance erhöhen. ABER es sind nunmal nicht alle Bildpunkte von einander unabhängig UND, ohne Zusammenarbeit der Spielentwickler mit den Treiberentwicklern lässt sich von außen noch weniger machen, weil schwer bzw. gar nicht erkennbar ist wie die einzelnen Abläufe und Abhängigkeiten in der Engine intern gehandhabt werden.

Genau das führt dann dazu, dass manche spiele mit aktiviertem SLI/CF sogar schlechter laufen, als ohne. Einfach weil sie nicht darauf ausgelegt sind, bzw. die Abarbeitungsreihenfolgen so "schlecht" gewählt sind, dass sich die Arbeit nicht günstig aufteilen lässt.

Die Lösung des ganzen? Engines müssen ihre Arbeit von vornherein auf mehrere "gThreads" aufteilen, und zwar am besten so, dass möglichst wenig Synchronisation notwendig ist.

Klarer Weise muss der Treiber dazu die notwendigen APIs für Mutlithreading auf der GPU zur Verfügung stellen, ja sogar noch mehr, der Treiber muss ähnliche Aufgaben übernehmen, wie das Betriebssystem es für Prozesse und Threads auf der CPU übernimmt: Scheduling, Synchronisationsmechanismen, Deadlock-prevention/-detection, etc.

Solang das der Treiber nicht kann, und zwar für 1 bis n Cores, können das klarerweise auch die Spieleentwickler in ihren Engines nicht ausnutzen, aber um MultiCore GPUs (egal ob wie jetzt über SLI/CF oder "on die") auch nur irgendwie sinnvoll nutzbar zu machen, führt imho kein Weg an solchen Treibern vorbei.

Aber wenn es soweit ist, dann _müssen_ die Engines davon auch Gebrauch machen, denn wenn die Renderarbeit weiterhin nur in einem gThread steckt, wird die Optimierung von außen (also nur durch den Treiber der versucht die Arbeit aufzuteilen) immer nur eine Krücke bleiben.

Zitat von NeseN

ich hab so ne vorahnung, das das in die hose gehen könnte -.-

gibts von amd schon irgendwas offizielles darüber?

Das hoffe ich doch nicht!
Seit AMD ATI gekauft hat, gehts ja bergauf.

In der kurzen Zeit Energiesparoptionen für Desktop Grafikkarten und die "offene" Hardware damit anständige Linux Treiber entwickelt werden können.

Wenn das dann wirklich mit jeder Anwendung funktioniert die Crossfire unterstützt sehe ich da nur Vorteile.