News Elsa nutzt Hydra-Chip – nur wozu?

[JackBlackstone]

meine gedanken:
also der chip auf dem board muss nicht viel leisten können, um dsa zu machen was da gefordert wird, wenn jede gpu nur ein teil des bildes bewerkstelligen soll, müssen die infos die ankommen nur aufgeteilt werden und wieder von dem chip zu einem bild zusammengefügt werden, das sollte nicht viel leistung fressen und die gpus wären dann so unabhängig voneinander, was erklären würde, dass nvidia karten auch mit amd karten gemischt werden können, da sie untereinander nicht komunitieren müssen sondern nur ein teil des bildes alleine berechnen müssen.
allerdings wäre doch so auf keinen fall gleich doppelte leistung zur verfügung, weil vieles doppelt berechnet werden müsste :/

 

[flappes]

Ich glaube viele verstehen nciht wo genau das Problem der Mikroruckler liegt.
Ist ja schön und gut mit Tesla, nur wenn zwei Grafikkarten mit unterschiedlichen Methoden Bilder oder Halbbilder berechnen, dann treten automatisch unsaubere Überschneidungen oder Mikroruckler auf. Wie bitte soll Tesla das verhindern?
Tesla könnte nur funktionieren, wenn die Grafikkarten exakte Berechnungen der 3D-Umgebung erstellen, ohne AA und ohne AS und am Ende übernimmt Tesla oder eine Grarfikkarte die Glättung usw. was ich aber für sehr unwahrscheinlich halte.

Naja, abwarten und Tee trinken. Wenn es eine einfache Lösung gäbe, dann hätte Ati oder nvidia die ja auch schon in Ihre High-End-Sli-Karten implementiert.

 

[ragnarok666]

You made my day
Selten habe ich so selbsicher vorgetragene Ahnungslosigkeit gelesen. Informir dich doch bitte erst mal was Tesla ist, kann nicht schaden...

Ansonsten rate ich euch die Links anzuschauen die Klamann in #17 gepostet hat, sehr interssant und informativ.Mir war nicht kalr (und dem CB-Autor offensichtlich auch nicht), dass schon so viel über Hydra bekannt ist.

 

[Timesless]

Klingt intressant und das Prinzip von "x Grafikkarten arbeiten am Bild" find ich sowieso besser.

Ich stell mir das ganze dann so vor dass eine 9800GT einer GTX 280 unter die Arme greift und somit man von ~20 FPS auf gut spielbare 30 FPS kommt.

 

[bensen]

Ja das hört sich alles so toll an, aber wie sie das wirklich machen steht auch in dem Artikel nicht.
Mit Split-Frame-Rendering haben bei Nvidia auch mehrere GPU an einem Bild gearbeitet. Kein µ-Ruckeln, war aber furchtbar ineffizient, den Grund findet man in alten SLI-Artikeln.
AFR, also das Bearbeiten eines Bildes von jeder GPU ist viel effizienter, hat aber eben besagte Nachteile.

Was genau machen die jetzt hier besser? Solange das keiner beantworten kann bzw. nen Test vorlegt sehe ich keinen Vorteil.

 

[nazfalas]

Schonmal gelesen wozu es genutzt werden soll? -.-
Es ist halt nicht zum Zocken gedacht immer diese sinnlosen Kommentare...
"Man kann mit dem Supercomputer nicht Crysis spielen Schei*e"

Das war jetzt nicht dein Ernst, oder?

 

[Kunibert_KA]

Ja das hört sich alles so toll an, aber wie sie das wirklich machen steht auch in dem Artikel nicht.
Mit Split-Frame-Rendering haben bei Nvidia auch mehrere GPU an einem Bild gearbeitet. Kein µ-Ruckeln, war aber furchtbar ineffizient, den Grund findet man in alten SLI-Artikeln.
AFR, also das Bearbeiten eines Bildes von jeder GPU ist viel effizienter, hat aber eben besagte Nachteile.

Was genau machen die jetzt hier besser? Solange das keiner beantworten kann bzw. nen Test vorlegt sehe ich keinen Vorteil.

Es geht hier wohl darum wie gesplittet wird.
Also nicht in feste Zeilen oder Blöcke aufgeteilt, sondern nach Objekten.

Einfachstes Beispiel:
Die dicke GPU rendert die Landschaft und der IGP übernimmt zb bei einem Shooter die Berechnung der Anzeigen, des Chars und der Waffe.
Andere Möglichkeit ist eben das eine GPU alles im Hintergund rendert und eine andere Objekte die weiter vorne sind.
Beispiel: eine GPU berechnet den Raum und eine andere den Tisch (+ dessen Schatten darin)

