Vorweg: Deine Agression ist an der Stelle unnötig, weil ich dich nicht angegriffen habe!
ETI1120 schrieb:
AMD hätte es mit der Vega gar nichts gebracht eine größere GPU auf den Markt zu bringen. Sie hätte gegen die Nvidia-GPUs kein Land gesehen. Und das obwohl Vega mit HBM, die schnellere Speicherschnittstelle hatte.
Was meinst Du wieso RDNA mit maximal 40 CUs erschienen ist?
Eine netter Versuch einer Belehrun, auch von oben herab, ich habe dir aber in meinem Beitrag erläutert, warum Vega als iGPU nicht die selben Probleme hatte wie Vega 56 und Vega 64 und das hat nichts mit HBM zutun und ja, noch größere CPUs mit Vega hätte AMD nicht geholfen.
Die Probleme von GCN allgemein - und diese Probleme gab es auch schon vonher - war die interne Struktur der CU: 4 * Vec16-ALUs bilden eine CU mit 64 Shadern. Die Treiber verarbeiten die Shader in Wave64-Befehlen und das Problem bei GCN war/ist, dass ein Wave64-Befehl nicht in einem Takt pro CU ausgeführt wird - also auf allen Vec16-ALUs, sondern dass ein Wave64-Befehl nur auf einer Alu der CU ausgeführt wird und damit ganze 4 Takte braucht.
Und damit erneut - und ich wiederhole mich: Pro CU braucht man bei GCN 4 Threads/Shader-Programme um eine CU optimal zu nutzen. Bei Vega8 - Vega11 benötigt man also 32 - 44 Threads/Shader-Programme um die GPU optimal zu nutzen. Vega56 und Vega64 benötigen hingegen 224 - 256 Threads/Shader-Programme die zur gleichen Zeit augeführt werden um optimal ausgelastet zuwerden und die ganze Rechenleistung auf die Straße zu bringen. Du kannst dir dafür den Test hier bei CB zu RDNA durchlesen oder erneut dir das AMD-Whitepaper zu RDNA durchlesen.
Bei RDNA hat man die CU drastisch umgebaut und aus diesem Umbau zieht auch RDNA seine Effizient und dieser Umbau ist auch Grund, warum RDNA2 mit weniger Shadern dennoch mit Ampere sehr gut mithalten kann.
Die CU wurde bei RDNA mit einer zweiten CU verbunden - WGP. Dazu wurden die 4 * Vec16-ALUs pro CU durch 2 * Vec32-ALUs ersetzt, so dass nur noch 2 Threads pro CU notwendig sind. Das führt nun dazu, dass ein Wave64-Befehl in 2 statt 4 Takten ausgeführt wird und durch die weniger ALUs auch weniger Threads/Shader-Programme notwendig sind um alles auszulasten. Und ein weiteres Geheimnis von RDNA ist, dass - anders als bei GCN - ein Wave64-Befehl der nur bis zu 32 Werte enthält, auch nur einen Takt benötigt und erst wenn der Wave64-Befehl mehr als 32 Werte hat, er auch 2 Takte benötigt.
Ebenso hat AMD - auch erneut das Whitepaper - angedeutet, dass auch beim Treiber größere Umbauten anstanden bei RDNA und man wohl mit der Zeit auf Wave32-Befehle umgestellt hat/umstellen will/umtellen wollte. Was wiederum anfangs teilweise die Treiberprobleme erklärt.
Und warum man RDNA nur mit 20 WGP oder 40 CU heraus brachte? Relativ einfach und auch AMD hat das durchaus auch angedeutet: Neue Architektur + neue Fertigung. Es gab genug Gerüchte auch über ein "Big-Navi" mit RDNA1-Architektur. Nur wäre AMD bei einer Big-Navi bei RDNA entweder auf HBM angeweisen gewesen oder hätte eine 512-Bit SI umsetzten müssen und letzteres wollte AMD vermutlich um jeden Preis vermeiden, denn mit 512-Bit-SI haben sie schlechte Erfahrungen gemacht.
ETI1120 schrieb:
Es war der Primitive Shader, der für Vega nie aktiviert wurde. So weit ich es verstehe sind Mesh Shader nicht dasselbe wie Primitive Shaders.
Ja, sie nannten sich Primitive Shaders, man kann nicht jede Codenamen im Kopf haben. Ansonsten: "
Primitive shaders led to task shaders, and that led to mesh shaders."
Das Ziel und die Möglichkeiten hinter den Primitive-Shadern und heute den Geometry-Shadern ist ähnlich und wenn man der Aussage folgt, dann sind die Geometry-Shader die Folge der Entwicklung der Primitive-Shader.
Es sind die selben Ziele, Geometry-Shader sind dabei eine Evolution der Primitive-Shader und damit zwar nicht dasselbe, jedoch gehören sie zu einer Familie.
ETI1120 schrieb:
Der High Bandwith Cache Controller wurde groß angekündigt, hat aber fast nichts gebracht.
Oh, der HBCC hat schon etwas gebracht, nur war der HBCC zu dem Zeitpunkt eigentlich unnötig, weil kein Spiel damals die 8 GiB-VRAM wirklich gesprengt hat und man damit das, wofür er gedacht war, überhaupt nicht wirklich nachstellen konnte.
ETI1120 schrieb:
Der Draw Stream Binning Rasterizer brachte nicht den erhofften Effekt.
Oh, für AMD hat er den erhofften Effekt gebracht und DSBR wird von AMD auch bei RDNA und RDNA 2 verwendet und entsprechend auch weiter verbessert.
AMD hat damals angeben, dass damit die benötigten Date beim Rendern reduziert werden und hat auch entsprechende Vergleiche gebracht. Das Problem ist da eher die Community - auch besonders hier - und was die dann daraus gemacht haben. Der DSBR ist ein Puzzleteil, mit de man den Datenhunger reduzieren kann und dazu das Bild entsprechend gut in Kacheln einteilen kann, daraus wid aber nicht automatisch ein Geschwindigkeitsschub und erst recht nicht, wenn man die Wave64-Problematik mit den GCN CU im Hinterkopf hat.
ETI1120 schrieb:
Ah ja, die FP16 Sache, auch die hat etwas gebracht, nur - erneut - liegt das Problem hier nicht direkt bei AMD, FP16 macht auch heute genau das, was es damals bereits gemacht hat - Funfact am Rande: in DX12 kann man heute als Shader-Programmierin sogar explizit bestimmen, ob man FP16 oder FP32 nutzen will, genau so kann man seit 6.1? in der ShaderLanguage sogar explizit die Vektorbreite für den Shader anpassen und so von Wave16 - Wave64 gehen.
Das Problem erneut ist die CU von Vega - und GCN allgemein - das Problem. Eine Karte die ohnehin bereits Teile der Rechenleistung ungenutzt verpuffen lässt - 4 Wave64-Befehle pro CU, sonst ist sie nicht optimal ausgelastet - wird nicht unbedint viel schneller, wenn man nun mit bis zu 64 FP16-Werten kommt, die dann auf einer CU laufen, statt 4 Takten dann halt nur 2 Takte. ...
ETI1120 schrieb:
Im Vorfeld wurden die vielen neuen Features von Vega in den Foren heftig diskutiert. Umso größer war die Ernüchterung und der Frust, dass diese teilweise nicht einmal aktiviert wurden oder praktisch keinen Nutzen hatten. Hinzu kam, dass Vega im ersten Jahr nicht gut gereift ist.
Die Features wurden im Vorfeld heftig diskutiert und teile der Features wuden durch Unwissenheit der Diskussionsteilnehmer auch massiv verklärt. Der Tiled-Based-Renderer von NVIDIA wurde als das große Geheimnis der Leistung von Maxwell und Pascal verklärt und damit wurde auch dem DSBR "Wunderkräfte" unterstellt. Die Hauptaspekt von TBR als auch DSBR ist es immer, dass man Bandbreite sparrt, weil man entsprechende verdeckte Polygone verwerfen kann und ebenso dass man die Tiles besser auf die Hardare verteilen kann. Das kann Leistung bringen, muss aber nicht.
ETI1120 schrieb:
Genau deshalb sagen viele, dass Vega in erster Linie gar nicht fürs Gaming designed war, sondern als Türöffner fürs GPGPU dienen sollte.
Macht die Aussage aber nicht richtiger, denn die Probleme von Vega sind keine speziellen Probleme von Vega, sondern es sind allgemeine Probleme von GCN - auch hier verweise ich auf das RDNA Whitepaper von AMD, zu finden auf der Webseite von AMD.
GPGPU unterstützen AMD/ATi-Grafikkarten bereits seit den X1x00-Modellen und ATi war damals sogar noch vor NVIDIA im "Markt". GCN hat aber bereits seit Version GCN1 das Problem mit der CU und dass man 4 Wave64-Befehle pro CU braucht um die Grafikkarte optimal auszulasten. Das Problem ist in den ersten GCN-Versionen nicht wirklich aufgefallen, besser es war damals kein so großes Problem:
GCN1 hatte maximal 32 CU und damit 2048-Shader, macht bei 4 Wave64-Befehlen und damit Verbunden 4-Shader Programme ca. 128 Shader, die eine Engine gleichzeitig abfeuern muss im Bild dass ist damals zwar schon viel gewesen, aber nicht unrealistisch und gleichzeitig konnte damit GCN1 gut altern. GCN2 brachte nun 2816 und damit 44 CU und auch hier stehen am Ende "nur" 176 Thread/Shader pro Bild, aber bereits bei der R290 merkte man, dass die Leistung nicht mehr unbedingt in Relation zu den FPS steht.
Die Radeon Fury - 64 CU - hat aber schon 2015 gezeigt, dass da was nicht passt, besonders wenn man sich den Shader-Count der 980 und 980 Ti ansieht.
Und diese Probleme haben nichts mit einer angeblichen GPGPU-Ausrichtung von Vega zutun, die Probleme waren bereits zu GCN und damit Radeon HD 7000 vorhanden, sie traten damals nur nicht in der Form ans Licht, sondern erst später.
Natürlich wird man jetzt damit kommen, dass ja RDNA alias 5700 XT in Spielen ja schneller ist als Radeon Vega 64 und auch die Vega 7, während diese ja in GPGPU viel schneller ist und das der Beweis dafür wäre, dass ist aber - um deine Wortwahl zu nutzen: Blödsinn! Die RDNA-1 GPUs sind in GPGPU nicht schneller sondern langsamer als Vega 56, Vega 64 und Vega 7, weil ihnen ganz einfach die CUs fehlen und das auch im erwartbaren Maß wie die theoretische Rechenleistung fehlt.
RDNA eigent sich, sobald man seine OpenCL-Programme etwas anpasst, genau so gut für GPGPU wie es GCN tat. Einziger unterschied ist, dass man nun statt bis zu 256-Threads zur gleichen Zeit nur noch - damals - 80 und jetzt bis zu 160. Wenn man entsprechend das weiß und beachtet, dann kann man auf diese Eigenheit optimieren und bekommt auch die zu erwartende Leistung.
NVIDIA hat lange Jahre keine wirkliche Unterscheidung zwischen HPC und Gameing gemacht und später beschränkte sich der Unterschied einfach darauf, dass man FP-DP in dedizierte Einheiten auslagerte und diese Strich.
Die erste wirkliche "Trennung" in HPC und Gaming gab es bei bei NVIDIA in Form von Pascal und Volta, wobei man Turing dann durchaus als Volta für Gamer ansehen kann - 64 FP-Shader pro SM, dazu Tensore-Kerne und eben Raytracing + 64 INT-Shader.
Und auch nun die beiden Ampere-Lösungen sind sich in der Architektur ähnlicher, als man vermuten mag. aber über die HPC-Schwäche von RDNA und woher die "kommt", könnte ich einen ganzen Aufsatz mit den dazugehörigen Pseudocodes erstellen.
ETI1120 schrieb:
Bei Vega 20 ist es offensichlich. Hier war die Radeon VII nur ein Lückenfüller bis zur Navi. Und verschwand nach dem Release von Navi bald vom Markt. Die Profi- und die GPGPU-Karten waren lange auf dem Markt.
Die GPGPU-Karten waren lange auf dem Markt, weil Vega7 alleine von der Rohleistung Navi weit überlegen war, weil mehr CU und damit verbunden ALUs. Ebenso die Tatsache, dass man im HPC-Bereich die Daten ganz anders aufbereiten kann für die GPU und es nicht relevant ist ein fertiges Bild nach X Milisekunden zu haben, sondern am Ende es zählt, wann das Ergebnis fertig ist. Man kann im HPC-Bereich also durchaus auf der CPU erst mal die Daten sortieren und passend auf Threads auf der GPU verteilen. Bei einem Spiel geht das leider halt nicht, da kommt der Shader und der muss entsprechend schnell ausgeführt werden.
Im übrigen kommt in dem Fall bei GCN allgemein und Vega auch etwas weiteres zum tragen: Frag dich mal, warum GCN allgemein und Vega weit stärker von Async-Shadern profitiert hat als NVIDIA und NVIDIA erst mit Turing und nun Ampere auch von Async-Shadern profitiert. Kleiner Tipp: Es hat hat mit dem Aufbau der CU bei AMD zutun und dem heutigen Aufbau der SM bei AMD - mit Turing.
Die Async-Schwäche bei NVIDIA bis einschließlich Pascal hat nicht wirklich etwas mit dem Treiber und dem Treiberschedulign zutun, wei man damals gerne vermutet und die Gaming-Probleme unter DX11 bei GCN und speziell bei Vega auch nichts mit dem Hardware-Scheduler. Ich habe genug Hinweise nun eingebaut, denk mal darüber nach!
ETI1120 schrieb:
RPM16 (Rapid Pack Math) wurde von AMD auch als Gaming Preformance Boost für Vega angepriesen, war aber offensichtlich für GPGPU vorgesehen. Nur sehr wenige Games haben RPM16 verwendet.
RPM16 bringt - genau so wie VSR - nur etwas, wenn die Grafikkarte quasi im Limit läut und man bei RPM16 als auch bei VSR auch genug Daten zusammen bekommt. Ansonsten ist der Nutzen eher gering bis nicht vorhanden.
Bei RPM16 als auch VSR kommt es stark darauf an, wie viele Threads/Shader laufen bereits und wie viele Daten kann ich mit RPM16 oder VSR wirklich einsparren und schaufel ich damit Ressourcen frei, die ich dann auch nutzen kann.
ETI1120 schrieb:
Alles keine Gerüchte sondern offensichtlicher Blödsinn.
Ah, offensichtlicher Blödsinn? Und dass es offensichtlicher Blödsinn sind, kannst du auch beweisen? Also wirklich beweisen. Ich würde dir an der Stelle im übrigen empfehlen, wenn du andere schon schräg anmachen willst dass du auch wirklich richtig liest:
Ich schrieb nicht davon, dass Sony zu AMD Ingenieure schickte und die mit diesen Navi entwickelt haben, sondern das Sony hinter Navi die treibende Kraft war und das kann man sehr vielfältig interpretieren. In der Gerüchteküche schreibt man in dem Fall, dass Sony mit GCN nicht so zufrieden war und man daher doch anregte, dass man die Probleme angehen soll und es tiefgreifende Veränderungen braucht.
Genauso besagen die Gerüchte, dass Navi zum Teil hinter Koduris Rücken entwickelt wurde, während er eben Vega favorisierte und ihm da immer wieder Ressourcen wegenommen wurden. Letzteres hat er selbst wohl in einem Tweet auch angegeben.
Das Problem an den Gerüchten ist, dass man sie genauso wenig beweisen/belegen kann, wie dass man sie wirklich wiederlegen - hier halt als Blödsinn abstempeln kann.
Genau so sind deine Anmerkungen, warum Koduri gegangen ist, nur Gerüchte und man könnte manche mehr oder weniger stark als Blödsinn bezeichnen.
Und wenn du glaubst, dass Koduri, auch wenn er Chef der RTG war, nicht hätte übergangen werden können bei gewissen Projekten auch in seiner Abteilung, dan bist du ganz schön naiv. Ich habe sowas schon oft erlebt, dass Teams auch hinter dem Rücken des eigentlichen Vorgesetzten an Projekten bereits gearbeitet wurden und diese Projekte dann an andere Stelle vorgestellt wurden um den eigentlichen Chef zu deskreditieren.
Und nein, AMD hat die RTG nicht wirklich aufgelöst und die RTG wird sogar noch als Bestandteil von AMD geführt.
Für die Hardware - also GPU-Architektur - ist
Martin Ashton zuständig, der von Intel kam und auch vorher durchaus auch an sehr interessanten GPU-Sachen - darunter das Tiled-Based-Rendering und ebenso "PowerVR"-GPUs zuständig war und für die Software ist es nun
Andrej Zdravkovic und der direkte Chef der RTG ist
David Wang. Und gerade mit der Biografie von Wang solltest du dich in dem Fall beschäftigen, denn einige der legendären ATi-GPUs und AMD sind unter seiner Führung entstanden.
