PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: Intel stellt das Alchemist Grafikchip-Design der Xe-HPG Architekt. vor


Leonidas
2021-08-21, 13:23:04
Link zur News:
https://www.3dcenter.org/news/intel-stellt-das-alchemist-grafikchip-design-der-xe-hpg-architektur-vor

Update ca. 16:18
Absatz mit dem Tensor-Vergleich zu nVidia korrigiert: Es ist nicht die FP32-Einheiten-normiert gleiche Tensor-Power wie bei nVidia, sondern vielmehr eine doppelte (zugunsten von Intel).

Gast
2021-08-21, 16:12:32
Wär hätte es gedacht dass Intel mal AMD den A*sch retten wird :D

Seit wann hat allerdings RDNA2 Tensor/Matrix-Cores das wäre mir neu?

Leonidas
2021-08-21, 16:21:34
Die können das über die normalen Shader-Einheiten berechnen. Habe ich am Ende der Tabelle als Anmerkung gesetzt.

Dorn
2021-08-21, 16:52:36
Wenn die zwei Punkte passen, könnte es sogar ein Kauf werden sofern hier Intels Grafikkarten zur UVP angeboten werden.
Habe jetzt solange gewartet, jetzt warte ich noch bis Q1 2022.

Gethvel
2021-08-21, 17:18:14
Wär hätte es gedacht dass Intel mal AMD den A*sch retten wird :D

Dann kann AMD endlich FSR in die Tonne treten. :rolleyes:

iamthebear
2021-08-21, 23:37:05
FSR hat weiterhin seine Daseinsberechtigung für alle Spielehersteller, die es sich nicht antun wollen ein temporales Upscalingverfahren zu integrieren.
Langfristig könnte es jdoch wirklich so weit sein, weil man dann TAA ersetzen kann (wo es ja auch bessere und schlechtere Implementierungen gibt).

Aber davor muss sich XeSS erst einmap beweisen, dass die Ergebnisse tatsächlich so gut sind und vor allem (wo ich mehr Bedenken habe) das Ganze auch auf Nvidia/AMD GPUs ausreichend performant läuft sodass es auch ohne starke RT Effekte Sinn ergibt.

Gast
2021-08-22, 02:18:25
Die können das über die normalen Shader-Einheiten berechnen. Habe ich am Ende der Tabelle als Anmerkung gesetzt.

Klar können sie FP16/INT8 über die Shadereinheiten berechnen.
Das ist ja gerade der große Unterschied, wenn RDNA2 INT8/FP16 berechnet machen das die Shadereinheiten, oder anders ausgedrückt während INT8/FP16 berechnet wird ist der FP32-Througput 0.

NV und Intel können INT8/FP16 berechnen während gleichzeitig der FP32-Throughput unangetastet bleibt.

Leonidas
2021-08-22, 05:41:52
Korrekt. Deswegen ist die Spalte "Tensor-Cores" bei AMD auch leer. Die Spalte Tensor-Power darf ich nicht leer lassen - weil dann wieder die Anmerkung kommt, das dies auch bei AMD möglich ist.

GerryB
2021-08-22, 08:06:08
DP4a auf Navi14+RDNA2+R7+Xbox X/S und Turing+Pascal wird auch schnell genug sein, ohne allzusehr FP32-Leistung einzubüßen.
Ich sehe Das eher wie ein AsyncCompute, was letztendlich hilft die Shader zu 100% auszulasten.

DP4a nutzt immerhin INT8 x 4.(x)
Bleibt abzuwarten, ob mehr Shader oder geopferte Chipfläche für MatrixCores sinnvoller sind.
(lt. Grafik gibts nur ca. 5% Unterschied, ... k.A. wieviel Chipfläche die neuen Cores dafür brauchen)

(x)nur Navi 10 und PS5 könnens net nutzen

Gast
2021-08-22, 11:16:13
Man muss ehrlich sagen, es sieht ziemlich vielversprechend aus. Wenn das auch gehalten und geliefert werden kann, sollte Intel gut den Markt aufmischen können.
Bin mir nicht ganz sicher, aber dg1 und die integrierte xe können auch xess oder nicht?

