[Sammelthread] Grafikkarten - Technikdiskussion

Jup, da hast du auch wieder recht,
besonders wenn viele kleine berrechnungen durchgeführt werden müssen.
aber genug jetzt davon.

Wie gesagt nur habe ich ein SI von 512 bit angezweifelt, da das dann doch recht viel ist.
Dass wären dann 300GB/s

Wieso können eig. Grakas nicht den x86 befehlssatz
ist das Hardwareseitig noch nicht möglich.
Oder blockiert da doch Intel?
Wäre cool ne "CPU" mit effektiven 2.3 TFLOP´s
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hmmmm eigentlich nicht, habe ich nur gestellt um euch moderatoren ein bisschen Arbeit um diese Uhrzeit zu verschaffen, da es ja so ruhig ist (IRONIE!!!!!!!)

Nein im ernst, eine Graka hat ja mehr Rechenleistung als ne CPU
Eine CPU ist aber mit wenigen sachen Schneller als mit vielen.

Könnte man das nicht Lösen?
Damit dann sozusagen eine Mainstream Graka, das OS und alles andere Macht.
 
Chezzard schrieb:
Hmmmm eigentlich nicht, habe ich nur gestellt um euch moderatoren ein bisschen Arbeit um diese Uhrzeit zu verschaffen, da es ja so ruhig ist (IRONIE!!!!!!!)

Nein im ernst, eine Graka hat ja mehr Rechenleistung als ne CPU
Eine CPU ist aber mit wenigen sachen Schneller als mit vielen.

Könnte man das nicht Lösen?
Damit dann sozusagen eine Mainstream Graka, das OS und alles andere Macht.
Zum Vergrößern anklicken....

Äh...das Flops allein nicht alles sind und CPUs etwas anders aufgebaut sind als GPUs ist dir aber bewusst?
 
PS: Absurd ist in der Computerwelt Gar nichts.

Damals wollte man Bill Gates keinen Kredit geben, weil Computer so gross und teuer sind, dass sie sich nie durchsetzen werden........Klar soweit?

Und "Damals" was hat BIll Gates gesagt, 748kb memory should be enough for anybody.....

---------- Beitrag hinzugefügt um 21:03 ---------- Vorheriger Beitrag war um 21:02 ----------

Jup aber ich kenne mich da Relativ wenig aus, deshalb dachte ich :Hey frag mal im Technik thread, die sind supernett und können dir sicher bei deiner Frage helfen.
 
Chezzard schrieb:
PS: Absurd ist in der Computerwelt Gar nichts.

Damals wollte man Bill Gates keinen Kredit geben, weil Computer so gross und teuer sind, dass sie sich nie durchsetzen werden........Klar soweit?

Und "Damals" was hat BIll Gates gesagt, 748kb memory should be enough for anybody.....

---------- Beitrag hinzugefügt um 21:03 ---------- Vorheriger Beitrag war um 21:02 ----------

Jup aber ich kenne mich da Relativ wenig aus, deshalb dachte ich :Hey frag mal im Technik thread, die sind supernett und können dir sicher bei deiner Frage helfen.
Zum Vergrößern anklicken....

Es ging mir nicht darum, dich bloßzustellen, ich wollte nur abchecken, wo eine eventuelle Erklärung ansetzen müsste. ;) Es IST absurd und das hat mehrere Gründe.
Zum einen "atmen" GPUs regelrecht Pipelining. Es gibt sehr wenige, sehr einfache Maschinenbefehle immer gleichen Typs. x86 ist das genaue Gegenteil davon. Variable Befehlslänge und teilweise sehr komplexe Befehle, typisch CISC eben, denn aus der Zeit stammt das noch. Zerlegen der x86-Befehle in Micro-Ops wie es Prozessoren machen, um dann ihren RISC-Kern darauf loszulassen, ist auf GPUs keine Option, denn dafür fehlt denen einfach der Platz.
Nicht nur das fehlt: Befehlssätze wie x86 bestehen zu großen Teilen aus Kontrollflussbefehlen, d.h. (bedingte) Sprünge und Conditionals. Mit sowas kommen GPUs nicht klar. Das dort zu implementieren, würde voraussetzen, dass man der GPU all das gibt, was CPUs in der Hinsicht auch haben (z.b. Branch Prediction Units, stallable Pipelining, große Caches).

Eine GPU ist ein ASIC, der eine ganz spezielle Nische füllt. Man kann einer GPU sicherlich rudimentär beibringen, Betriebssysteme laufen zu lassen, aber sicherlich nicht mit x86. Über das Thema kann man locker Stunden - eigentlich sogar Monate - referieren, aber genau deswegen ist es auch unglücklich, hier längere Erklärungen folgen zu lassen. Wenn dich das wirklich interessiert, kann ich dir gerne einige tolle Bücher empfehlen, auf denen fast überall Patterson oder Hennessy draufstehen. :fresse:

