nVidia GT300 (40nm) DirectX 11 [Speku-, News- & Diskussionsthread] Part 2

Status
Für weitere Antworten geschlossen.
fdsonne schrieb:
Das ist so nicht ganz richtig...
Unified Shader sind erstmal frei programmierbar. Welche Software (in Form von übersetze Programmcode in Maschinensprache) dann da oben drauf läuft und mit welcher Programmiersprache man diese Produkte ansprechen kann spielt keine Rolle.

Oder vereinfacht gesagt, eine Hardware muss nicht auf eine Software zugeschnitten sein, sondern eine Software wird auf eine Hardware zugeschnitten.
In unserem Fall gibt es Hardware in Form von 1D ALUs auf NV GPUs, es gibt eine Entwicklungsumgebung die mit C++ umgehen kann und es gibt ein Zwischenglied, welches Programmcode in Maschienensprache umsetzt...
Den ALUs ist es schnurz egal ob du nun mit C++, VB, Java oder weis der Teufel was ankommst solange das besagte Zwischenglied die Sprache in eine Maschinenverständliche Sprache übersetzen kann. Und genau diese Möglichkeit hat NV geschaffen. Und bietet C++ Kompatibilität an.

Das ist aber leider nur die eine Kehrseite der Medalie. C++ verstehen heist lange nicht, jeglichen C++ Programmcode ausführen zu können.
Ich denke da zum Beispiel an Befehlserweiterungen ala SSE. Sowas kann die GPU nicht und dementsprechend wird derartige Software nicht auf der GPU laufen, zumindest nicht ohne massive Anpassungen.

Soviel zum Thema Optimierungen der NV Chips für C++ :fresse:
Zum Vergrößern anklicken....

Ich meine damit auch eher den Umbau der GPU, damit C schneller läuft. Das es auch so laufen würde stimmt wohl, aber wie schnell? Beim G200 hätte man halt die ganzen Mul Einheiten weglassen können und beim Fermi hätte man die CUDA-Cores nicht so umbauen müssen, dass sie so viel DP Leistung haben. Außerdem gibt es wohl auch einige Elemente, die man wirklich ändern musste, wenn es rein Softwaretechnisch ist, wäre der G200 ja auch C++ kompatibel. Dies ist aber nicht der Fall.



fdsonne schrieb:
Da hast du natürlich recht, im Falle von C++ muss der Entwickler der Software nicht erst auf irgend ne NV only Programmiersprache umsatteln um die GPU nutzen zu können. Aber es gibt wie grade schon gesagt auch Stolpersteine zu bewältigen.
Schlussendlich interessiert uns Gamer Endkunden die Workstationfähigkeit aber keinen Milimeter...

Die Frage ist eher, was bringt uns Endkunden das?
Schau dich auf dem Software Markt um... Im Privat-Endkundenbreich gibt es nur wenige Anwendungsgebiete, die extrem Leistung brauchen. Da zählen Games noch zu den größten.
Dann gibt es die Audio/Video Bearbeitungssparte. Aber hier sind schon wieder drastisch wengier Anwender die davon profitieren würden, weils einfach mal nich jeder macht und wenn dann nicht sooo oft, das man davon signifikannt Zeitersparniss hätte.
Und danach hört es schon wieder auf. Das bisschen Office geplänkel der meinsten User macht ne aktuelle Dualcore CPU spielend.
Zum Vergrößern anklicken....

Nunja man kann nie sagen was für Sachen da später draus resultieren, oder hat hier jemand die MP3 verhergesehen? ;)
Aber eigentlich finde Ich hier einen anderen Aspekt interessant. Bisher war der Gamingmarkt das Zugpferd für Highendgrafik und die schnelle Entwicklung hat sogar machmal Supercomputer überrollt. Nun deuten alle Vorzeichen daraufhin, dass GPGPU und Supercomputing in Zukunft das Zugpferd werden. Viele Kunden sind halt nicht mehr bereit für die Entwicklung mitzubezahlen. Das Nvidia nun Kombichips produziert könnte zur Folge haben, dass die Weiterentwicklung schneller voran geht. Davon hätte dann auch der Gamer etwas.