Platos
2021-08-22, 11:33:32
Ob es gut aussieht, kann man eig. erst mit dem Preis sagen.

Und vor allem mit dem Strassenpreis.

sklave_gottes
2021-08-22, 11:52:42
Klar können sie FP16/INT8 über die Shadereinheiten berechnen.
Das ist ja gerade der große Unterschied, wenn RDNA2 INT8/FP16 berechnet machen das die Shadereinheiten, oder anders ausgedrückt während INT8/FP16 berechnet wird ist der FP32-Througput 0.

NV und Intel können INT8/FP16 berechnen während gleichzeitig der FP32-Throughput unangetastet bleibt.

Der FP32-Throughput ist aber nur direkt unangetastet, indirekt über die Speicherbandbreite schon, oder?

Complicated
2021-08-22, 12:32:15
Auf der rechtliche Seite folgt Intel hingegen dem Ansatz von FSR und wird XeSS in Zukunft als OpenSource veröffentlichen und damit anderen Grafikchips zugänglich machen. Die technische Bedingung liegt in der Ausführung von INT8-Berechnungen – was durchaus einige ältere Grafikchips beherrschen, bei AMD alles ab Vega 20 und Navi 12 (nicht Navi 10), bei nVidia alles ab der Pascal-Generation. Dabei soll es laut Intel nur zu einer kleinen Performance-Differenz gegenüber dem Intel-Original kommen – was somit nach AMDs FSR ein weiteres interessantes, offenes Upscaling-Verfahren ergibt, welches den Spiele-Entwicklern zur Verfügung steht.
Damit ist das Auslaufen von Nvidias proprietärem DLSS eingeläutet. XeSS+FSR wird nun die Referenz für die GPU Hardware werden und darauf kann nun sowohl Software- als auch Hardwareseitig auf eine freie Verbreitung und Kompatibilität gesetzt werden. Mit einem dritten Player wie Intel, der derzeit ebenfalls lieber offene Lizenzen als Neueinsteiger bevorzugt, was sich natürlich auch bei einem dominanten Marktanteil schnell wieder ändern kann, wird es zukünftig schwerer für Nvidia solche Alleingänge zu machen die sich auch auszahlen.

Hier wird wohl auch der größte Nutzen für uns Endkunden liegen.

Leonidas
2021-08-22, 12:45:38
Der FP32-Throughput ist aber nur direkt unangetastet, indirekt über die Speicherbandbreite schon, oder?

Das ist eine sehr gute Frage. Auch Register, Caches, Scheduler etc. etc. könnten hier limitierend wirken. Oder am Ende die TDP.

Gast
2021-08-22, 14:27:54
Korrekt. Deswegen ist die Spalte "Tensor-Cores" bei AMD auch leer. Die Spalte Tensor-Power darf ich nicht leer lassen - weil dann wieder die Anmerkung kommt, das dies auch bei AMD möglich ist.

Dann sollte man das aber nicht in die Spalte Tensor Power schreiben sondern eine eigene Spalte FP16/INT8 Leistung machen.

Gast
2021-08-22, 14:46:09
DP4a nutzt immerhin INT8 x 4.(x)
Bleibt abzuwarten, ob mehr Shader oder geopferte Chipfläche für MatrixCores sinnvoller sind.
(lt. Grafik gibts nur ca. 5% Unterschied, ... k.A. wieviel Chipfläche die neuen Cores dafür brauchen)


Laut Grafik ist das Upscaling mit XMX immer geschätzte 2,5-3x schneller als mit DP4a.

Klar durch die eingesparte Renderzeit ist es immer noch gut nutzbar.
Falls aber die benötigte Zeit fürs Upscaling wie bei Nvidias DLSS konstant ist heißt das aber auch, je höher die Framerate ist desto größer wird auch der Vorteil für XMX. Wenn man von unspielbaren Frameraten auf spielbare kommen will macht es natürlich keinen großen unterschied. Wenn man das aber nutzen will um auf die 144 oder gar 240Hz seines Monitors zu kommen, wird der Unterschied aber sehrwohl relevant.