Wenn ich es richtig sehe dann versucht der Chip neben einem Loadbalancing eben an Hand der Tiefeninformationen und anderer Dinge das Bild in einzelne Objekte aufzuteilen. Dadurch das Objekte sowieso schon eine Kante zu anderen Objekten haben, fällt es dort weniger auf wenn 2 Bilder zusammengefügt werden als wenn ein Objekt geteilt wird.
Also eher die Richtung Collage(?).

 

[auRiuM]

genau das sieht man doch auf dem bild von post 17.

das Bild wird nach Vordergrund und Hintergrund aufgeteilt.

 

[HOT]

Ja das hört sich alles so toll an, aber wie sie das wirklich machen steht auch in dem Artikel nicht.
Mit Split-Frame-Rendering haben bei Nvidia auch mehrere GPU an einem Bild gearbeitet. Kein µ-Ruckeln, war aber furchtbar ineffizient, den Grund findet man in alten SLI-Artikeln.
AFR, also das Bearbeiten eines Bildes von jeder GPU ist viel effizienter, hat aber eben besagte Nachteile.

Was genau machen die jetzt hier besser? Solange das keiner beantworten kann bzw. nen Test vorlegt sehe ich keinen Vorteil.

Wenn ich das richtig interprätiere, ist das kein simples IMR-basiertes Software-SFR, wie es NV und ATI versucht haben, sondern eine Hardwarebasierte Lösung. Das Teil simuliert sozusagen eine eigene WDDM-Grafikkarte und die Emulationssoftware ermöglicht die Einbindung mehrerer Grafikchips des gleichen Herstellers. Die eingehenden Grafikdaten werden von der Software analysiert (das kostet etwas CPU-Leistung) und per Hardware werden dann aus dem Datenstrom einzelne Aufgaben errechnet (dies geschieht auf dem Chip) und diese direkt auf die einzelnen Grafikchips verteilt. Lucent spricht von einer Latenz, baut also quasi eine Phase zwischen CPU und GPU ein. Aber wie man schon bei anderen deferred Renderern gesehen hat (Kyro z.B.) macht das für die Grafik keinen Unterschied. Man sollte dank der Hardwarebasis eine deutlich besser SFR-Effizienz hinbekommen (natürlich nicht 100%) als dies per Software möglich war, das ist der ganze Trick bei der Sache. Man macht IMR-Chips zu einem grossen deferred Renderer. Die Technik ist eigentlich simpel wie genial, das ist im Prinzip ein Hardware-RAID für Grafikkarten. SFR ist sozusagen erwachsen geworden .

Einzige Fragen, die sich dabei auftun:

1.) Wie steht es um die CPU-Last der Emulationssoftware?
2.) lässt sich das CPU-Last-Problem mit mehr Threads pro CPU umschiffen?

Klar sein sollten zudem die Einschränkungen:

1.) Das maximale Featureset der Lösung ist das Featureset der "kleinsten" Graka
2.) Hersteller-eigene Lösungen wie CUDA werden problematisch, es sei denn, die Emulationssoftware kann das übersetzen. OpenCL sollte hingegen funzen. Alle Funktionen müssen im "Behavioral-Profile" enthalten sein.
3.) man ist von Lucent-Treibern abhängig. Wenn eine neue DX-Version kommt, muss Lucent entspechende Treiber liefern, um das nutzen zu können, obwohl die Grafikchips das evtl. schon vorher können. (Ohne entsprechende Behavioral-Profile keine Emulation)
4.) Dank Vista können nur Grafikchips des gleichen Herstellers verwendet werden, da Vista nur einen Grafiktreiber vorsieht.

 

[InkognitoGER]

Danke Hot,
so hab ich das im Prinzip auch immer verstanden. Du hast es aber in einen sehr vertändlichen Text gepackt.

Bin jedenfalls sehr gespannt was da kommt auch wenns bei mir nicht wirklich einen Nutzen hat. Aber der Technikteufel in mir kanns kaum erwarten.

 

[digitalangel18]

Schonmal gelesen wozu es genutzt werden soll? -.-
Es ist halt nicht zum Zocken gedacht immer diese sinnlosen Kommentare...
"Man kann mit dem Supercomputer nicht Crysis spielen Schei*e"

Das war jetzt nicht dein Ernst, oder?

you made my day