Der Konsolenmarkt hat die Entwicklung im GPU-Markt ja fast zum erliegen gebracht. Über 18 Monate warten wir schon auf eine neue Generation. Es gab mal Zeiten da kamen neue Generationen alle 6 bis 12 Monate.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Neurosphere schrieb:
Naja, man fängt ja nicht immer wieder bei Null an. Die allgemeine Taktrate steigt schon und das der Shadertakt über dem Niveau einer GT200b arbeitet muss nicht unrealistisch sein. Allerdings hat sich ja gezeigt das der wechsel auf 40nm dort nicht gerade viel geholfen hat.
Zum Vergrößern anklicken....

Im Taktratenvergleich zum G92 ist der G200 aber eher ein Rückschritt gewesen. Und wenn mans ich das ganze im Nachhinein betrachtet, für NV wären höhere Taktraten gerade im Vergleich zu AMD eigentlich sehr willkommen gewesen...

Und klar, mit neueren Herstellungsverfahren hat man die Möglichkeit am Takt etwas zu schrauben, aber dennoch um so komplexer die GPU, desto schwieriger werden höhere Taktraten...
 
fdsonne schrieb:
Und klar, mit neueren Herstellungsverfahren hat man die Möglichkeit am Takt etwas zu schrauben, aber dennoch um so komplexer die GPU, desto schwieriger werden höhere Taktraten...
Zum Vergrößern anklicken....

Deswegen kam bei mir vor einigen Seiten auch die Frage auf ob ich bei den einzelnen Cores nicht mit einer Pipeline arbeiten kann. Gut, ich hab das Problem der Sprungvorhersage, aber wer weiß ob sich das nicht lösen lässt.
 
Hentur schrieb:
Ich meine damit auch eher den Umbau der GPU, damit C schneller läuft. Das es auch so laufen würde stimmt wohl, aber wie schnell? Beim G200 hätte man halt die ganzen Mul Einheiten weglassen können und beim Fermi hätte man die CUDA-Cores nicht so umbauen müssen, dass sie so viel DP Leistung haben. Außerdem gibt es wohl auch einige Elemente, die man wirklich ändern musste, wenn es rein Softwaretechnisch ist, wäre der G200 ja auch C++ kompatibel. Dies ist aber nicht der Fall.
Zum Vergrößern anklicken....

Nein, man hat an der GPU gar nix umgebaut. Schon gar nicht auf C++ bezogen.

Zum MUL, das MUL kann laut CB beim G200 zu 93-94% für General Shading genutzt werden. Beim G80 waren es noch ca. 15%. Deswegen kümmert sich es sich um die Perspektivenkorrektur oder arbeitet als Attributinterpolator oder Special-Function-Unit (SFU)

Also einfach weglassen ist nicht wirklich, da beim G200 neben dem MADD auch das MUL stark gebraucht wurde...

Zum Thema gesteigerte DP Leistung. Auch hier hat das wieder überhaupt nix mit C++ zutun.
Klar hat NV die DP Leistung gesteigert, bzw. wird dies tun, aber nicht auf C++ bezogen, sondern weil im HPC Bereich idR DP Arbeit gemacht wird. Sprich wenn man sich dort mit seinem Produkt etablieren will, muss die DP Leistung stimmen...


Hentur schrieb:
Nunja man kann nie sagen was für Sachen da später draus resultieren, oder hat hier jemand die MP3 verhergesehen? ;)
Aber eigentlich finde Ich hier einen anderen Aspekt interessant. Bisher war der Gamingmarkt das Zugpferd für Highendgrafik und die schnelle Entwicklung hat sogar machmal Supercomputer überrollt. Nun deuten alle Vorzeichen daraufhin, dass GPGPU und Supercomputing in Zukunft das Zugpferd werden. Viele Kunden sind halt nicht mehr bereit für die Entwicklung mitzubezahlen. Das Nvidia nun Kombichips produziert könnte zur Folge haben, dass die Weiterentwicklung schneller voran geht. Davon hätte dann auch der Gamer etwas.
Zum Vergrößern anklicken....

Das Problem ist eher, wenn von Gaming als Zugpferd auf GPGPU bzw. HPC/Workstations umgesattelt wird, darf man nicht glauben, das der Gamingbereich mit der gleichen Intensität vorrangetrieben wird...
Und das sind meine Beführchtungen beim Fermi und dessen Nachfolgekarten...
Der Gamingbereich wird wohl wie Froggy so schön sagte das Abfallprodukt werden. Es wird denke ich nur die nötigsten Sachen erfahren um dort vorran zu kommen.