Der zweite Punkt ist, wir sehen hier 1080p auf 4k Upscaling also das Äquivalent von DLSS Performance. In höheren Qualitätsstufen sind die Einsparungen in der Renderzeit natürlich auch wesentlich geringer und damit wird die benötigte Zeit fürs Upscaling auch wieder relevanter.

konkretor
2021-08-22, 15:50:29
Jemand schon Infos ob es den Tapeout schon gab?
Wenn die im Q1 auf dem Markt kommen sollen, müßte ja bald der Tapeout sein.

Ich bin auf die Menge gespannt die Intel liefern kann. (Bei TSMC gebucht wurden)

Gast
2021-08-22, 15:59:43
Jemand schon Infos ob es den Tapeout schon gab?
Wenn die im Q1 auf dem Markt kommen sollen, müßte ja bald der Tapeout sein.


Mit dem was Intel zeigt bin ich mir sicher, dass dass die schon längst lauffähige Hardware in den Händen haben.

Gast
2021-08-22, 16:19:57
Jemand schon Infos ob es den Tapeout schon gab?
Wenn die im Q1 auf dem Markt kommen sollen, müßte ja bald der Tapeout sein.

Ich bin auf die Menge gespannt die Intel liefern kann. (Bei TSMC gebucht wurden)


Tapeout ist schon lange vorbei, letztes Jahr im Herbst irgendwann: https://www.tomshardware.com/news/intel-xe-hpg-dg2-gpu

Samples werden schon lange an Partner ausgeliefert.

konkretor
2021-08-22, 17:46:59
Danke Leute!!!!11

iamthebear
2021-08-22, 18:03:34
1.) Also ich würde in diese Grafik nicht zu viel hinein interpretieren. Das sieht eher mehr nach einer symbolischen Darstellung aus, die sicher nicht maßstabsgetreu ist.

2.) Wenn der Unterschied wie auf der Grafik gezeigt nur um die 5% ist. warum verbaut Intel dann tonnenweise Tensor Cores? Da wäre die Chipfläche in ein paar zusätzlichen Shadern deutlich besser angelegt gewesen, denn ob sich XeSS durchsetzen wird steht noch in den Sternen. In den entscheidenden 1-2 Jahren wird die Verbreitung in den aktuell gespielten Spielen nicht höher sein als bei DLSS.

3.) Ich denke dass die Testzeit mit den fertigen Karten sicher länger dauern wird als bei einer Nvidia/AMD Generation wo man wesentlich weniger Arbeit mit den Treibern hat. Ich denke, dass man auch einige Spiele gleich mit funktionierendem XeSS präsentieren will.

Intel hat was das angeht auch relativ wenig Stress. Nvidia muss einen Launch (z.B. Ampere) immer sehr schnell durchziehen weil sobald die Benchmarks leaken verkauft sich die Vorgängergeneration nicht mehr (zumindest im High End). Bei Intel ist das eine andere Situation. Da will man ohne Probleme in den Launch Reviews starten. Danach kann man in Ruhe alle Mainstream/Midrange Käufer einsacken, da Nvidia/AMD ja hier nicht mehr vertreten sind.

Leonidas
2021-08-23, 05:06:45
Theoretisch richtig. Aber Intel ist nun ganz schön hinter den ursprünglichen Zeitplänen hinterher. Später als Frühling 2022 darf man gar nicht rauskommen - denn im Sommer 2022 winkt man dann schon ab, da geht es Richtung RDNA3 & Lovelace.

Gast Ritis
2021-08-23, 08:30:47
Nur weil Intel XeSS ankündigt darf man nicht gegen AMD zetern.

Erst mal muss das wirklich OS freigegeben werden und erst dann wird man sehen wie das mit anderer HW läuft, welche Performance und BQ das dann bringt und wie viel Arbeit die Entwickler haben das einzubauen.

Wenns hackelig wird werden Game-Devs nur das machen was nicht stört oder wofür es Geld vom HW-Hersteller gibt.

Sollte die Interpretation von Leonidas stimmen hat die Xe viel mehr Tensor-Leistung als alles sonst in dem Bereich, wenn XeSS ohne das nicht performt ist anderen bestehenden GPUs auch nichts geholfen. Am Ende bleibt den meisten Nutzern wieder nur auf FSR Support zu hoffen wenn man keine überteuerte neue GPU kaufen will.

