ArrakisSand schrieb:
Ich glaube nicht daran das diese Architektur noch Potenzial haben wird.
Abwarten und Tee trinken.
Intel ist sich der Probleme mit Xe ARC bewusst und wird daran auch sicher Arbeiten. Sie haben ein kleines Treibermonster - nicht nur von der Qualität her, auch davon, was sie alles bei Spielen anfassen müssen, damit sie ihre Architektur ausgelastet bekommen.
Es gibt dabei die Arten von Optimierungen, die man auch bei NVIDIA und AMD findet - fett - und es gibt halt auch einen Punkt, den Intel vorsieht - fett & rot - der so aber überhaupt nicht vorkommen sollte, weil dass die Art von Optimierung ist, die tödlich für Hersteller ist: "We are improving our process over time and have developed a collection of techniques that don’t require game updates when the title is no longer in development, but instead can be done solely in the driver.
This includes identifying specific application processes and then passing flags to our compiler for efficient memory utilization, optimizations of what type of SIMD instruction is preferred, and
even wholesale shader replacements to ensure optimal hardware performance."
Intel nett aber auch den Grund dafür: "The Intel Arc graphics products are a new entrant to the discrete GPU landscape, and a lot of shader programs assumed certain characteristics about the underlying GPU architecture that simply don’t match well with the Xe HPG architecture."
Dieser Satz aus dem einen Interview ist im übrigen auch der Knackpunkt. Intel ist sich bestimmter Probleme bewusst, sie schieben hier den schwarzen Peter indirekt den Spieleentwicklern aber auch NVIDIA und AMD zu, da ja bisher für ihre Grafikkarten entwickelt wurde.
Das Ausmaß der "Optimierungen" reicht dabei von relativ einfachen Sachen, die man heute eigentlich im Compilerbau als guten Ton kennt, bishhin zu komplexen Änderungen.
Man wird sehen müssen, wie Intel hier weiter vorgeht, dass Intel ohne "optimierte" Shader aber ca. 13% an Leistunt verliert - oder eben 15 % gewinnt, je nach Basis - ist nicht unbedint positiv. Denn Intel muss bei jedem Spiel jeden Shader prüfen und auch prüfen, ob ihre "Veränderungen" am Ende wirklich auch das Ergebniss bringen, die die Spieleentwickler vorsehen. Das geht zwar "relativ" gut automatisiert mit entsprechenden Testsuiten, nur muss Intel das theoretisch für jede neue Spiele-Version machen, wenn die Entwickler eine neue Version des Spieles bringen.
rg88 schrieb:
Das muss sich erst zeigen. Eine APU ist dort eigentlich nicht notwendig. Dedizierte Karten sind hier ja in allen Belangen von Vorteil. Wozu also einen Kombi-Chip?
Wie viel hast du denn mit HPC-Berechnungen zutun? Weißt du wo die Probleme von Grafikkarten wie der MI 200 oder NVIDIA A100 liegen bei diesen Berechnungen?
Das was AMD hier vorgestellt hat, dass woran NVIDIA und auch Intel arbeiten, was sie ebenso angeteasert haben, löst so einige Probleme im HPC-Markt und dieses Problem nennt sich Bandbreite und ebenso Latenz um die Daten aus der CPU auf die GPU zu bringen, da man sonst zwar die massive Rechenleistung hat, diese aber nicht effizient nutzen kann.
Es hat einen Grund, warum es auch heute noch Szenarien gibt, in denen es sinnvoller ist die Daten in den SIMD der CPU zuberechnen als an eine GPU auszulagern, weil man eine Treiberschicht hat, die dann das ganze aufbereitet und über PCIe an die Grakkarte schickt, die die Daten verarbeitet und dann zurück schicken muss.
AMDs APU wird einen "Unified Memory"-Ansatz haben. Die CPU bereitet die Daten auf, schreibt sie in den Arbeitsspeicher, meldet der GPU, dass sie arbeiten kann, diese holt sich von dort die Daten, bearbeitet sie, schreibt sie zurück und meldet, dass sie fertig ist und die CPU holt sie sich direkt aus dem Arbeitsspeicher ab.
Der APU-Ansatz steigert hier die Effizienz und kann auch beschleunigend wirken, weil der Overhead der Datenübertragung über PCIe entfällt.
rg88 schrieb:
Nur, dass das nicht an eine native Lösung rankommt. Sowas ist immer mit vielen Nachteilen verbunden.
Hast du Entwicklungserfahrung im HPC-Bereich und weißt du auch wie ROCm arbeitet und wie CUDA in ROCm verarbeitet wird? Es scheint an der Stelle nicht so zu sein.
Natürlich ist ROCm keine "optimale" Lösung, nur versucht ROCm nicht CUDA zu emulieren oder zu simulieren, sondern arbeitet auf Sourcecode-Ebene, in dem CUDA mit einem Transcompiler (HIPIFY) in eine "Metasprache" (HIP, eigentlich METAAPI) überführt wird. AMD selbst gibt an, dass es keinen Einfluss auf die Geschwindigkeit bis einen kleinen Einfluss hat.
HIP wird dann entsprechend beim Compilieren direkt in passenden Code entweder für die AMD-Karte übersetzt oder eben für NVIDIA mit den CUDA-Aufrufen. Deswegen auch keinen Einfluss oder nur einen geringen Einfluss auf die Performance, da höchsten noch Controll-Code dazu kommt, der das Programm etwas aufbläht um zu fragen, ob es "HIP-HIP" ist oder "HIP-CUDA". AMD muss nur mit der Zeit die APIs entsprechend einpflegen in ihre Meta-API und intelligent designen, aber auf der Ebene ist das um ein vielfaches einfacher.
rg88 schrieb:
Die 3000er Serie war kaum/nicht schneller als die 2000er Serite
Sie war nicht schneller, gleichzeitig aber - nicht nur durch den Shrink - deutlich effizienter, da man am Speicherinterface gearbeitet hat und mit HD 4000 weitere Probleme löst.
rg88 schrieb:
Schrieb ich etwas anderes?
Ich habe nur die Daten zu deiner Aussage geliefert, damit man den zeitlichen Abstand hat.
rg88 schrieb:
Glaube nicht, dass das die Entwicklungskosten auch nur annährend aktuell deckt. Man weißt die Umsätze hier nicht ohne Grund nicht getrennt aus.
Also, man weiß die Umsätze nicht, aber du willst dann mit Bestimmtheit das sagen:
rg88 schrieb:
verdient AMD aber nichts damit.
Okay. Kann ich verstehen und vermutlich hast du sogar recht, aber wissen können wir es halt nicht. AMD
rg88 schrieb:
Da gibts ja immerhin schon sehr viele andere Firmen mit eigenen Architekturen und alle sind bis auf wenige Einzelfälle wie ARM gegen die Wand gefahren.
Die meiste Firmen sind mit ihrer Architektur wegen der Softwarekompatibilität gescheitert und x86_64 hat dazu beigetragen das PowerPC, SPARC und Co, besoners nach dem Intel auf den x86_64-Zug aufgesprungen ist.
YMMD