Aus Verkaufspreissicht wäre das auch nicht anders zu erwarten, denn die Verkaufspreise im Workstation/HPC Bereich sind weit höher als im heiß umkämpften Gamingbereich.

Neurosphere schrieb:
Deswegen kam bei mir vor einigen Seiten auch die Frage auf ob ich bei den einzelnen Cores nicht mit einer Pipeline arbeiten kann. Gut, ich hab das Problem der Sprungvorhersage, aber wer weiß ob sich das nicht lösen lässt.
Zum Vergrößern anklicken....

könnte extrem schwierig werden...
Da wir uns hier in einer völlig dynamischen Welt befinden werden.
So richtig vorstellen kann ich mir das weniger. Zumahl es dann wohl massiven Cache Zuwachs geben müste. Damit die ALUs auf Daten extrem schnell zurück greifen könnten.
Da reicht ja schon das bewegen des Bildes um nur einen einzigen Pixel. Schon müsste man die komplette Berechnung über den Haufen werfen und die Pipes mit den neuen Infos füttern.
 
bin java programmierer,denke aber nicht das c++ mehr als 10% verliert(gegen. hardware program.)?
 
DerGoldeneMesia schrieb:
bin java programmierer,denke aber nicht das c++ mehr als 10% verliert(gegen. hardware program.)?
Zum Vergrößern anklicken....

Wie soll C++ verlieren?
Es kommt doch schlussendlich auf die Fähigkeiten des Treibers bzw. des Compilers an, welche Programmiersprache am Ende die meiste Leistung bei der selben Berechnung bringt...

Oder vereinfacht gesagt, das was Hentur uns hier weis machen will, nämlich das NV den Chip auf C/C++ optimiert hat, stimmt so nicht. Zuerst kommt die Hardware, dann wird der Compiler geschaffen bzw. dazu gebracht, mit der Hardware umzugehen und schlussendlich wird der Programmierer dran gesetzt, der in einer gängigen Programmiersprache ala C/C++ Programmcode schreibt und dem Compiler vorsetzt... Dieser setzt das ganze in eine der Hardware verständlichen Sprache um und die Hardware führt das ganze aus.

Geschwindigkeitsoptimierungen gehen hier nur über den Programmcode selbst, den Compiler oder vllt noch über den Treiber für die Karte.

Ich denke mal Hentur ist der Annahme, das die Karte nativ C++ Code ausführen kann, was natürlich nicht stimmt. Zumahl C++ als Hochsprache sowieso in keinster Weise native auf Hardware ausgeführt werden kann...
 
fdsonne schrieb:
Wie soll C++ verlieren?
Es kommt doch schlussendlich auf die Fähigkeiten des Treibers bzw. des Compilers an, welche Programmiersprache am Ende die meiste Leistung bei der selben Berechnung bringt...

Oder vereinfacht gesagt, das was Hentur uns hier weis machen will, nämlich das NV den Chip auf C/C++ optimiert hat, stimmt so nicht. Zuerst kommt die Hardware, dann wird der Compiler geschaffen bzw. dazu gebracht, mit der Hardware umzugehen und schlussendlich wird der Programmierer dran gesetzt, der in einer gängigen Programmiersprache ala C/C++ Programmcode schreibt und dem Compiler vorsetzt... Dieser setzt das ganze in eine der Hardware verständlichen Sprache um und die Hardware führt das ganze aus.

Geschwindigkeitsoptimierungen gehen hier nur über den Programmcode selbst, den Compiler oder vllt noch über den Treiber für die Karte.

Ich denke mal Hentur ist der Annahme, das die Karte nativ C++ Code ausführen kann, was natürlich nicht stimmt. Zumahl C++ als Hochsprache sowieso in keinster Weise native auf Hardware ausgeführt werden kann...
Zum Vergrößern anklicken....