So viel Tensor-Rechenleistung hat auch nichts mit Gaming zu tun. Das ist ein AI-Beschleuniger mit Gaming-Marketing. Da wird die Reise mit oneAPI also hingehen.

Leonidas
2021-08-23, 10:04:20
Man kann ja FP16 auch zur Gaming-Beschleunigung nutzen. Aufgrund der Breite der XMX-Cores sind die nur für XeSS fast schon überpowert.

Gast Ritis
2021-08-23, 10:41:24
ich kann mir nicht vorstellen, dass Tensor Ops, also das Multiplizieren von Matritzen die grösser als ein Vektor sind, in Grafik eine grosse Rolle spielen wird. Sonstige Anwendungsfälle im Gaming bin ich auch unsicher.
Ein normaler Shader-Core für Vektoren sollte dann am Ende effizienter und schneller arbeiten können als ein Tensor-Beschleuniger. So ganz theoretisch zumindest.

Leonidas
2021-08-23, 11:20:48
Gab es nicht die Bestrebungen, einzelne Operationen auf FP16-Genauigkeit runterzubrechen? Dafür wäre so was ideal, wenn man einen expliziten FP16-Beschleuniger hat.

Gast
2021-08-23, 11:46:29
Gab es nicht die Bestrebungen, einzelne Operationen auf FP16-Genauigkeit runterzubrechen? Dafür wäre so was ideal, wenn man einen expliziten FP16-Beschleuniger hat.
Dann kann man aber auch einen Shader auf FP16 optimieren (also 2x FP16 in einem FP32 Shader/Takt).
Die Frage ist halt auch, wie groß und energieeffizient ist das alles? Vielleicht gibt's da ja erhebliche Vorteile für eine Lösung.

Leonidas
2021-08-23, 11:59:03
Ich vermute, die XMX-Cores verbrauchen einen Bruchteil an TDP, wenn man anstatt dessen die normalen FP32-Einheiten benutzen würde. Reine Vermutung natürlich.

Gast
2021-08-23, 14:48:21
Ich vermute, die XMX-Cores verbrauchen einen Bruchteil an TDP, wenn man anstatt dessen die normalen FP32-Einheiten benutzen würde. Reine Vermutung natürlich.
Dazu gibt es zumindest bei AMD rapid packed math, die HW gibt die 16bit SIMD Ergebnisse entsprechend aus, sollte wohl heute auch mit 8bit oder gar 4bit möglich sein. Müsste man recherchieren.

Leonidas
2021-08-23, 15:44:29
Richtig, aber die laufen dann auf den normalen FP32. Könnte aber sein, das extra Cores weniger ziehen - normiert auf die insgesamte Bit-Breite. Einfach weil diese Cores viel kleiner aufgebaut sein können. Ist nur eine Vermutung - welche ein wenig in Richtung big.LITTLE zielt, auf was Intel derzeit ja so schwört.

Gast Ritis
2021-08-23, 16:16:58
- normiert auf die insgesamte Bit-Breite. Einfach weil diese Cores viel kleiner aufgebaut sein können.
Jetzt ist der Gedanke klar geworden. Könnte sein..., insbesondere wenn weniger unterschiedliche Instruktionen implementiert werden wird es einfacher und damit effizienter.

Das ist spricht aber auch wieder gegen Tensor, die Designer allein werden das beurteilen können wo mehr Overhead hinzukommt. Tensor-Cores sind übrigens bei 2d Pixel-Grafik mit Filtern gut anwendbar, bei den dort relativ geringen Datenmengen letztlich auch wieder zu viel des Guten.

Gast
2021-08-23, 22:02:32
Interessant ist auch, dass Intel die doppelte Tensorleistung pro SM/Xe-Core im Verhältnis zu Nvidia verbaut, die Intel XMX-Cores sind sozusagen äquivalent zu den Tensorcores vom A100.

