Bestätigt: AMD arbeitet an "Radeon R9 380X" mit Richtung 300 Watt TDP und HBM-Speicher

Wenn ich das aus den bisherigen News richtig verstanden habe könnte Vulkan mit beiden umgehen, sofern es entsprechend erweitert wird.
So gesehen könnte man es auch einfach als eine überarbeitete, flexible bzw. erweiterte Version davon bezeichnen, was schon aufgrund der Nutzung unterschiedlichster GPU Architekturen nötig gewesen wäre.
Und wo wurde von einer 1:1 Kopie geredet oder saugst du dir das nur aus den Fingern um deiner Aussage Nachdruck zu verleihen?

Zum Thema CUDA....sag das im Spiele Bereich lieber nvidia und ihrer GPU Physx Politik. Im professionellen Segment hat diese Schnittstelle schon eher ihre Berechtigung um das Maximum an Leistung aus den Karten zu quetschen.
 
SPIR-V bildet eine gemeinsame Basis für OpenCL 2.1 und Vulkan Shader. AMD ist auf der OpenCL-Seite ja recht gut aufgestellt, daher würde ich mir da keine Sorgen um Vulkan machen. Die müssen für beides im Endeffekt nur den gleichen Bytecode auf die Grafikkarten-Funktionen umsetzen. Außerdem ist SPIR-V technisch näher an HLSL als GLSL.

Edit: Ja, es sollte auch gut möglich sein, dass es ein HLSL-Frontend für SPIR-V geben wird.
 
Und wo wurde von einer 1:1 Kopie geredet oder saugst du dir das nur aus den Fingern um deiner Aussage Nachdruck zu verleihen?
Ich wehre mich nur gegen die Aussage, dass Vulkan ein Mantle Klon wäre und AMD dadurch leichtes Spiel bei der Umsetzung hat. Dergleichen konnte man immer wieder lesen. Vielleicht nicht in diesem Thread, aber in den Kommentaren bei Anandtech und anderswo. AMD wird bei der Umsetzung von Vulkan noch viele ausstehende Punkte auf der Aufgabenliste zu stemmen haben. Es gibt schließlich bedeutsame Unterschiede zwischen den beiden APIs, die gar nicht so gering ausfallen. So mag AMD zur Zeit einen (kleinen) Vorsprung vor der Konkurrenz haben, aber sie müssen auf der Hut sein diesen zu behalten. Die Entwicklungsabteilungen von nVidia und Intel werden nicht untätig sein. AMD hat seine Schäfchen jedenfalls noch lange nicht im Trockenen, obwohl man mit Mantle schon einige Erfahrungen in Hinblick auf Low Level APIs sammeln konnte. Allerdings bin ich zuversichtlich, dass das Catalyst Team letztendlich bei Direct3D12 und Vulkan eine gute Arbeit abliefern wird. Geschenkt bekommt AMD hingegen nichts. Sie müssen sich dies erarbeiten. Die mit Mantle geleistete Vorarbeit wird sich auszahlen, aber nicht dergestalt, dass man über Nacht durch den Austausch einiger Strings einen Vulkantreiber präsentieren kann.
 
@SPINA
Dann lasse solche Aussagen doch bitte da wo sie gemacht werden.
Des weiteren ist der Ansprechpartner für Vulkan nicht AMD sondern die Khronos Group bei der AMD nur einer von vielen Mitgliedern ist.
Ich für meinen Teil sehe Vulkan auch eher als eine Auskoppelung aus OpenGL die primär für die Spieleindustrie gut ist, was auch erklären würde warum man parallel an OpenGL weiter entwickelt. Dann kämen sich auch nicht mehr die Anforderungen der professionellen Programme und die der Spieleindustrie nicht mehr in die Quere, der bisher größte Entwicklungsvorteil von Direct3D.
 
@sompe: Bei DirectX pflegt man die High Level API ebenfalls weiter. Es soll ein konservatives Direct3D11.3 neben dem gehypten Direct3D12 geben.

So muss ein Spieleentwickler nicht in die Untiefen der Low Level API absteigen, sondern kann bei den gewohnten DirectX und OpenGL Tools bleiben.
Schließlich erfordert nicht jedes Projekt, dass man das letzte Quentchen an Performance herauskitzelt; in dem Fall kann man sich den Aufwand sparen.
 
Viele Spieleentwickler nutzen doch eh zugekaufte Engines. Dazu brauchen sie D3D12/Vulkan nicht groß zu kennen, die sind da bereits implementiert.

AMD engagiert sich jetzt auch in Richtung VR: AMD Gets Into VR With LiquidVR Technology
 
Außerdem hat sich AMD in der Verganheit immer schwer mit der GLSL getan. Sicher ein Grund wieso man bei Mantle auf das von Direct3D übernommene HLSL gesetzt hat. Vulkan bricht an dieser Stelle mit Mantle und setzt statt dessen auf SPIR-V. Es muss sich erst noch erweisen, dass AMD hiermit zurecht kommt. Vulkan ist zwar von Mantle inspiriert, aber nun einmal keine 1:1 Kopie. Das scheint mir allzu gern verdrängt zu werden dieser Tage.
Von mir aus könnte man CUDA auslaufen lassen. Es hat seinen Zweck bereits vor Jahren erfüllt gehabt.