Der Anahme bin ich sicher nicht. Vieleicht hab ich mich ja nicht klar genug ausgedrückt und du hängst dich auch viel mehr an C++ auf, als ich das eigentlich wollte. Mit für C++ optimiert meine ich im Grunde alle Optimierungen für die nicht Gaming-Software, die über C++ angesprochen werden soll. Das das ganze nichts direkt mit C++ zu tun hat ist klar. Ich fand nur es ist der einfachste Weg das zusammenzufassen.
Auch wenn die MUL Einheiten von den Games mitgenutzt werden, so ist die Auslastung doch mehr als lausig und 90%+ dürfte wohl selbst NV intern wunschdenken sein. Vieleicht gibt es ja die eine Anwendung wo es so ist, aber im Durchschnitt sind die ziehmlich nutzlos für Gamingleistung.
Edit: Was wohl auch der Grund dafür ist, dass es sie beim Fermi nicht mehr gibt.
Meine ursprüngliche Aussage war ja nur, dass die GPUs von NV sicher noch effektiver wären (auf die Transistoren bezogen), wenn es reine Gaming Karten wären. Somit ist die Aussage Ati-Karten seien fortschrittlicher aufgrund höher Effektivität/Transistor nicht haltbar.
 
Zuletzt bearbeitet:
Hentur schrieb:
Der Anahme bin ich sicher nicht. Vieleicht hab ich mich ja nicht klar genug ausgedrückt und du hängst dich auch viel mehr an C++ auf, als ich das eigentlich wollte. Mit für C++ optimiert meine ich im Grunde alle Optimierungen für die nicht Gaming-Software, die über C++ angesprochen werden soll. Das das ganze nichts direkt mit C++ zu tun hat ist klar. Ich fand nur es ist der einfachste Weg das zusammenzufassen.
Zum Vergrößern anklicken....
Dann solltest du beim nächsten mal explizit dazu schreiben, was du auch wirklich meinst...
Denn die Aussage, der Chip sei auf C++ hin optimiert ist nun wirklich nicht richtig. Wenn du aber was anderes damit aussagen wolltest, wie du jetzt hier schriebst, dann kann das hingegen schon hinkommen... Denn NV hat zweifelsohne laut den Spekus dran gearbeitet, die DP Performance möglichst hoch anzusetzen. Was gerade Wissenschaftlichen Anwendungen im HPC/Workstation Bereich zu gute kommt. Sprich hat für diesen Bereich hin optimiert. Mit C++ hat das aber nach wie vor wenig zu tun ;)
Aber ich denke mal wir verstehen uns da jetzt und reden nicht mehr aneinander vorbei ;)

Hentur schrieb:
Auch wenn die MUL Einheiten von den Games mitgenutzt werden, so ist die Auslastung doch mehr als lausig und 90%+ dürfte wohl selbst NV intern wunschdenken sein. Vieleicht gibt es ja die eine Anwendung wo es so ist, aber im Durchschnitt sind die ziehmlich nutzlos für Gamingleistung.
Edit: Was wohl auch der Grund dafür ist, dass es sie beim Fermi nicht mehr gibt.
Meine ursprüngliche Aussage war ja nur, dass die GPUs von NV sicher noch effektiver wären (auf die Transistoren bezogen), wenn es reine Gaming Karten wären. Somit ist die Aussage Ati-Karten seien fortschrittlicher aufgrund höher Effektivität/Transistor nicht haltbar.
Zum Vergrößern anklicken....

Muss nicht sein. Wenn man davon spricht, das ein MUL Berechnung mit 93-94%iger Auslastung für generel Shading genutzt werden kann. Kommt das den Games sehr entgegen.
Und es ist ja nicht so, das die MUL Berechnungen beim G80 gänzlich brach geliegen haben. Wie schon gesagt, das ganze fungierte als Spezial Function Unit, änlich der Spezial Function Unit bei AMD für Sinus- Kosinus- und Logarithmische Berechnungen.
Wie viel davon schlussendlich gebraucht wird, hängt stark von der Anwendung ab und lässt sich von außen nicht beurteilen...

Ein Wegrationalisieren von MUL bedeutet im gleichen Atemzug aber auch, das Berechnungen die sonst darüber ausgeführt wurden dann auf anderem Weg berechnet werden müssen.
So ist es Fraglich was beim Fermi als SFU agieren wird... Aber schauen wir mal ;)
Eine dedizierte Einheit dafür kann ich mir nur schwer vorstellen.