Gast
2021-08-24, 02:08:47
Die technische Bedingung liegt in der Ausführung von INT8-Berechnungen – was durchaus einige ältere Grafikchips beherrschen, bei AMD alles ab Vega 20 und Navi 12 (nicht Navi 10), bei nVidia alles ab der Pascal-Generation
Gab es Tensors nicht erst ab Volta?

Man kann ja FP16 auch zur Gaming-Beschleunigung nutzen. Aufgrund der Breite der XMX-Cores sind die nur für XeSS fast schon überpowert.
Tensor Operationen kommen bei Spielen so gut wie nicht vor, was anderes kannst du mit denen leider nicht offiziel machen.

Leonidas
2021-08-24, 03:47:59
Tensor Operationen kommen bei Spielen so gut wie nicht vor, was anderes kannst du mit denen leider nicht offiziel machen.

Vielleicht verstehe ich das falsch - aber wenn FP16 unterstützt wird, kann man das nicht für alles andere mögliche nutzen?

Gast
2021-08-24, 07:14:56
Tensor Operationen kommen bei Spielen so gut wie nicht vor, was anderes kannst du mit denen leider nicht offiziel machen.

Die Dinger können auch ganz normale FP16-SIMD-Operationen und werden in Shadern auch dazu verwendet, und das parallel zu FP32.

Deshalb hat "Baby-Turing" (GTX 16xx) auch FP16 ALUs anstatt der Tensorkerne, damit der erzeugte Shadercode kompatibel bleibt.

Gast Ritis
2021-08-24, 08:13:44
Ich denke es ist auf Desktop eine Frage für den Treiber mögliche Funktionen in DX12 und Vulkan entsprechend solche Einheiten nutzen zu lassen.
Dazu kommen dann spezifische Software-Tools wie DLSS, XeSS etc. Diese werden dann auch ohne Kenntnis der HW-ISA in Software eingebaut ohne auf die allgemeinen APIs aufzusetzen.

Eigentlich müsste Microsoft mal wieder aktiv werden und die HW-Basis via API für KI-Supersampling und Co. in DX12+ zu standardisieren. Ob das bereits via DirectML gehen würde ist mir nicht bekannt. Es ist ohnehin etwas merkwürdig, zu DirectML gibt es bisher keine bekannten Entwicklungen.
Sobald alle drei GPU-Hersteller eigene Tools anbieten wird der Wunsch für DirectX oder Vulkan basierten Code sicher grösser, vielleicht hat Intel ja ein DirectML Ansatz, man muss warten bis es Open Source verfügbar wird.

Gast
2021-08-24, 09:48:49
Eigentlich müsste Microsoft mal wieder aktiv werden und die HW-Basis via API für KI-Supersampling und Co. in DX12+ zu standardisieren. Ob das bereits via DirectML gehen würde ist mir nicht bekannt. Es ist ohnehin etwas merkwürdig, zu DirectML gibt es bisher keine bekannten Entwicklungen.
Sobald alle drei GPU-Hersteller eigene Tools anbieten wird der Wunsch für DirectX oder Vulkan basierten Code sicher grösser, vielleicht hat Intel ja ein DirectML Ansatz, man muss warten bis es Open Source verfügbar wird.

Die API ist ziemlich egal, es geht um den Algorithmus selbst. Nvidia hält den Algorithmus von DLSS zumindest bis jetzt geheim, während Intel angekündigt hat ihren für XeSS frei zugänglich zu machen.

Wenn der Algorithmus bekannt ist wird sich auch auch eine API finden diesen zu implementieren, wenn nicht nutzt eine "freie" API auch nichts.

Sowohl bei DLSS als auch bei XeSS geht es allerdings nicht nur um den Algorithmus an sich, um diesen einsetzen zu können ist ja auch das NN dahinter notwendig, und rein die Veröffentlichung des Algorithmus muss nicht unbedingt heißen, dass das NN ebenfalls mit veröffentlicht wird.

DerselbeGast
2021-08-24, 18:11:10
Vielleicht verstehe ich das falsch - aber wenn FP16 unterstützt wird, kann man das nicht für alles andere mögliche nutzen?
Wenn du das auf XMX Cores beziehst, so klingt es in deinem Beitrag, und diese wie Tensore Cores von NVidia funktionieren, was "Matrix Engine" impliziert, dann geht das leider nicht. Tensor Cores führen eine einzige Operation, aber massiv aus:
https://developer-blogs.nvidia.com/wp-content/uploads/2017/05/image4.png