SPIR-V ist nicht der Ersatz für HLSL sieht man anden Diagrammen, zudem kann wer will auch die GLSL gegen was anderes tauschen. Khronos behält sich offen auch die hlsl verwendung zu standardisieren.
Da bleibt dann das es mehr funktionen gibt bei Vulkan laut dllauszug der amd Treiber von letzten Januar und Progrcode nicht direkt für die hw geschrieben wird sondern wie bei hsa in einer il in binärform generiert wird.

--- Update ---

SPIR-V ersetzt llvm ir, welche amd wenn ich mich richtig erinnere auch beim proprietären Treiber nutzt um dann Hw Programmcode zu generieren. Zumindes habe ich den amd HSA Teamleiter der vorher die Radeonentwicklung geleitet hat so verstanden.
 
Exakt ONH. Das wird so etwa wie HSA für GPUs mit der Einführung der IL und dem Low-API Ansatz. Da wird es immer einfacher die zugrunde liegende ISA auszutauschen oder mit schlanken Treibern spezifische Hardware anzusprechen.
 
Bei heise mehr davon. Ein offener 3D-VR-Standard:
http://www.heise.de/newsticker/meldung/LiquidVR-Neues-Virtual-Reality-SDK-von-AMD-2566652.html
besonders interessant
Um die Latenz zu reduzieren, setzt AMD unter anderem auf "Latest Data Latch". Dahinter verbirgt sich die Vorgehensweise, die aktuelle Kopfposition des Benutzers erst unmittelbar vor der vertikalen Synchronisation auszulesen. Doch was, wenn sich die Position weiter ändert, während das Bild berechnet wird? Dann kommen "Asynchronous Compute Engines" oder asynchrone Shader zum Einsatz. Sie werden schon während des Rendering aktiv und versetzen das Bild an die Stelle, an der sich der Kopf des Anwenders bewegt haben wird. Beide Methoden kombiniert vermindern die Latenz und beseitigen Ruckler und Aussetzer.
[...]
Stecken zwei Radeon-Grafikkarten im Rechner, weist LiquidVR jeder GPU die Bildberechnung für jeweils ein Auge zu. Die VR-Anwendung rendert eine Szene und reicht diese an den LiquidVR-Treiber weiter. Der erzeugt mit einem ersten Thread zwei weitere Threads für je eine Grafikkarte. Diese berechnen dann die Varianten für das linke beziehungsweise rechte Auge. Der Zugriff auf das SDK des Headsets ist dabei optional. Nach Angaben von AMD kann LiquidVR im "Direct to Display"-Modus direkt auf die Displays des VR-Helms beziehungsweise der VR-Brille zugreifen. Das freut die Programmierer, die sich nicht mit jedem Headset vertraut machen müssen. Obendrein verspricht die Umgehung des Betriebssystems einen weiteren Geschwindigkeitszuwachs beziehungsweise eine Latenzabsenkung.
Kein SMT in dem Sinne, sondern tatsächliche Aufsplittung eines Thread in 2 die parallelisiert werden - ist das nicht VISC Technologie?
Die VISC-Technik versucht, mehrere Kerne gemeinsam an einem Thread arbeiten zu lassen, um so Zahl der verarbeiteten Instruktionen pro Takt (IPC) zu erhöhen.
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
Angeblich kommen die Verzögerungen mit der 390X ja daher, dass die kein Rebranding machen wollen, sonder eine komplett neue Reihe mit neuen Chips auf einmal rausbringen wollen. Das würde dazu jedenfalls nicht ganz passen.
 
Man muss zugestehen das AMD im Moment Leaks sehr gut unter Kontrolle hat, definitiv ist nichts bekannt. Steigert die Spannung, Verzögerungen sind natürlich nie gut.
 
Einige Beobachter mutmaßen nun, eine mögliche frühe Veröffentlichung könnte darauf hindeuten, dass die kleinen Karten evtl. doch nur ein Rebranding sind. Das sollte sich AMD nicht erlauben.
 
An reines Rebranding glaube ich nicht, Karten ohne volle Freesync Unterstützung wären ein schlechtes Zeichen.
 
Zuletzt bearbeitet:
Ich denke das Rebranding kann man schon anhand der TDP ausschliessen.
 
Unterm Strich ist alles ein Teil der Gerüchteküche und gesicherte Informationen kommen da sicherlich nicht her.
Die Warscheinlichkeit ist aber in meinen Augen recht hoch das recht neue GPUs wieder der Tonga in die neue Generation übernommen werden.
In der unteren Preisklasse, welche nicht von den APUs abgedeckt werden kann, halte ich allerdings auch ältere GPUs für möglich da diese ganz einfach noch gut genug wären. Hier halte ich den Bonaire für einen guten Kandidaten.