Gruß

Übrigens, laut Zitat waren es 640 kBytes.
 
Zuletzt bearbeitet:
Eine GPU ist nicht zu dämlich, nur ist sie einfach nicht in ihrer jetzigen Form in Hardware x86 fähig. Und um sie dazu zu machen wäre halt ein erheblicher Aufwand von nöten der die GPU ums x-Fache anwachsen lassen würde, bzw die einzelnen ALUs.

Edith sagt: Jup, verschrieben :)
 
Zuletzt bearbeitet:
Nochmal n Paar Fragen.

Wird wenn eine Graka auf Idle läuft, dann der Komplette Speicher einfach nur runtergetaktet, oder wird der Grossteil sogar abgeschaltet? (Wäre ja einsparpotential da oder?)

Und nochwas, Ich verstehe was der Buffer ist.
dann gibt es Doppelbuffer, dann wird das Aktuelle bild in Buffer 1 Gespeichert, buffer 2 bekommt das neue bild, dann wird buffer 1 in buffer 2 umbenannt und umgekehrt, und dass dan gesenden oder?

Der 3fach Puffer müsste ja auch so funktionieren.

Wieso gibt es dann MR bei MPGU.
Könnte man nicht die ausgabe um zb 40ns verzögern und so das bild dan gleichmässiger abgeben? also zb statt der Ausgabe: 10ns 40ns 12ns 60ns.
Einen kurzen Overcut erzeugen dass dan (auf Vorrat) gerendert wird (ich weiss ist nicht möglich, aber das ist jetzt ganz einfach gesagt: also dass das bild nicht sofort ausgegeben wird, um dann solche werdte zu erhalten) 40ns Wartezeit 10ns 20ns 17ns 30ns (In den 40ns würden wann die weiteren Bilder Berrechnet werden, zwischengespeichert, und dann gleichmässig abgegeben).

---------- Beitrag hinzugefügt um 22:30 ---------- Vorheriger Beitrag war um 22:19 ----------

Es ist 00:29
Bin ich mit dem Text oben wieder Diffus?
 
Hey Leute, ich hab ´ne ganz kurze Frage: Wisst ihr, ob ich mit der GeForce 9400 GT zwei Monitore parallel betreiben kann? Ich frage, weil es mit meiner 7600 GS nicht geht und ich kurz davor stehe, mir die 9600 + ´nen 2. Monitor zuzulegen, falls das funktioniert.
Wollte dafür keinen extra Thread aufmachen. Hoffe, könnt das spontan ohne viel Aufwand beantworten.
 
Deys, das ist der falsche Thread dafür. Schau mal in die Sammelthreads oder Treiberthreads vorbei, da kann dir bei sowas geholfen werden ohne das du nen neuen Thread öffnen musst.
 
Chezzard schrieb:
Hat wer infos zu meinem Post?
Zum Vergrößern anklicken....

Zu 1.: Der wird nicht abgeschaltet, nur runtergetaktet. Was mit der Spannung passiert weiß ich allerdings nicht, obwohl ohne eine Senkung nicht so viel beim Stromverbrauch passiert.

Zu 2.: Ich meine das Thema hatten wir schonmal im Crossfire und Sli Thread. Lies dir den mal durch, da solltest du genügend Antworten zum Thema finden. Ich kann dir aus dem Stehgreif nur sagen das es bei deiner Lösung wieder zu einem höheren Inputlag kommen würde.
 
Chezzard schrieb:
Wieso gibt es dann MR bei MPGU.
Könnte man nicht die ausgabe um zb 40ns verzögern und so das bild dan gleichmässiger abgeben? also zb statt der Ausgabe: 10ns 40ns 12ns 60ns.
Einen kurzen Overcut erzeugen dass dan (auf Vorrat) gerendert wird (ich weiss ist nicht möglich, aber das ist jetzt ganz einfach gesagt: also dass das bild nicht sofort ausgegeben wird, um dann solche werdte zu erhalten) 40ns Wartezeit 10ns 20ns 17ns 30ns (In den 40ns würden wann die weiteren Bilder Berrechnet werden, zwischengespeichert, und dann gleichmässig abgegeben).
Zum Vergrößern anklicken....

Klar wäre das recht Problemlos möglich. Aber es wäre unvorteilhaft, weil eben die Performance stark drunter leiden würde...