Each Tensor Core performs 64 floating point FMA mixed-precision operations per clock ... von https://developer.nvidia.com/blog/programming-tensor-cores-cuda-9/
Das ist was bei Convolutional Networks gemacht wird, es gibt ein paar Tensors/Matrizen mit den Gewichten der Neuronen und du multiplizierst dann einen Ausschnitt vom Bild damit und addierst es auf. Dann gehst du einen Pixel weiter und wiederholst. Du hast dann nur ein Paar Byte die du neu einlesen musst gegenüber hunderten FMAs. Deswegen lohnt sich die Spezialhardware, also ALU und riesen Register, für diesen einen Befehl.


Bei RPM von AMD geht das zum Teil, nicht alle Operationen haben eine FP16 Version und es kostet zwischen FP16 und FP32 zu wechseln, weil du FP32 Register zu paarweisen FP16 Registern umwandeln musst, sodass der Gewinn oft klein ist bzw. es sich negativ erweisen kann.

Leonidas
2021-08-24, 19:59:01
Ok, also nicht nur Performance-Verlust wegen der nominell kleineren Einheiten-Anzahl - sondern auch, weil die Operationen bei den Tensor-Cores viel einfacher durchfliegen können als bei normalen FP-Einheiten. Richtig?

Gast
2021-08-24, 22:56:02
Wenn du das auf XMX Cores beziehst, so klingt es in deinem Beitrag, und diese wie Tensore Cores von NVidia funktionieren, was "Matrix Engine" impliziert, dann geht das leider nicht. Tensor Cores führen eine einzige Operation, aber massiv aus:
https://developer-blogs.nvidia.com/wp-content/uploads/2017/05/image4.png


Die Tensor-Cores müssen diese Operationen aber nicht auf ganz viele Matrizen ausführen, sondern können diese auch auf einfache Vektoren durchführen.

Also ja, alles bis FP16 kann auf den Tensorcores durchgeführt werden.

Die Tensorcores zeigen auch dass ALUs verdammt billig sind, sowohl was Transistoren als auch was Strom angeht, die haben nämlich Tonnen davon. Was teuer ist, ist die ALUs zu füttern (das muss natürlich auch für die Tensorcores passieren) und vor allem die Ansteuerung, die ist bei den Tensorcores extem simpel, daher kann man auch so viele davon haben.

Gast
2021-08-25, 08:44:48
Klingt ja erst ein mal vielversprechend.
Hat leider ein paar (sehr) große ABERs:
- Real Performans mit und ohne Optimierung (bezweifel, daß viele alte Spiele einen "Xe optimizer Patch" bekommen)
- Lieferbarkeit bei Release?
- Preise? Sowohl UvP als auch Straße eff.
- Akzeptanz bei der Software Industrie (Gaming und Prof.)
(- Linux Treiber???? Ja, AMD und NVidia glänzen da auch nicht, wäre doch nen Punkt für Intel?)

Am Ende ist es positive und negativ für uns Nutzer :/.
Klar, ein neuer Mitspieler mischt den Markt auf.
Aber wieder ein neue RT Ansatz? Wie viele Publisher werden es mitmachen, für 3 unterschiedliche Ansätze zu entwickeln?

Da wird es Zeit für VulcanRT, OpenRT und DirectRT. Ka, in wie weit es da schon akzeptierte Lösungen gibt.

Gast
2021-08-25, 11:15:49
Aber wieder ein neue RT Ansatz? Wie viele Publisher werden es mitmachen, für 3 unterschiedliche Ansätze zu entwickeln?

Da wird es Zeit für VulcanRT, OpenRT und DirectRT. Ka, in wie weit es da schon akzeptierte Lösungen gibt.

Dies ist doch bereits der Fall. DirectX hat DXR und Vulkan auch raytracing extension die standardisiert ist. Die meisten Spiele und Applikationen nutzen diese apis in erster Linie. Spezialfälle werden proprietäres wie CUDA/Optix oder RadeonRays oder Intel’s equivalent nutzen.

