Test AMD Radeon VII im Test: Zu laut, zu langsam und zu teuer, aber mit 16 GB HBM2

https://www.kmcomputer.de/detail/index/sArticle/49964 auch verfügbar.


es gibt sein dem 11. feb. ein neuen treiber - jetzt wird der takt gehalten, auslastung immer bei 99-100% (paar games und benches getestet).
auto oc lässt jetzt aber den pc sofort abschmieren. der vram leer sich nicht sondern läuft immer weiter voll - auch nach game beenden.
 
Jesterfox schrieb:
denen war sie wohl eindeutig nicht zu teuer ;-)

Wenn sie noch ein wenig preislich runterkommt, der Treiber sich weiter stabilisiert und es Waküblöcke dazu gibt, dann muss wohl doch meine Vega 56 weichen.

pupsi11 schrieb:
der vram leer sich nicht sondern läuft immer weiter voll - auch nach game beenden.

Deshalb hat sie ja auch 16 GB, da muss man nix freigeben ;) :D
 
  • Gefällt mir
Reaktionen: Strikerking
obwohl ich kein Freund von Lauch Tests bin , weil sie nie die tatsächliche Leistung wiederspiegeln , weil meist nur bessere Beta Treiber Verwendung finden , hier mal die Zusammenfassung von 18 Tech Seiten
3DCenter-pcgh.png


ziemlich genau 1080 TI Leistung , wobei die NV Karten die ausgereifterten Treiber hatten ...
nur als Hinweis : Radeon VII =13,2 Mrd Transistoren , 1080 TI =12 Mrd Transistoren , 2080 TI = 18,6 Mrd
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: arvan und zera13
Faust2011 schrieb:
Wenn sie noch ein wenig preislich runterkommt, der Treiber sich weiter stabilisiert und es Waküblöcke dazu gibt, dann muss wohl doch meine Vega 56 weichen.
Wenn ich mir zwischenzeitlich nicht ne Vega hätt kaufen müssen hätt ich mir wohl schon ne VII als Upgrade für die Fury X geholt. Aber so ist mir der Spaß n bissl zu teuer, eben weil ich erst letztes Jahr schon Geld reinstecken musste (und mir die Vega in den meisten Fällen auch noch locker reicht)
 
Das ist total verrückt, was da gemacht wurde und zeigt, welches Potential die GCN-Karten, zu denen auch die Radeon VII gehört, haben und eigentlich doch auch im Gaming-Bereich zeigen können.

Das wichtigste aus dem hier:

Bard schrieb:

Marek Olšák from AMD's Linux driver team just published a patch which greatly improves the average frame rate in some situations by using primitive culling with async compute shaders

Da wird also, bevor überhaupt in der Geometrie-Pipeline die 3D-Weltberechnung los geht, erstmal per Compute Shader die Geometrie (bzw. die Objekte, Figuren, ...) aussortiert, die derzeit in der Welt (Spielzene) gar nicht dargestellt werden müsen. Damit spart man sich unnötig viel Arbeit auf der Grafikkarte. Das geniale an diesem Ansatz ist nun, dass das bereits auf Treiberebene gemacht wird.

Derzeit liegt der Patch von diesem AMD-Programmierer in einem privaten Repository für Mesa, was ein Linux-Treiber ist. Hoffentlich findet AMD Möglichkeiten, das auch in den Windows-Treiber zu integrieren und zumindest optional aktivierbar zu machen.

Einen Haken hat jedoch die Sache: Die Performancebeschleunigung gibt es natürlich nur, wenn in Spielzenen auch Objekte sind, die aussortiert werden können (weil sie verdeckt sind durch andere Objekte).

Und wer sich Hoffnung macht, dass das auch für Nvidia passt: Zum einen können ihre bisherigen Grafikkarten keine ComputeShader so effizient wie AMDs GCN parallel zur Graphics Pipeline ausführen lassen und zum anderen machen die das (vermutlich) bereits... entweder im Treiber oder Hardware.
 
  • Gefällt mir
Reaktionen: Wadenbeisser und thermalpaste
Ein anderer Haken ist das NV nahestehende Studios ihr bestes geben werden eine solche Technik zu torpedieren ....
Ich erinnere mich noch gut an Games da wurde nur ein Teil Wasseroberfläche gezeigt , tessaliert , jedoch ging die tessalierte Wasser Oberfläche über den ganzen Bildschirm , nur um die Einheiten auszulasten weil NV die leistungsfähigeren Tessalations Einheiten hatte ...
Mittlerweile werden unnötig hohe Tessalations Stufen ja vom AMD Treiber deaktiviert , möglich das man ähnliches mit verdeckten Objekten versuchen wird , jedoch wäre es sinnvoller wenn die Gameentwickler das bereits täten bzw die Gameengine . Da wird leider zuviel auf NV optimiert und zuwenig auf AMD ...
 
  • Gefällt mir