Wenn man bedenkt. Wenn wir mal von 60FPS ausgehen, wären das im Idealfall 33,33ms Frametime.
Schwankt diese sagen wir nun von ~25 zu ~40 zwischen den einzellnen Bildern haben wir MR. Dort wo das Frame nur ~25ms gebraucht hat kommt es schneller zum Schirm als wo es ~40ms gebraucht hat.
Bei gleichmäßiger Verteilung der Frametimes auf ~40ms würden aber nur 25FPS rauskommen.
Baust du also eine "Bremse" ein, welche dir die schnellere GPU ausbremst und die Bilder syncronisiert mit der anderen Karte ausgibt, wären bei dem Vorhaben von vormals angezeigten 30FPS nur noch 25FPS zu sehen.
Klar wird das Bild etwas runder, aber mit 25FPS ist eben kein Sieg mehr zu gewinnen.

Das Thema MR ist aber viel zu hochgehypt, der Überwiegende Teil der CF/SLI nutzer merkt davon überhaupt nix. Die die es stört, können ja um Dual/Multi GPU Lösungen einen Bogen machen.

Der nächste Punkt ist, um ein CF/SLI Gespann aktueller HighEnd Karten in MR relevante Regionen runterzudrücken (sprich um die 30FPS) brauch es schon extrem hohe Bildverbesserungssettings. Sprich diese Settings mit dehnen man da bencht, würde man auf ner Single GPU Lösung lange nicht fahren können, weil die FPS dann wohl weit unter 20FPS liegen würden.

Bleibt unterm Strich wieder ein Vergleich, der nicht vergleichbar ist... Apfel mit Birnen sozusagen. Vergleicht man hingegen gleiche Settings, und stellt diese so ein, das eine Single GPU im Spielbarkeitsbereich ist, wird man mit dem SLI/CF weit drüber liegen. Und da haben MR wiederum wenig Relevanz.
 
Hmm da hast du recht.

Und wenn man jetzt (rein theoretisch) ich meine ich kenn mich nicht so gut aus wass alle seine Grafikkarte macht.
Aber wenn mann jetzt im CF die Eine Karte nur bestimmte sachen berrechnen lässt (zb. das Bild und die Pixelwerte) und die Zweite kümmert sich dann um zb. AA/AF und noch ein bisschen kleinzeugs.

Wäre das eien Möglickeit?
 
Macht wenig Sinn, weil beide Karten auf den selben Speicherinhalt zugreifen müssen, und wenn du AA über ein Bild drüber jagst, dann brauchst du die zuvor berechneten Daten... Sprich rechnet eine Karte nur das AA und die andere beispielsweise das Bild müsstest du umständlich zwischen beiden Karten diesen Datenbestand austauschen. Der Interconnect zwischen den Karten ist aber im Vergleich zur Speicherbandbreite zwischen GPU und Speicher extrem lahm...

Der wohl einzige richtige Ansatz MR wegzubekommen ist die Möglichkeit anstatt AFR SFR als Rendermodus zu nutzen. Bei SFR rechnen alle GPUs nur einen Teil des Bildes...
Nachteil, das lässt sich sehr schwer auslasten und auch recht schwer realisieren... Die Lastverteilung zwischen den GPUs ist ebenso ein heikles Thema...
Meist wird AFR benutzt, wo die GPUs eben Bilder im Vorraus berechnen.

Im SFR Modus erschlägst nicht nur MR, sondern auch das Input Lag. Vor allem bei mehr wie zwei GPUs das wohl viel größere Problem...
 
Oh ja kenne ich hatte ja 3x die 5870 damals. also da habe ich die MR schon gemerkt.

Im CF mit 2 Karten war ich erst ab ca 27 (Je nach game/engine) im MR bereich.

---------- Beitrag hinzugefügt um 11:25 ---------- Vorheriger Beitrag war um 11:25 ----------

danke für die Infos, sehr Hilfreich.
 
Das nächste Problem bei deiner Idee, Chezzard besteht eben darin, dass die 40ns als Verzögerung der Bildausgabe einer Grafikkarte eben nicht immer ausreichen. Im Idealfall sind diese Verzögerungen gleichmäßig verteilt. Aber stell dir mal folgendes Szenario vor: Karte A berechnet ein Bild. Währenddessen werkelt Karte B ganz fleißig am nächsten Bild. Dieses Bild erfordert aber wesentlich mehr Rechenschritte, so dass es erst etwas später ausgegeben wird als geplant. Das folgende Bild sieht vom Rechenaufwand wieder etwas anders aus. Dort muss weniger gerechnet werden. Was geschieht? Die Abstände zwischen den einzelnen Bildern von Karte A und B variieren.

Ein Lösungsansatz wäre die GPUs mittig anzuordnen und drum herum einen Ring Bus zu konstruieren, so dass beide GPUs mittels Controller erst beide Bilder ausgeben wenn diese auch zu Ende berechnet sind. Wie Paul schon anmerkte, frisst das aber Unmengen an Leistung.
 