Gast
2021-08-25, 11:17:22
- Real Performans mit und ohne Optimierung (bezweifel, daß viele alte Spiele einen "Xe optimizer Patch" bekommen)


Spiele werden nicht gegen bestimmte Hardware programmiert sondern gegen gegen eine Generalisierte API. Die Optimierung auf eine bestimmte Hardware ist nicht Aufgabe der Endanwendersoftware sondern die Treibers für die Hardware. Wenn Intel seine Hausaufgaben gemacht hat braucht es keinen "Xe optimizer Patch". Wir wissen natürlich nicht ob Intel das schafft, aber ich denke der Hauptgrund dass Arc erst 2022 erscheint sind die Softwareanforderungen, die Hardware dürfte schon längst spruchreif sein.
Dass Intel solche Verschiebungen in kauf nimmt, gerade in Zeiten des Grafikkartenmangels in denen man auch mit mangelhafter Hardware immer noch kommerziell erfolgreich sein könnte, deutet auf jeden Fall darauf hin, dass Intel um jeden Preis einen guten Ersteindruck hinterlassen will.


- Lieferbarkeit bei Release?
- Preise? Sowohl UvP als auch Straße eff.


Das kann man logischerweise vorher nicht wissen, aber der späte Release deutet zumindest darauf hin dass man ordentliche Mengen vorproduzieren kann um zumindest für den ersten Schwung gewappnet zu sein.


- Akzeptanz bei der Software Industrie (Gaming und Prof.)


Das darf keine Voraussetzung sein, ansonsten könnte niemand in einen bestehenden Markt einsteigen. Die Hardware (bzw. genauer deren Treiber) muss sich an die Software anpassen nicht umgekehrt.


(- Linux Treiber???? Ja, AMD und NVidia glänzen da auch nicht, wäre doch nen Punkt für Intel?)


Das dürfte der einfachste Punkt sein, da sich AMD/NV hier auch nicht immer mit Ruhm bekleckern und Intel generell für gute Linux-Unterstützung bekannt ist.

Bei der Marktdurchdringung von Linux am Desktop hat das aber auch überhaupt keine Relevanz für einen möglichen Erfolg oder Nichterfolg der Hardware.


Am Ende ist es positive und negativ für uns Nutzer :/.


Negativ ist es garantiert nicht, entweder es ist positiv für die Nutzer oder im schlimmsten Fall ändert sich nichts und Intel hat wieder mal eine Menge Geld verbrannt.


Klar, ein neuer Mitspieler mischt den Markt auf.
Aber wieder ein neue RT Ansatz? Wie viele Publisher werden es mitmachen, für 3 unterschiedliche Ansätze zu entwickeln?


Intel wird genauso DXR unterstützen, da braucht kein Publisher irgendwas mitmachen.


Da wird es Zeit für VulcanRT, OpenRT und DirectRT. Ka, in wie weit es da schon akzeptierte Lösungen gibt.

Gibt es doch schon längst.

Gast Ritis
2021-08-25, 13:58:57
Die API ist ziemlich egal, es geht um den Algorithmus selbst. Nvidia hält den Algorithmus von DLSS zumindest bis jetzt geheim, während Intel angekündigt hat ihren für XeSS frei zugänglich zu machen.

Wenn der Algorithmus bekannt ist wird sich auch auch eine API finden diesen zu implementieren, wenn nicht nutzt eine "freie" API auch nichts.

Sowohl bei DLSS als auch bei XeSS geht es allerdings nicht nur um den Algorithmus an sich, um diesen einsetzen zu können ist ja auch das NN dahinter notwendig, und rein die Veröffentlichung des Algorithmus muss nicht unbedingt heißen, dass das NN ebenfalls mit veröffentlicht wird.

Intel sieht das offensichtlich etwas anderes, aus dem WCCFtech Interview:

That's an interesting question. First of all, I would wanted to point out that both the DP4a version and the XMX version are exposed through the same API. So as far as the integration is concerned, it's actually the same, it's the same. What the game engine sees is the same interface and underneath that interface, you know, you can select the DP4a or the XMX version and depending on the platform. So I wanted to clarify that, it's not two different interfaces. It's the same interface and the same library that it's integrated with two different paths inside of it, which makes it a lot easier for game developers.