Ich halte es einfach für sehr warscheinlich das es ein Mix aus alten und neuen GPUs wird.
 
3D Center hat das mit der TDP auch noch mal aufgenommen:

Nach genauer Betrachtung der Stromverbrauchswerte erscheint aber die Variante, daß es sich um einen wirklich neuen Grafikchip handelt, immer mehr wahrscheinlich: Denn die für die Radeon R9 370 angegebene Boardpower von 110-130 Watt ist einfach zu niedrig für den Pitcairn-Chip, welcher selbst in abgespeckter Form immer eine Boardpower von 150 Watt und mehr aufgewiesen hatte (selbst wenn der reale Stromverbrauch meist niedriger lag). Insbesondere die notierten "ab 110 Watt" deuten eher auf einen anderen Grafikchip als Pitcairn hin – und eine total abgespeckte Pitcairn-Variante (mit entsprechend niedrigem Stromverbrauch) wird AMD kaum als "Radeon R9 370" in den Handel schicken können, jene wäre dann schließlich langsamer als eine aktuelle Radeon R9 270. Gut möglich also, daß mit Trinidad dann doch ein neuer Grafikchip kommt – mittels welchem AMD dann aber die hohe Aufgabe angeht, unter derselben Fertigungsgröße mehr Performance zu einem geringeren Stromverbrauch herauszuholen: Denn schließlich scheint zwischen Radeon R9 270 und 370 ein etwas niedrigerer Stromverbrauch schon offensichtlich, während man wenigstens etwas Mehrperformance zugunsten der neueren Generation genauso annehmen darf.

Hardware- und Nachrichten-Links des 11. März 2015 (3D Center)
 
Zuletzt bearbeitet:
Keine Ahnung wie man überhaupt auf die Idee kommt, AMD würde Pitcairn noch mal als Mittelklasse Karte auflaufen lassen.
 
Wenn die Verbreitung einer Idee hilft, das eigene Weltbild zu pflegen und zu entstauben, denkt man sich eben etwas aus und verbreitet es. Ganz simpel.
 
naja, da hier 3d-center zitiert wurde, haben die aber auch vor einem monat eine zusammenfassung der gerüchte veröffentlicht. und da ist innerhalb der 3er serie doch einiges an rebranding zu finden. dass tonga wieder auftauchen wird, war sehr naheliegend. aber dort findet man auch pitcairn als mögliches rebranding für die radeon r7 360 & 360x

http://www.3dcenter.org/news/amd-ra...-als-380x-fiji-als-390x-und-bermuda-als-395x2

was die aktuellen gerüchte bzgl. der 370 im april angeht, so geht das offenbar auf eine meldung von videocardz zurück. und auch dort wird über ein rebranding spekuliert. im falle der r7 360 & 360x ist es hier aber bonaire als mögliche grundlage.

soll man im moment auch nicht überbewerten, so lange es sich um gerüchte handelt.

http://videocardz.com/55051/xfx-radeon-r9-370-core-edition-leaks-out-coming-early-april
 
Zu Vulkan gibt es jetzt auch die Slides von der GDC-Präsentation mit Johann Andersson & Co.

Wenigstens darin: Auf Seite 6 ein großes Dankeschön an AMD, und auf Seite 8 nochmal: "Mantle pioneered & led the way", und auf Seite 10: "Vulkan: Based on
Mantle – standardizes & replaces it" ... Aber was weiß ich schon ...

Edit: Und auch: "Frostbite will transition our Mantle renderer to Vulkan"
 
Wenn man von folgenden Voraussetzungen ausgeht...

Radeon R9 390(X) - Fiji
Radeon R9 380(X) - Hawaii
Radeon R9 370(X) - Tonga

... ergibt sich in der Tat eine Lücke und zwar bei der Radeon R9 360(X).

Der Bonaire Chip ist für das Jahr 2015 zu schwach, um eine Renaissance als Raden R9 360(X) zu erleben. Allerdings kann AMD den Bonaire Chip auch nicht als Radeon R7 340/350 launchen, denn dafür wäre die GPU zu teuer in der Fertigung und hätte einen zu hohen Stromverbrauch. Eine Karte der Leistungsklasse einer Radeon R7 340/350 müsste ohne 6-Pin PEG Buchse auskommen können. Den Bonaire Chip deutlich unter 75W TDP zu drücken, sollte zwar machbar sein, würde aber viele Einschnitte bedeuten. Somit bedarf es eigentlich zwei neuer Chips und zwar sowohl für die Radeon R9 360(X), als auch für die Radeon R9 340/350. Dass AMD noch einmal Pitcairn oder Tahiti aus der Versenkung holt, wage ich sehr zu bezweifeln. Dafür haben sie nun wahrlich zuviele Jahre auf dem Buckel und zuletzt wurde der Treibersupport schon für die GNC 1.0 Architektur schrittweise zurück gefahren.
 
Zurück
Oben Unten