Aber lassen wir uns mal von überraschen...
Kleine Zahlenspielerei...
Zwischen 8800Ultra und 280GTX liegen laut CB rund 49% bei 1600x1200 4xAA/16xAF...
Bei gut 60,7% mehr reiner Shaderleistung. (MADD only) Rechnen wir die Skalierung nun mal hoch von der 285er auf den Fermi würden bei von mir spekulierten 1400MHz Shadertakt und 512 ALUs grob 63,5% mehr Spieleleistung zur 285er GTX rauskommen.
Bei 1700MHz wären es 98,3% über einer 285er GTX.
Abzüglich den Rund 20% was eine HD5870 schneller als die 285er GTX ist, bleiben 43,5-78,3% für den Fermi ;)

Bin ich mit meinen grob 30% Fermi Top Single GPU größer RV870 Top Single GPU schon recht gut dran. Zumindest wenn die Skalierung stimmt.

Ein ähnliches Bild zeigt sich zwischen der 216er 260GTX und der 285er GTX.
Bei 32% reiner MADD Shaderpowererhöhung bleibt ein Skalierungsfaktor von ~0,84375, ergo 27% reale Mehrleistung.
Oben bei der 8800er zur 280er waren es ~0,80725.

Ich denke mal eine Ähnliche Skalierung zur reinen Shaderpower wäre beim Fermi auch realistisch.
Andererseits müssen die ALUs durch das wegfallen von MUL auch andere Aufgaben übernehmen, was vorher nicht der Fall war. Ebenso könnten die im Verhältnis nur Shaderpower geringeren ROPs/TMUs noch etwas problematisch werden.
 
Hallo,

ich hab mit den Werten aus der Tabelle noch ein paar Zahlenspielchen betrieben:
Bei der GTX 360 zeigt sich fast das gleiche Verhältnis aus Shadertakt zu Kerntakt (2,31) wie bei der GTX 285 (2,28).
Die GTX 380 fällt mit 2,62 deutlich aus dem Rahmen.
Bei 700 MHz (was auch schon mal zu lesen war) für den Kern und 1600 MHz für die Shader wäre man mit 2,29 wieder ziemlich genau bei dem bisherigen Verhältnis.
Dabei hab ich aber keine Rücksicht darauf genommen, ob nVidia letztendlich tatsächlich solche Taktraten mit den ersten Karten erreichen kann.;)

ciao Tom
 
@Neurosphere
bitte den Bilderquote noch entfernen...

Dampfkanes schrieb:
Hallo,

ich hab mit den Werten aus der Tabelle noch ein paar Zahlenspielchen betrieben:
Bei der GTX 360 zeigt sich fast das gleiche Verhältnis aus Shadertakt zu Kerntakt (2,31) wie bei der GTX 285 (2,28).
Die GTX 380 fällt mit 2,62 deutlich aus dem Rahmen.
Bei 700 MHz (was auch schon mal zu lesen war) für den Kern und 1600 MHz für die Shader wäre man mit 2,29 wieder ziemlich genau bei dem bisherigen Verhältnis.
Dabei hab ich aber keine Rücksicht darauf genommen, ob nVidia letztendlich tatsächlich solche Taktraten mit den ersten Karten erreichen kann.;)

ciao Tom
Zum Vergrößern anklicken....

Ich hab das mal fix für paar Karten der letzten Reihen gerechnet.
295er = 2,16
285er = 2,28
280er = 2,15
275er = 2,22
260er = 2,16
250er/9800GTX+ = 2,49
9600GT = 2,5
9500GT = 2,55
9800GTX = 2,48
8800GTS 512 = 2,50
8800GT = 2,52
8800Ultra = 2,47
8800GTX = 2,35
8800GTS 640 = 2,4


Die 9500GT ist hier also mit 2,55 der Spitzenreiter...

Aber wie gesagt, ich bezweifle selbst, das 1700MHz Shadertakt realistisch sind, eher so um die 1400MHz.

EDIT:
2,37 wäre der Mittelwert aus den Werten.
Wenn man die kleinen 8xx0er Karten noch mit rein nimmt, sinkt das noch bischen. Ich denke mal mit ~2,3-2,35 kommen wir durchaus hin.
Also 1495-1527,5MHz Shadertakt bei 650MHz Coretakt ;)
 
Zuletzt bearbeitet:
Motkachler schrieb:
Hier könnte man mit etwas glück am 7-10.1 was erfahren was tatsächlich erreicht werden kann.
http://www.cesweb.org/
Zum Vergrößern anklicken....