PCZeus schrieb:
Ein Lösungsansatz wäre die GPUs mittig anzuordnen und drum herum einen Ring Bus zu konstruieren, so dass beide GPUs mittels Controller erst beide Bilder ausgeben wenn diese auch zu Ende berechnet sind. Wie Paul schon anmerkte, frisst das aber Unmengen an Leistung.
Zum Vergrößern anklicken....

Na zu Ende berechnet sind die Bilder ja jetzt auch schon... Das Problem ist halt die ungleichmäßige Ausgabezeit, hält man diese syncron, so ergeben sich erhebliche Leistungseinbußen. Weil die Karten eben teils nix tun können außer warten.

Der wohl sinnvolleste Ansatz ohne groß Leistungsverlust wäre SFR. Mit dem Nachteil, das extrem viel optimierungsaufwand bestehen dürfte. Es sei denn man kann das ganze soweit intelligent aufbohren, das es sich quasi selbst anlernt und an die Gegebenheiten anpasst. Dynamische Lastverteilung usw.
Das Problem mit dem mehrfachen Datenvorenthalten im Speicher ist aber bei SFR auch gegeben.
 
Nur musst du eben diese Optimierung bzw. Steuerung der Bildausgabe auch irgendwie koordinieren. Daher mein Ansatz mit dem Ring um die GPUs damit alle den kürzesten Weg zum Speicher haben und die Bilder nach einander zu einem Controllerchip ausgeben.

So könnten 2 GPUs auf einen gemeinsamen Speicher zurück greifen, nur muss das erstmal auch so laufen...
 
Das mit dem shares RAM kannst quasi vergessen, der Ansatz ist gut, aber die Durchführung wird schwierig, einen interconnect zu bauen, der derartige RAM Bandbreiten bereit stellt, wie die GPUs sie brauchen ist in meinen Augen derzeit nicht drin...

Man könnte so eine Art bauen, wie es aktuell bei Multi CPU Systemen der Fall ist, sprich jede CPU hat ihren Speicher, aber es gibt die Möglichkeit über den Bus auf den Speicher der zeiten GPU zuzugreifen.
Aber ob es das bringt?
Würde auch meinen, das wäre zu lahm...
Man müsste da mal erörtern, welche Daten Bandbreiten abhängig sind und welche eher nicht. Ich könnte mir vorstellen, einen dedizierten Texturecache muss man nicht zwingend mit 150GB/sec+ an die GPU anbinden...
 
Neja, das mit dem Interconnet wäre jetzt nicht das Problem an sich. Wie du schon erwähntest, geht das auch mit Multicore Systemen ohne Probleme. Die Daten könnte man schon zur anderen GPU schaufeln ohne das das IC zum Flaschenhals wird. Das eigentliche Problem das ich darin sehe ist die momentane Architektur der GPUs. Wie will man auf den Speicher der anderen GPU zugreifen? Dazu bräuchten die GPUs Logikeinheiten ähnlich die der CPUs (in puncto Memory Controller, Cache, Misses usw.)
 
Hä? Wieso soll sich durch Vorhaltung die Framerate vermindern? Du kriegst nur ein nichtkonstantes Lag mit rein. Das wird das Problem sein - du weißt ja nicht, wie alt der Frame ist, den du grade siehst. Entsprechend durch Verziehen der Maus zu reagieren wird da schwierig...
 
Wenn die Karte Bild A berechnet und wartet, bis die zweite GPU mit Bild B fertig ist, vergeht Zeit. Das resultiert eben in weniger FPS, da in der Zwischenzeit wo gewartet wurde eigentlich schon ein neues Bild angezeigt wurden wäre (allerdings in unregelmäßigem Abstand) ;)
 
Reden wir von Warten und Däumchendrehen oder von Zwischenspeichern und währenddessen nächstes Bild rendern?
 
In der Zwischenzeit das nächste Bild berechnen würde bedeuten, dass sich der Inputlag und die evtl. FPS-Einbrüche noch stärker bemerkbar machen. Das macht also nur begrenzt Sinn. Man weiß ja nicht, ob das x.te Bild nun verworfen werden muss oder nicht.

Wobei hier von Bild zu reden etwas irreführend ist. Ich meinte damit eher kleine Abschnitte von einem Bild. So verringert man die Zeit, die nun gewartet werden muss.
 
Wow hier geht es ja zur sache.

Danke dass ihr mir das so Fachkompetent erklärt habt, ist doch nicht so einfach das Zeug wie sich das so manch einer Denkt.

Aber andere Frage wenn man eine CF karte hat wie die HD 5970.
wieso gibt man dann jeder gpu 1gb ram und nicht beiden Zusammen 2 gb ram.
Das beide den Gleichen Speicher haben.

Hat sicher auch seine Gründe, aber welche?
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh