Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsNext-Gen-GPUs: Grafikkarten überspringen 20 nm für 14/16 nm
dann wird -je nach Performance- höchstens der Preis der TitanX ins Wanken geraten, wobei nVidia auch zuzutrauen ist, dass die wegen der 12GB VRAM stur bleiben und gar nix tun, sondern den höheren Preis trotz geringerer Rohleistung durch das Mehr an VRAM rechtfertigen werden.
Da kannst Du lange darauf warten, dass die Titan X billiger wird. Da braucht NVidia auch nichts zu rechtfertigen weil es einfach eine Titan ist und da bleibt der Preis so. Fertig aus.
Wozu sollte Nvidia auch für irgendwas die Preise senken?
Solange sich die Karten wie geschnitten Brot an den Mann oder Frau bringen lassen, gib ihnen.
Ist ja auch toll, dass AMD alle möglichen Features unterstützt. Dafür kann sich AMD letztlich nicht viel kaufen, sofern die Dinger entweder im Laden stehen bleiben oder noch nicht verfügbar sind. Am Ende zählen Umsatzzahlen.
Wie viel Speicherbandbreite letztendlich sinnvoll ist, ist doch eher von der Speicherbandbreitenlimitiertheit des Algorithmus abhängig. . . . bei manchen Algorithmen kann eine GPU mit HBM dank größerer Speicherbandbreite vorbeiziehen bei anderen wieder nicht. Und bei anderen Algorithmen, die durch die Speicherbandbreite limitiert sind, kommt wieder zu tragen, dass HBM sich afaik noch schlechter für random access eignet als GDDR5 und deshalb eine niedrigere Bandbreite liefert. Wie üblich ist alles etwas differenzierter zu betrachten . . . .
@ MikelMoto: Hab ich mir auch beim Schreiben gedacht. Aber ein Nebensatz an der Stelle war mir dann doch noch umständlicher
Und bei anderen Algorithmen, die durch die Speicherbandbreite limitiert sind, kommt wieder zu tragen, dass HBM sich afaik noch schlechter für random access eignet als GDDR5 und deshalb eine niedrigere Bandbreite liefert.
Das wäre mir neu. Hast du eine Quelle dazu?
Wieviel Random Access Anteil hat eine GPU als Troughput Computing Unit und hoch parallelisierte Recheneinheit?
Kann ich mir beides nicht vorstellen. Die R9 390 darf und wird nur minimal langsamer sein als die 390X, wie es auch bei der 290 der Fall ist. Da geht es um die letzten paar Prozent, was noch lange nicht heißt dass sich die schnellere Speicherbandbreite nicht lohnt.
Und 4GB wären genau so ein Todesstoß wo nVidia beim Topmodell 12GB raushaut. Es müssen 8GB sein.
Die Lieferzeit wird mit Sicherheit ein Problem, das hat man ja schon öfters gesehen. Immerhin wird der Referenzkühler der WCE wohl recht gut. Und für die Luftkühler könnte AMD einfach die der Vorgänger kompatibel machen, insofern HBM nicht so viel in der Kühltechnik verändert. Dann gäbe es schon gute Designs.
Das wäre mir neu. Hast du eine Quelle dazu?
Wieviel Random Access Anteil hat eine GPU als Troughput Computing Unit und hoch parallelisierte Recheneinheit?
Die Praxis wird es (bald) zeigen. Es kommt bestimmt nicht nur auf die Eigenschaften des Speichers an. AMD setzt hier ja nicht auf ein totes Pferd. Bestimmt gibt es weitere (neue) Hardware-Einheiten, die sowas ausgleichen (sofern das Problem überhaupt existiert).
Ich könnte mir gut vorstellen, dass das so ähnlich ist wie die ACEs bei AMD, die erst jetzt im Kontext der Asynchronous Shader ihre volle Aufmerksamkeit bekommen.
Für die 390 ist HBM so gut wie gesichert. Steht in jeder entsprechenden News, die du aufgrund der Stromsparfunktion deines Monitors wohl nur halbscharf lesen konntest.
Wenn die Titan X mit GDDR5 auskommt, sollte das für eine 390X doch auch machbar sein. Wenn das Gerücht stimmt, dass sich die 390X wegen Fertigungsproblemen mit HBM Speicher verzögert, dann hätte sich AMD wieder selbst ein Bein gestellt, wie leider so oft seit dem 290X Release.
Wenn die Titan X mit GDDR5 auskommt, sollte das für eine 390X doch auch machbar sein. Wenn das Gerücht stimmt, dass sich die 390X wegen Fertigungsproblemen mit HBM Speicher verzögert, dann hätte sich AMD wieder selbst ein Bein gestellt, wie leider so oft seit dem 290X Release.
Nein haben Sie sich nicht.
Denn GDDR 5 ist die Sackgasse. Und glaube mir, wenn NV bereits an HBM kommen würde, würden sie es nutzen.
Sie dürfen nur nicht.
Und warum ist da Nvidia nicht mit von der Partie? Haben Hynix/AMD Patente darauf oder existiert eine Art Zuerst-darf-AMD-es-verbauen-Vertrag zwischen Hynix und AMD?
Und warum ist da Nvidia nicht mit von der Partie? Haben Hynix/AMD Patente darauf oder existiert eine Art Zuerst-darf-AMD-es-verbauen-Vertrag zwischen Hynix und AMD?
Letzteres ist richtig. AMD hat (zwei - ich meine das mal gelsen zu haben - inzwischen finde ich aber nur noch Aussagen über eine Generation [gemessen am Lebenszyklus von Grafikkarten]) Jahre exklusiv den Zugriff.
Wobei hier natürlich Details nicht bekannt sind. Es könnte also sein, dass nicht CPU/GPU Produzenten bei Hynix theoretisch schon früher den Speicher kaufen könnten...
Aber NV als direkter Konkurrent wird wohl nicht dran kommen...
P.S.: Wäre ich AMD würde zwar NV in einem Jahr an HBM kommen aber nur an Gen 1. Für Gen 2 würde ich mit Hynix wieder die Exklusivität sichern... und so weiter...
Geplant ist ja ein Upscaling der Technologie bis ins Jahr 2020....
Noch eine Sache, ich hoffe, dass sie nicht zu off-topic ist. AMD hat bereits vor langer Zeit (mit GCN) die Vorbereitung in der Hardware für die Asynchronous Shaders gelegt mit den ACEs. Nvidia hat sowas erst seit Maxwell 2.0. Warum so spät bei Nvidia? Gibt es da irgendwelche Hintergrundinfos?
Nehme hier den Wert Access Granularity und spiele etwas mit den Interface-Größen herum. Berücksichtige für die Vergleiche eventuell noch, dass momentan NVIDIA-GPUs 32-Byte "Cache-Lines" besitzen (eigentlich 128-Byte Cache-Lines bestehend aus vier 32-Byte Blöcken), während bei AMD-GPUs die Cache-Lines 64-Byte groß sind.
Wieviel Random Access Anteil hat eine GPU als Troughput Computing Unit und hoch parallelisierte Recheneinheit?
Beispiele aus typischen GPU-Anwendungen:
Die Rasterpipeline verursacht je nach Shader und Ausgangsdaten mittelmäßig chaotische Zugriffe, obwohl sie gut cacheable sind, sofern sie in die kleinen Caches (afaik worst case 8 Byte cacheplatz pro GPU-Thread bei AMD) der GPU passen.
Raytracing verursacht extrem chaotische Speicherzugriffe und ist schlecht cacheable.
Physikalische Simulationen verursachen auch oft mittelmäßige bis sehr chaotische Speicherzugriffe.
Beispiele aus typischen GPU-Anwendungen:
Die Rasterpipeline verursacht je nach Shader und Ausgangsdaten mittelmäßig chaotische Zugriffe, obwohl sie gut cacheable sind, sofern sie in die kleinen Caches (afaik worst case 8 Byte cacheplatz pro GPU-Thread bei AMD) der GPU passen.
Raytracing verursacht extrem chaotische Speicherzugriffe und ist schlecht cacheable.
Physikalische Simulationen verursachen auch oft mittelmäßige bis sehr chaotische Speicherzugriffe.
Ja, das kann ich mir gut vorstellen. Die simple Rasterpipeline bleibt beim Rendering recht lokal für die Berechnung eines einzelnen Bildpunkts. Aufwändiger (komplexer) wird es schon bei Ambient Occlusion, da hier mehr Punkte aus der Umgebung beachtet werden. Raytracing ist natürlich eine ganz andere 'Nummer', da hier für jeden Bildpunkt im Viewport dieser zurückverfolgt wird durch die ganze Szene bis zur Lichtquelle bzw. den Lichtquellen. Damit sind dann viele Objekte / Lichtquellen einer Szene involviert, die in den vereinfachten Modellen nicht berücksichtigt werden.
Physikalische Simulationen sind ebenfalls komplex beim Zugriff auf den Speicher. Der Klassiker ist hier wahrscheinlich die N-body-Simulation, in der jeder Partikel mit jedem anderen wechselwirkt.
Da bin ich gespannt, wie man sowas in der Praxis kompensiert, damit HBM (nicht nur in der Theorie) schnell ist. Neue Algorithmen? Zusätzliche Hardware-Chips, die den Speicherzugriff entkoppeln?
Physikalische Simulationen sind ebenfalls komplex beim Zugriff auf den Speicher. Der Klassiker ist hier wahrscheinlich die N-body-Simulation, in der jeder Partikel mit jedem anderen wechselwirkt.
NBody liest in der parallelen Standardimplementierung (der mit n^2 Komplexität) nur sequentiell aus dem Speicher, sowohl bei der Kraftberechnung als auch bei den Stützstellen für die zeitliche Integration. Abgesehen davon, dass die Kraftberechnung ganz und gar nicht durch Speicherbandbreite limitiert ist und die speicherbandbbreitenlimitierte Zeitintegration nur einen Bruchteil der Gesamtzeit ausmacht, eignet sich das Problem zumindest vom Zugriffsmuster für HBM
Da bin ich gespannt, wie man sowas in der Praxis kompensiert, damit HBM (nicht nur in der Theorie) schnell ist. Neue Algorithmen? Zusätzliche Hardware-Chips, die den Speicherzugriff entkoppeln?
Nein haben Sie sich nicht.
Denn GDDR 5 ist die Sackgasse. Und glaube mir, wenn NV bereits an HBM kommen würde, würden sie es nutzen.
Sie dürfen nur nicht.
Quatsch. Auch nVidia würde es schon nutzen, wenn es jetzt sinnvoll wäre. HBM1 ist immer noch viel zu limitiert und ein Nischenprodukt - teure und limitierte Produktion und wenig Speicher.
Sie kommen nächstes Jahr mit HBM2. Und daran arbeiten sie mit Hynix schon seit Jahren.
Was für ein Wort! Da sieht man mal wieder was die Deutsche Sprache anrichten kann. 
http://wccftech.com/amd-20nm-r9-390x-feautres-20nm-hbm-9x-faster-than-gddr5/