Now, coming to your question. So, for DP4a, yes, SM 6.4 and beyond SM 6.6 for example supports DP4a and SM 6.6 also supports these packing intrinsics for extracting 8-bit data and packing 8-bit data. So we recommend SM 6.6.

We don’t use DirectML. See the kind of performance that you're looking at when it comes to real time, even a hundred microseconds is very significant. And so for our implementation we need to really push the boundaries of the implementation and the optimization and we need a lot of custom capabilities, custom layers, custom fusion, things like that to extract that level of performance, and in its current form, DirectML doesn't meet those requirements, but we are certainly looking forward to the evolution of the standards around Matrix acceleration and we're definitely keeping an eye on it and we hope that our approach to XeSS sets the stage for the standardization effort around real-time neural networks.

WedgeAntilles
2021-08-25, 15:54:58
Negativ ist es garantiert nicht, entweder es ist positiv für die Nutzer oder im schlimmsten Fall ändert sich nichts und Intel hat wieder mal eine Menge Geld verbrannt.

Da Intel auch bei TSMC fertigt könnte es theoretisch sein, dass die gesamte Verfügbare Menge an GraKas identisch bleibt.
Gäbe es Intel nicht, hätten Nvidia + AMD mehr zur Verfügung.
Falls also die IntelGraKa ein Reinfall wird gäbe es unterm Strich für den Konsumenten weniger Grafikkarten zu kaufen.

Ich sage nicht, dass das definitiv so ist - aber theoretisch ist es möglich.

Gast Ritis
2021-08-25, 17:46:37
Da Intel auch bei TSMC fertigt könnte es theoretisch sein, dass die gesamte Verfügbare Menge an GraKas identisch bleibt.
Gäbe es Intel nicht, hätten Nvidia + AMD mehr zur Verfügung.
Falls also die IntelGraKa ein Reinfall wird gäbe es unterm Strich für den Konsumenten weniger Grafikkarten zu kaufen.

Ich sage nicht, dass das definitiv so ist - aber theoretisch ist es möglich.
Könnte sein, mit Intel vermute ich aber, dass erstmal insgesamt noch mehr dGPUs verkauft werden, der Bedarf steigt weil neue OEM Kunden angesprochen werden.

Im Prinzip haben wir mit Samsung und TSMC Fabs mehr Chip-Output als die Gen zuvor. Zumindest vermute ich dass die Waverstarts zusammen in 7nm TSMC und 8nm Samsung mehr Kapazität hatten als Glofo 12 und TSMC 12nm der Vorgängergenerationen.

Wenn alle nur noch bei TSMC buchen könnte es wieder mengenmässig knapper werden, die Hoffnung ist zumindest dass Intel auf seinen Anlagen und Nvidia auf Samsungs Anlagen ebenso diverse Varianten auflegen und dass die Konsolen erstmal nicht zur gleichen Zeit auf die neuen TSMC Fertigungen in Millionen-Stückzahlen durchschlagen.

Gast
2021-08-26, 07:31:10
Gäbe es Intel nicht, hätten Nvidia + AMD mehr zur Verfügung.
Falls also die IntelGraKa ein Reinfall wird gäbe es unterm Strich für den Konsumenten weniger Grafikkarten zu kaufen.


Nachdem Nvidia bei Samsung fertigt, und Intel vorerst die einzige 6nm GPU bleiben wird steht diese zumindest in erster Generation nicht in Konkurrenz um Kapazitäten mit AMD und Nvidia.

Das könnte sich in zukünftigen Generationen natürlich noch ändern, aber die wird es nur geben wenn die Grafikkarten eben kein totaler Reinfall werden und Intel damit Intel nicht die Reißleine zieht.

Und selbst mit der gleichen Menge an Grafikkarten hätten wird zumindest den Zustand keiner Verbesserung, aber auch keiner Verschlechterung für den Kunden, sollte sich die Grafikkartenmenge erhöhen wäre es in jedem Fall eine Verbesserung.