Reaktionen: Jesterfox
Ein weiterer Haken ist, dass die Radeon VII überteuerter Schrott ist...
 
Was daran unter anderem liegt, dass Nvidia hier mit viel Know How weiterhilft und den Studios hier viel Geld spart. Sie investieren also auch. ICh verstehe nicht, wieso dass ihnen immer negativ angekreidet wird. AMD stünde es frei, hier ebenso den Studios unter die Arme zu greifen. TUn sie nicht. Muss man sich wirklich wundern, dass irgendwer mehr optimiert wenn er dafür auch die entsprechende Hilfe und das Know how zur Verfügung gestellt bekommt? Dies kostet Nvidia schließlich auch richtig viel Geld, denn sie bezahlen ihre Mitarbeiter schließlich dafür, dass sie die Studios unterstützen.

Ich als Kunde sehe für mich da nur Vorteile, weil Nvidia so dafür sorge trägt, dass die Spiele zumindest auf Ihren Karten bei mir daheim entsprechend fehlerfrei laufen. Die Unterstellung, man würde parallel AMD aktiv boykottieren, halte ich hingegen für verschwörungstheoretischen Unfug. Die Besserleistung ist das simple Resultat von besserer und umfangreicherer Hilfestellung.
 
MK one schrieb:
jedoch wäre es sinnvoller wenn die Gameentwickler das bereits täten bzw die Gameengine .
Wenn ich die Kommentare bei dem reddit Post richtig les wird bei Frostbite und IDTech sowas schon in der Engine gemacht, bei Unity und Unreal aber nicht.
 
@CrEaToXx

Auch bei dir ist die Argumentation für die Aussage der Hammer!
 
  • Gefällt mir
Reaktionen: zera13
Faust2011 schrieb:
zum anderen machen die das (vermutlich) bereits... entweder im Treiber oder Hardware.

Grundsätzlich macht es jede Grafikkarte und API bereits und es exisitieren mehrere Layer dafür. Zum einen wird per Frustum Culling überhaupt ermittelt was sich in sichbaren Bereich befindet und dann über einen Z-Buffer ermittelt welche Punkte von anderen überdeckt und somit gar nicht weiter bearbeitet werden müssen.

Der neue Ansatz optimiert anscheinend einen Teilbereich dieser Techniken auf AMD Hardware.
 
Zuletzt bearbeitet:
xexex schrieb:
Der neue Ansatz optimiert anscheinend einen Teilbereich dieser Techniken auf AMD Hardware.

Ja und nein. Natürlich, es wird bereits viel Geometrie gecullt bzw. geprüft, ob geculled werden kann. Allerdings war das bisher a) zu spät (d.h. dass bspw. der Vertex Shader schon lief) und b) es nun direkt auf der GPU stattfindet wie an anderen Stellen per CPU da im Treiber.
 
amd hat es schon mal hinbekommen mit dem neusten treiber das man oc kann.
ueber 2xxx mhz sind schon möglich.
 
http://www.pcgameshardware.de/Radeo...194/News/Radeon-VII-Overclockin-Test-1275428/
AIDA64-GPGPU-Radeon-VII-pcgh.png

AIDA64-GPGPU_Radeon-VII-2.000-MHz-pcgh.png

oben @ stock , darunter @ 2 Ghz
ich denke mal , wenn mann der Radeon VII eine WaKü spendiert die die tjunktion bei 100- 105 Grad halten kann , wird beim OC so einiges möglich sein

@pupsi11
bei 2 Ghz sind 1,18v von nöten ...
Wir erreichen benchmarkstabile 2.000 MHz mit 1,18 Volt (Standard: 1,075 V.) und +20 Prozent Powerlimit. Geringere Spannungen führen relativ rasch zu Abstürzen. Mit 2.000 MHz durchbricht die Radeon VII spielend die Marke von 15 Tera-FLOPS bei einfacher Genauigkeit (FP32) - ein Wert, welcher mit keiner anderen AMD-GPU stabil erreichbar ist
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: pupsi11 und blöderidiot
Zurück
Oben