Wobei es laut den Gerüchten fraglich ist, ob NV überhaupt auf der CES vertreten ist bzw. Fermi Karten vorstellt.

Laut den Gerüchten wollen sie nämlich nichts Neues (im Zusammhang mit Fermi z.B. die GeForce GTX 300er Serie) präsentieren - eher frühstens Ende Januar (oder etwas später).
 
Neurosphere schrieb:
Deswegen kam bei mir vor einigen Seiten auch die Frage auf ob ich bei den einzelnen Cores nicht mit einer Pipeline arbeiten kann. Gut, ich hab das Problem der Sprungvorhersage, aber wer weiß ob sich das nicht lösen lässt.
Zum Vergrößern anklicken....

In der gesamten Architektur macht eine Pipeline aus mehreren Gründen keinen Sinn, der offensichtlichste ist noch, dass man damit den Datenfluss völlig überspezifiziert. Diese Serialisierung, die dadurch entsteht, ist nicht gewünscht. Man würde sich quasi die Pipeline, die man gebaut hat, völlig durch die Verdrahtung von Bypasses (das sieht am Ende wohl ein bisschen wie ein vollständiger Graph aus, weil von jeder Stage jede erreicht werden muss) ad absurdum führen.
Im größeren Bild sind ja die einzelnen Stufen (Rasterisieren, Texturieren [Fetchen, Perspektivkorrektur...], ...) schon (echt) parallel. Was du jetzt genau mit "Pipeline innerhalb der Cores" meinst, weiß ich nicht. Da ist außer der ALU nicht mehr viel relevantes und die ALU ist bestenfalls Teil einer Pipeline, nicht andersherum. :)

(Wollte durchaus schon eher auf deine PN antworten, aber hab meine letzten Wochen mit Prozesssynchronisation verbracht - POSIX-/pthreads-compliant, wers mag :) )
 
Woher stammen eigentlich die 1700MHz Shadertakt (übrigens: verwendet Nvidia nicht 27-MHz Kristalle, also müsste irgendetwas ungerades herauskommen - edit: hab's nachgerechnet, wären 1701 MHz, oder 63x27)? Das erste mal war in einem Artikel von Rys auf Techpowerup die Rede davon, und dieser hat selber gemeint, dies sei mehr ein Bauchgefühl von ihm, aber dass er zuversichtlich genug sei, dies zu publizieren, und dass Nvidia selber die Taktraten noch nicht kennt, und deshalb konservativ die bis zu 630 GFLOP/s publiziert (=> 1230MHz Shadertakt), um auf der sicheren Seite zu sein. Genau diese Form von Understatement ist man sich von Nvidia ja gewohnt!
 
Wieviel bringt eigentlich ein neues Stepping bei Grafikkarten? Ich kann mich erinnern, dass Taktraten bei Fermi A1 (wie zählt Nvidia eigentlich: Menschen beginnen bei 1, Maschinen bei 0) mit Wasserkühlung auf 495/1100Mhz zu bringen waren. Bei CPU bringt ein neues Stepping ja ca. 100-200MHz mehr Taktpotential, das sind bei aktuellen Taktraten ca. 5%. Kann Fermi dank eines respins um 50% höher auf 1700 MHz (shader-takt) gebracht werden?
 
Phantomias88 schrieb:
@ Chemiker494

Wieviel Takt haben den die Tesla C2050/70 ?
http://www.nvidia.de/content/PDF/Tesla_product_literature/NV_DS_Tesla_C2050_C2070_Final_lowres.pdf
(müssten ja die A2 sein?)

Wäre es nicht besser von den auszugehen?

MfG
Zum Vergrößern anklicken....

Ganz genau bisher war es immer so das aktuelle Highendgrafikkarten für Gamer mindestens so schnell wenn nicht sogar schneller waren als die Karten aus dem Profibereich(Quadro,Tesla);)
Siehe G200 oder G80

Das ist bei ATI auch so

Das ist schon darin zu begründen das den Profikarten absolut kein Fehler unterlaufen darf bei der Berechnung(sonst ist ein Projekt von mehreren Tagen Berechnung für die Katz),was für den Gamerbereich eine nicht ganz so hohe Priorität darstellt

Deshalb wurden Quadro u Tesla immer etwas gedrosselt(Speichertakt meistens) in den Specs im Gegensatz zur Highendgamerkarte.

