Nvidia Maxwell: Angebliche Spezifikationen zur GTX 870, + 18 % zur GTX 770 im 3DMark 11
Im chinesischen Forum von coolaler.com sind Screenshots aufgetaucht, welche mit einer Geforce GTX 870 erstellt worden sein sollen. Demnach soll die Grafikkarte 13 SMM mit insgesamt 1.664 Shadereinheiten sowie 4 GiByte GDDR5-Videospeicher besitzen. Der Grafik-Score im 3DMark 11 fällt um 18 Prozent höher aus als bei der GTX 770 - sofern der Screenshot echt ist.
Sowohl AMD als auch Nvidia bereiten aktuell ihre jeweils neue Grafikkartengeneration vor, welche bei Letzterem als GTX-800-Reihe daherkommen wird. Zum GM204 war bisher lediglich bekannt, dass der Speichercontroller mit einer Bandbreite von 256 Bit und die entsprechenden Modelle folglich mit 2 oder 4 GiByte Videospeicher daherkämen. Bei coolaler.com sind nun Screenshots aufgetaucht, welche mit einer GTX 870 erstellt worden sein sollen. In der Vergangenheit tauchten dort schon öfters Leaks auf, die sich als echt herausstellten – häufig aber auch schon Fälschungen. Das sollte man bei den folgenden Ausführungen berücksichtigen.
Demnach soll die Grafikkarte 1.664 Shadereinheiten besitzen. Geht man von 128 ALUs pro Maxwell-Streaming-Multiprozessor (SMM) aus, wie es beim GM107 (GTX 750 (Ti)) der Fall ist, besäße die GTX 870 13 SMMs. Der GPU-Takt soll bei 1.051/1.178 MHz (Basis/Boost) liegen, was sich ebenfalls mit den bisherigen Erfahrungen von Maxwell deckt. Der GM107 hat ein enormes Taktpotenzial, sodass viele Custom-Designs schon auf 1.300 MHz kommen. Der Videospeicher wird auf 4 GiByte bei 256 Bit beziffert und soll wie auch schon bei der GTX 770 mit 3.500 MHz arbeiten. Einzig das Verhältnis zwischen Textureinheiten und SMM scheint beim Screenshot nicht zu passen: Beim GM107 sind es je acht TMUs, was hier eine ungerade und daher unlogische Anzahl ergäbe. Jedoch muss hier bedacht werden, dass es sich aller Wahrscheinlichkeit nach um eine GM2xx-GPU handelt und daher größere Änderungen vorgenommen sein dürften.
Insgesamt soll die mutmaßliche Geforce GTX 870 einen Grafik-Score von 4.303 Punkten im 3DMark 11 erreicht haben, wohingegen die GTX 770 dort auf rund 3.600 bis 3.700 kommt. Folglich liegt der Unterschied bei rund 18 Prozent, was mit der Erhöhung der ALU-Anzahl und des GPU-Takts in Einklang zu bringen wäre. Allerdings sehen wir hier das Problem, dass nicht mehr allzu große Performance-Sprünge bei der GTX 880 zu erwarten wären, wenn beide tatsächlich auf dem GM204 basieren. Da die Ausbeute beim 28-nm-Prozess mittlerweile sehr fortgeschritten ist, sollte bei der GTX 870 nicht beispielhaft ein Drittel deaktiviert sein. Somit wäre es für die GTX 880 mit GM204 schwierig, auf ein ähnliches Niveau wie die GTX 780 (Ti) zu kommen.
Quelle: coolaler.com (maschinelle Übersetzung)
Also wie ich seit Tagen überlegt habe bzw Nachgedacht habe, es lohnt sich 0 wenn die neue 880 what ever.... 30% Leistung bringen würde... erst mit der 900 Serie würde es sich lohnen, das wäre aktuell nur rausgeschmissenes Geld :/
Oder halt eine 780 Kaufen wenn die wirklich billiger wird ^^ und dann halt Knüppel dann kommt man vielleicht auf das Niveau der 880 ? Falss die 880 die 780 ersetzen soll.
Nicht alle Berechnungen die durchgeführt werden (auch bei Games) sind hochgradig parallelisierbar und nur dann kann die GPU ihre Stärke ausspielen. Die Aufteilung von bestimmten Aufgaben für die CPU und GPU über Cuda ist einer der wichtigsten Argumente für diese Technologie.
sämtliche .Net Sprachen und auch Java werden alle zur Laufzeit Kompiliert, bzw. 'Just in Time', da muss auch für jede Architektur gearbeitet werden. normalerweise spielt das keine rolle, wenn du aber 60 mal die Sekunde irgendwas kompilieren musst, dann summiert sich das ganz schnell.
Cuda bzw. C#, C++ usw. (wobei Cuda nochmal etwas hardware näher ist) nutzen Compiler die den High Level Code spezifisch für eine bestimmte Architektur, in binäre Instruktionen übersetzen. Dies passiert einmal und nicht zur Laufzeit! Der daraus resultierende binäre Code kann dann von GPU/CPU ausgeführt werden. So optimiert man die Ausführung für eine bestimmte Architektur. Ein bereits kompilierter Code muss nicht zur Laufzeit erneut kompiliert werden, dies würde keinen Sinn ergeben. Ein binärer code kann natürlich von einem hardware scheduler optimiert werden (x86 typisch) oder auch vom Treiber einer GPU. Das hat aber nichts mit erneutem kompilieren zu tun. So wird dann z.B. die Ausführungsreihenfolge verändert oder bestimmte Instruktionen zusammengefasst da man sie in einem Taktzyklus berechnen kann.
Jedes programmierte Spiel hat Teile für die CPU und für die GPU. Bestimmte Module befassen sich mit z.B. Physik, Zustandsveränderungen wie Tag-/Nachtwechsel etc. Je nachdem welcher Teil davon gebraucht wird, werden entweder Teile für die GPU benutzt oder halt für CPU. Im Idealfall hat man beides, dann muss aber das Multithreading entsprechend gut optimiert sein.
Um Mischcode auszuführen gibt es für CUDA verschiedene Interpreter.
sämtliche .Net Sprachen und auch Java werden alle zur Laufzeit Kompiliert, bzw. 'Just in Time', da muss auch für jede Architektur gearbeitet werden. normalerweise spielt das keine rolle, wenn du aber 60 mal die Sekunde irgendwas kompilieren musst, dann summiert sich das ganz schnell.
Diesbezüglich kam bei Golem frisch ein Artikel.
Quelle:
Project Denver: Nvidias K1 mit 64 Bit optimiert ARM-Programme selbst - Golem.de
Kurz zusammengefasst steht darin, dass ich ein ARM-Prozessor aus "Projekt Denver" seine ARM-Programme (Apps) selbst optimiert. Dafür zwackt er sich 128 MB aus dem Hauptspeicher und legt dort die benötigten Programme ab. Anschließend übersetzt er sie sich selbstständig. Es folgt sortieren/organisieren und wieder ablegen, bis man die Sache erneut braucht. Man muss also nicht wie von dir angenommen immer wieder dasselbe kompilieren.
Ähnlich habe ich es kürzlich geschrieben. Nur hat Nvidia da noch eine Menge Finesse reingepackt.
Abhängig von der jeweiligen Architektur gibt es große Unterschiede im Instruction Set und bei der grundsätzlichen Art und Weise wie bestimmte Intsruktionen verarbeitet werden. Wenn man jetzt die High Level Language Ebene betrachtet, dann entwickelt man z.B. in C# oder C++ und fügt entsprechende tags in den Code, die dem Compiler sagen das bestimmte Instruktionen von der GPU berechnet werden sollen und andere von der CPU (das bietet z.B. Cuda). Die tags alleine reichen nicht aus damit Instruktionen effizient verarbeitet werden können. Bei GPUs muss man genau sagen welche Berechnungen auf welchem SM und mit wievielen Threads laufen sollen. Wobei dies aktuell wahlweise auch ein Compiler machen kann, mit vielleicht etwas schlechteren Ergebnissen als bei einer händischen Optimierung.
sämtliche .Net Sprachen und auch Java werden alle zur Laufzeit Kompiliert, bzw. 'Just in Time', da muss auch für jede Architektur gearbeitet werden. normalerweise spielt das keine rolle, wenn du aber 60 mal die Sekunde irgendwas kompilieren musst, dann summiert sich das ganz schnell.