Man kann eigentlich davon ausgehen das die Spezifikationen der Tesla in etwa der Gamerkarte entsprechen,siehe auch 6x8 Pin Stromanschluss
 
Zuletzt bearbeitet:
@Phantomias88: Aus deinem link:
IEEE 754 single & double precision: Achieve up to 600 Gigaflops of double precision performance for faster and more accurate results

Fermi soll 512 "Cuda-Cores" haben, die je ein Dual Precision FLOP pro Taktzyklus ausführen können.
=> 512 * 1'172 MHz = 600 GFLOP/s
Laut Nvidia soll Fermi eine DP Rechenleistung von bis zu 630 GFLOP/s aufweisen:
http://www.nvidia.com/object/io_1258360868914.html

Daraus ergibt sich nach obiger Formel eine Taktfrequenz der shader von (630/512) = 1,230 GHz
 
Noch mal ein kleiner Preisvergleich um bewusst zu machen was für eine Gewinnspanne zwischen Tesla u Geforce Karten liegen bei fast identischer Hardware

Die neuen Tesla-Karten möchte Nvidia ab Q2/2010 verkaufen. Dabei visiert man Preise von 2499 und 3999 US-Dollar an. Angemerkt sei noch, dass der Speicher der C2070 mit 6 statt 3 GiB das doppelte Volumen besitzt.
Zum Vergrößern anklicken....
http://www.hardware-infos.com/news.php?news=3304

Nun dürfte klar sein wo das "grosse" Geld verdient wird bei nvidia

---------- Beitrag hinzugefügt um 23:30 ---------- Vorheriger Beitrag war um 23:25 ----------
Chemiker494 schrieb:
Daraus ergibt sich nach obiger Formel eine Taktfrequenz der shader von (630/512) = 1,230 GHz
Zum Vergrößern anklicken....


Ist ja auch korrekt u wurde schon bestätigt für die Tesla Karten der ersten Revision

Keiner weiss aber was die nächsten beiden Steppings bringen
 
Zuletzt bearbeitet:
Taktraten von Fermi A1: 495MHz Chiptakt, 1100MHz Shadertakt. Mit Wasserkühlung. Zitat von "Hotboy" aus Chiphell (Achtung Babelfish-Übersetzung):
" Lao Huang takes the card it is said may run X10000 (the GPU score), in frequency not high situation (, because is really runs not high). .300 editions each time renew always a little are pleasantly surprised. At that time the frequency was 495/1100/1000.

Did not believe the words might turn occasionally before storm 5870 minutes…. Now the N card's most major problem is promotes the frequency to depend on the water cooling suppression…"

Ein neues Stepping bringt vielleicht 100MHz mehr Taktpotential, aber nicht 50% mehr.

10'000 Punkte 3DMark Xtreme als Taktziel: wirklich
15% mehr als Hemlock? (13'000 Xtreme Marks)
 
Zuletzt bearbeitet:
Chemiker494 schrieb:
@Phantomias88: Aus deinem link:
IEEE 754 single & double precision: Achieve up to 600 Gigaflops of double precision performance for faster and more accurate results

Fermi soll 512 "Cuda-Cores" haben, die je ein Dual Precision FLOP pro Taktzyklus ausführen können.
=> 512 * 1'172 MHz = 600 GFLOP/s
Laut Nvidia soll Fermi eine DP Rechenleistung von bis zu 630 GFLOP/s aufweisen:
http://www.nvidia.com/object/io_1258360868914.html

Daraus ergibt sich nach obiger Formel eine Taktfrequenz der shader von (630/512) = 1,230 GHz
Zum Vergrößern anklicken....

Danke!
Aber wird mit DP nicht mit 256 Cuda Core´s gearbeitet?

Just like we reported earlier, GT300 changed the way how the GPU is functioning. If we compare it to the old GT200 architecture, comparisons are breathtaking. Fermi architecture operates at 512 Fused Multiply-Add [FMA] operations per clock in single precision mode, or 256 FMA per clock if you're doing double precision.
Zum Vergrößern anklicken....

Quelle

:xmas:

Worst Case:
520GFLOPS / 256 CC = 1,962GHz ???
 
Zuletzt bearbeitet:
Status
Für weitere Antworten geschlossen.
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