Navi 1X (7nm, RDNA1, 2019) & Navi 2X (7nm, RDNA2, 2020)

[[MK2]Mythos]

Huch, zu später Stunde:

Navi vielleicht doch so schnell wie RTX 2070
und Customs knapp an der Radeon Seven dran vielleicht?

NVidia ist schon an was dran, zumindest sagt dies die WCC Gerüchte Küche:

https://wccftech.com/nvidia-rtx-2070-ti-potential-specs-benchmarks-leaked/
Meine Fresse horn, was soll der link zu der clickbait Seite und dann auch noch zu Gerüchten um eine RTX 2070 Ti?!

[Leonidas]

Inhaltliche Auseinandersetzung damit?

[mczak]

Verkauft nvidia eigentlich nicht ganz voll funktionstüchtige TU 104 als RTX 2070 (TU 104 und 106 sollten ja pin-kompatibel sein, und sonderlich viel muss man da ja nicht mal deaktivieren weil die Chips in jeder Beziehung derart nahe beieinanderliegen)? Ansonsten wäre ein RTX 2070 Ti sicher sinnvoll.
Die 7.5GB Speicher scheinen mir aber mehr als fragwürdig zu sein, es sind ja immer noch 8 MCs (mit je octa-rop). Wie soll denn das gehen, bei einem der 8 8gb Chips (und einem der 8 MCs) ist einer der 2 16bit Kanäle deaktiviert? Da müsste man dann aber auch die Hälfte eines Octa-ROPs deaktivieren können. Wäre ausserdem sowieso ein Problem wenn man da punkto Speichermenge (und auch Speicherbandbreite) hinter die RTX 2070 zurückfällt.
Das ist aber unabhängig davon was AMD mit Navi macht, selbst wenn die RTX 2070 Ti real ist finde ich es ziemlich fragwürdig da irgend etwas herzuleiten punkto Navi-Performance.

[Monsta]

Als Amd die Vega vorgestellt hat, kam die 1070ti auch wie Kai aus der Kiste.
Da sie einen Konter zur V56 haben wollten.

Da ist das mir der 2070ti nicht so unrealistisch um einen Navi Konter zu haben,

[Leonidas]

So gesehen: Ja, möglich.

Dies würde dann allerdings dafür sprechen, das der dickste Navi (von denjenigen, die jetzt im Sommer erscheinen) tatsächlich schneller als eine RTX2070 ist - und damit ungefähr das Performanceniveau von Vega64 hat. Für eine Midrange-Lösung wäre dies toll - und würde vor allem NV beim Preis mächtig unter Druck setzen.

[w0mbat]

Neue Architektur, erste reine "gaming" GPU seit Polaris und 7nm könnten schon was reißen :)

[Dino-Fossil]

http://deow9bq0xqvbj.cloudfront.net/image-logo/2368634/Truetrain.jpg

Mal ehrlich, ich erwarte lieber nicht zu viel von Navi und lasse mich dann im Zweifel angenehm überraschen.

[Palpatin]

Der Wahnsinnshype wird es so oder so eh nicht, entweder es wird 2060 für ~300€
oder 2070 für ~400€, ersters wäre ganz nett, zweiteres wäre zummindest eine Ansage und würde NV zu Preissenkungen zwingen.

[w0mbat]

Hä? 2060er gibts doch schon häufiger für ~300€, das macht keinen Sinn. Aber 2070 Leistung für 300€ wäre doch was.

[Gmax]

Wie sieht es eigentlich mit einer mobilen, dedizierten Version von Navi aus?

Können wir da dieses Jahr da noch was erwarten, oder begeht AMD den Fehler, und liefert das Teil erst wieder viel zu spät?

[aufkrawall]

Falls es dir nicht bewusst ist: Wir wissen noch gar nichts, deine Frage kann nicht irgendwie substanziell beantwortet werden.

[Leonidas]

Grundvoraussetzung einer mobilen Version wäre eine gute Stromverbrauchs-Effizienz. Dies muß das Hauptarbeitsfeld von AMD sein.

Ansonsten wird es schwer für AMD im Mobile-Segment, wenn man keine vollständige Produkt-Palette hat. Sprich, ein Midrange-Navi macht da noch keinen Sommer. Die Notebook-Hersteller wollen genauso mit LowCost- und Mainstream-Lösungen auf Basis derselben Technologie beglückt werden. AMD hat derzeit aber keine Kapazitäten für so viele Chips zur selben Zeit (bzw. liegen diese Kapazitäten eher im CPU-Bereich).

[Zossel]

Wie sieht es eigentlich mit einer mobilen, dedizierten Version von Navi aus?

Wie sind den sie Stückzahlen/Marktanteile von diskreten mobilen GPUs? Lohnt sich das überhaupt?

[Opprobrium]

Wie sind den sie Stückzahlen/Marktanteile von diskreten mobilen GPUs? Lohnt sich das überhaupt?
Irgendwie bestimmt, schon alein wegen des Prestigefaktors. Nur dürfte es dort ähnlich problematisch sein wie mit den CPUs: Die Hersteller werden von nVidia vermutlich etws gegängelt, die DAUs haben (teils natürlich berechtigte) Bedenken wenn nicht GeForce o.ä. draufsteht, und am Ende gibt es für die AMD GPUs nur die abgespeckten Sparversionen, wie zur Zeit bei Lenovo mit den 2000er APUs zu sehen: TPU reduziert, schlechtere Materialien, keine Tastaturbeleuchtung, dunklere Bildschirme etc. pp.

Abgesehen davon dürften idealerweise ohnehin bis auf für absolute DTR Exoten spätestens mit der 4000er APU Generation diskrete mobile GPUs mehr oder weniger überflüssig sein, zumal ich davon ausgehe, daß Intels GPU bemühungen auch an den IGPUs nicht spurlos vorbeigehen werden. Ob man dann noch eine mobile GPU anbietet um die paar tausend Gaminglaptops zu beliefern hängt sicherlich einfach davon ab, ob sich das Desktoppendant ohne großen Aufwand umfunktionieren läßt.

[HOT]

Da stimme ich zu. Jetzt wo Intel ne ernstzunehmende Grafikabteilung hat und die APUs in 7nm-Bereiche vorstoßen dürfte die Zeit der kleinen Geforces in Notebooks dem Ende entgegen gehen. Spätestens wenn Intel Icelake U nächstes Jahr in den Notebookmainstream bringt benötigt man keine Geforces mehr in 95% aller Fälle. Für AMD ist das von Anfang an ein toter Markt. Sofern es keine Massenabnehmer gibt, wie Apple bei V12 bespielsweise, kann AMD sich die Entwicklung mobiler Grafikchips einfach schenken.
Man müsste jetzt eigentlich so schnell wie möglich mit Renoir um die Ecke kommen, damit man ein paar Marktanteile von Intel abgreifen kann, solange Icelake U nicht die Massen bedient.

[Gmax]

Wie sind den sie Stückzahlen/Marktanteile von diskreten mobilen GPUs? Lohnt sich das überhaupt?

Ich denke es werden eine Menge an Gamingnotebooks verkauft, sieh dir doch die Vielfalt an Modellen an, die angeboten werden. Eine gute mobile Midrange GPU (wie die nVidia 2060) würde sich mMn sehr wohl lohnen, aber nicht erst nächstes Jahr.

[HOT]

Jetzt sind ja offenbar neue Konsolen SoCs aufgetaucht. Da für die neuen Konsolen 10-12 TFLOPs, mit eher Tendenz in Richtung letzteren, veranschlagt sind und der Takt auch unter 7nm wohl kaum die 1,5GHz erreichen dürfte (Sweetspot halt), sind wir übrigens zwangsläufig bei 56-60CUs (also 64, wenn man Konsolensalvage einkalkuliert). Navi 10 Lite wird also in etwa in dem Rahmen auftreten. Dazu kann man sich noch bequem 192Bit GDDR6-RAM vorstellen (24GB). Es sollte klar, sein, warum Navi die Skalierung ins Visier nimmt, denn das war bislang immer die Archillesverse von GCN. Für die neuen Konsolen wirds jetzt plötzlich wichtig.

Also SoC: abgespeckte 128Bit Zen2-Kerne mit weniger L3 (4MB pro Modul sind wahrscheinlich), Navi 10 Lite (modifizierte CUs für Konsolenzwecke) 64CUs (davon 4-8 deaktiviert), 24 GB 192 Bit GDDR6-RAM (16Gbit natürlich) und evtl. noch 2-4GB DDR4 für OS. So könnte die PS5 aussehen. Damit wird N10 full sogar sehr sicher 64 CUs beinhalten. Alles andere wär doch arg überraschend. Lisa sagte ja, man wird HighEnd bedienen. Sicher bedingt V20 auch HighEnd, aber es ist halt ein Lückenbüßer.

[BoMbY]

Und ich dachte wir hätten diese schlechten PS5-Gerüchte bezüglich Navi endlich hinter uns gelassen ...

[HOT]

Das heißt doch nicht, dass die Rechenleistung nicht erreicht werden muss.

Darum gings:
https://www.computerbase.de/2019-01/amd-gonzalo-next-gen-konsolen-soc-zen-kernen-navi-grafik/

[robbitop]

Wo ist der Vorteil, wenn man Zen 2 Kerne um 256bit AVX2 abspeckt? Ein CPU Kern selbst macht nur einen Bruchteil des gesamten SoCs aus. So viel Fläche wird man da nicht sparen. Und wenn man keine 256 bit Instructions nutzt, kosten sie auch keine zusätzliche Energie ggü 128 bit.

Kostet sicherlich Aufwand, soetwas aus einem bestehenden CPU Core rauszunehmen und nochmal extra zu validieren. Ob sich das lohnt, wenn man auch einfach einen Zen2 oder Zen/+ Kern, der fertig validiert ist implementieren kann.

An die >5x CUs zu glauben, fällt nicht schwer. Das ist in 7 nm im Bereich des Machbaren und in etwa diese Größenordnung (1x GFLOP/s) wird auch nötig sein, um einen sichtbaren Sprung ggü current gen in 2020 zu bieten.

Google geht ja mit Stadia auf eine ähnliche Größenordnung schon in 2019.

8C/16T + 5x CUs + 2x GB RAM @7nm sind IMO relativ realistisch für 2020 Nextgen.

[HOT]

Na gut, kann auch ein ganz normaler Zen2 Kern sein. An Zen1 (es gibt keinen Zen+, nur Zen1) glaube ich nicht wirklich, dann eher einen abgespeckten Zen2 in 7nm. Ich glaube nicht, dass man auf der ersten Zen-Generation hängen bleibt, wenn man 5 Jahre in die Zukunft plant. Die Katze war grade taufrisch als die letzten Konsolen rauskamen. Wenn die jetzigen Generation rauskommt ist Zen2 dann ja auch schon ne Weile auf dem Markt.

Und bei voller AVX2-Breite gehts mir um die Energieeffizienz. Wenn man sowieso ein neues Design für die Konsole macht, wird man eher Zen2 entsprechend zurechtstutzen als mit altem Kram zu hantieren, das macht einfach keinen Sinn.

[DK999]

Also SoC: abgespeckte 128Bit Zen2-Kerne mit weniger L3 (4MB pro Modul sind wahrscheinlich), Navi 10 Lite (modifizierte CUs für Konsolenzwecke) 64CUs (davon 4-8 deaktiviert), 24 GB 192 Bit GDDR6-RAM (16Gbit natürlich) und evtl. noch 2-4GB DDR4 für OS. So könnte die PS5 aussehen. Damit wird N10 full sogar sehr sicher 64 CUs beinhalten.
Ich glaube ja nicht, dass man nach dem erfolgreichen Shared Memory Konzept der PS4 wieder getrennten RAM haben wird, dafür braucht es wieder zusätzlichen Controller, Verdrahtungsaufwand und man legt sich bei der Geschwindigkeit die Karten, zusätzlich steigert man die Komplexität für den Entwickler. Mit dem Rest gehe ich d'accord :D
Wo ist der Vorteil, wenn man Zen 2 Kerne um 256bit AVX2 abspeckt? Ein CPU Kern selbst macht nur einen Bruchteil des gesamten SoCs aus. So viel Fläche wird man da nicht sparen. Und wenn man keine 256 bit Instructions nutzt, kosten sie auch keine zusätzliche Energie ggü 128 bit.

Wenn man auf AVX verzichtet dann nur, weil es Zen 2 Ausschussware ist und die AVX Einheit defekt sein darf. Ich denke die Zen 2 Chiplets für die Konsole sind eh Desktop/Serverausschuss, der noch gerade die Sweetspot/Turbo-Frequenzen erreicht.

[HOT]

Man verzichtet nicht auf AVX :freak:
Und was hat der Memcontroller damit zu tun? Natürlich bleibt das shared.

[robbitop]

Na gut, kann auch ein ganz normaler Zen2 Kern sein. An Zen1 (es gibt keinen Zen+, nur Zen1) glaube ich nicht wirklich, dann eher einen abgespeckten Zen2 in 7nm. Ich glaube nicht, dass man auf der ersten Zen-Generation hängen bleibt, wenn man 5 Jahre in die Zukunft plant. Die Katze war grade taufrisch als die letzten Konsolen rauskamen. Wenn die jetzigen Generation rauskommt ist Zen2 dann ja auch schon ne Weile auf dem Markt.

Und bei voller AVX2-Breite gehts mir um die Energieeffizienz. Wenn man sowieso ein neues Design für die Konsole macht, wird man eher Zen2 entsprechend zurechtstutzen als mit altem Kram zu hantieren, das macht einfach keinen Sinn.
AVX2 erhöht die Energieeffizienz. In synthetischen Benchmarks doppelter Durchsatz aber weniger als doppelt so viel Leistungsaufnahme.

Wenn es nicht genutzt wird, kostet es keine extra Energie. Wenn es vom Spiel genutzt wird, bringt es mehr Durchsatz.

Spiele nutzen mWn zwar auch SSE/AVX aber offenbar in vergleichbar geringem Maße im Vergleich zu Synthies

[Setsul]

Ausschussware würde Sinn ergeben, ansonsten nimmt man einfach die 2mm² mit. Mit 1,6-3,2 GHz Zen2 ist das sowieso ein enormes Upgrade, den ganzen Kern nochmal neu zu layouten und zu validieren um aufs ganze SoC gerechnet vielleicht 0,5W zu sparen und 100 MHz höheren Takt zu kriegen (weil kein full speed AVX2 mehr erreicht werden muss) ist völlig unnötig.

Wenn Zen2 kein Powergating für die oberen 128 bit hat wäre das schon sehr enttäuschend, aber nur dann würde sich der Verbrauch merkbar ändern wenn AVX2 nicht genutzt wird.


AVX2 in Konsolen-SoCs ist weniger sinnvoll als sonst weil die GPU am selben Speicher hängt und im Gegensatz zu anderen Programmen garantiert ist dass alles sowieso irgendwann auf der GPU landet. Mit geschickter Bastelei an der Reihenfolge kann man die rechenintensiven Teile erst auf der GPU machen die einen wesentlich größeren Effizienzvorteil hat, ohne für den Transfer hin (entfällt weil selber Speicher) und zurück (entfällt komplett) auch nur annähernd so viel zu zahlen wie wenn man in einem synthetischen Benchmark Teile auf die GPU auslagern will. Es ist auch besser als in Spielen auf einem PC weil man nicht alle Daten über PCIe schieben muss, dieses fundamentale Limit dass man maximal ~200 MB (bei 60 fps) an Daten von der GPU verarbeiten lassen kann fällt weg.

[robbitop]

2qmm sind relativ viel geschätzt. Das ist 1 moderner kompletter Kern ohne L2 in 7 nm.

Gravitationsfeld sagte mal, dass gemischtes Rechnen von CPU und GPU zumindest in Currentgen ziemlich langsam aufgrund eines Flaschenhalses ist. Ich bekomme es inhaltlich aber nicht mehr zusammen.

[DK999]

Und was hat der Memcontroller damit zu tun? Natürlich bleibt das shared.
Wozu sollte man DDR4 und GDDR6 verbauen, wenn bei der PS4 schon 8GB GDDR für System und GPU ausreichend war? Für DDR4 bräuchte man einen zweiten Memory Controller, dann doch lieber einfach 4GB mehr GDDR6 verbauen. Damit hat man nur eine Speicherarchitektur im System und muss nicht auf Geschwindigkeitsunterschiede achten.

[robbitop]

DDR4 ist billiger als GDDR6. Somit würde das OS und dessen Features nicht den teuren GDDR6 "klauen". Man kann also weniger GDDR6 verbauen und kommt potenziell mit weniger Kosten aus. Auch würde alles was über den DDR4 läuft keine Bandbreite wegnehmen. Außerdem kostet zusätzlicher Traffic ja auch immer wieder Wartezyklen. Das würde sicherlich helfen.

[DK999]

Würde aber auch die Abnahmemenge bei GDDR drücken und ich glaube nicht, dass das OS während des Zockens so viel Speicherzugriff erzeugt um das zu rechtfertigen. Zugriff auf den GDDR muss die CPU ja dennoch haben (HSA?). Wie sich das auf die Bestückung auswirken würde, weiß ich leider nicht.

[HOT]

Die PS4 Pro hat einen eigenen Speicher fürs OS. Das war gemeint.

Spiele nutzen kein AVX256 oder nur in extrem geringem (und damit irrelevantem) Maße, das ist völlig unnötig dafür ne energiefressende 256Bit FPU zu haben. Entweder man nimmt es in Kauf oder man speckt Zen2 für die SoCs entsprechend ab.

[gravitationsfeld]

Der DDR4 wäre wahrscheinlich wieder an der Southbridge und einem Speicher-Kanal. Sinn ist mit dem low bandwidth Video-Streaming-Gedöns usw. nicht den teuren GDDR6 voll zu müllen.

24GB sind eh schon viel zu wenig, wenn sie davon ansonsten auch noch GBs ans OS opfern müssen wird's arg traurig.

[mksn7]

https://semiengineering.com/gddr6-hbm2-tradeoffs/

Hier gibts mal Größenordnungen zu den Preisen des Interposers: "10's of Dollars"

[reaperrr]

Spiele nutzen kein AVX256 oder nur in extrem geringem (und damit irrelevantem) Maße, das ist völlig unnötig dafür ne energiefressende 256Bit FPU zu haben. Entweder man nimmt es in Kauf oder man speckt Zen2 für die SoCs entsprechend ab.
Für den 256bit-AVX-Support müssen auch andere Bereiche der Pipeline aufgebohrt werden, nicht nur die FPU selbst. Glaube eher nicht, dass es sich lohnt, für marginale Einsparungen mehrere Monate zusätzliche Arbeit (und damit Geld) zu investieren, zumal ein zurückschrauben eben auch den einen oder anderen Prozentpunkt IPC kosten würde (bei AVX logischerweise 2-3-stellig).

Und an Zen(+) glaube ich auch nicht, es wäre nämlich ebenfalls aufwändiger, den Zen1-Kern eigens auf 7nm zu shrinken, anstatt einfach direkt Zen2-Kerne zu nehmen.

Zu guter Letzt ist ein Zen2-Kern in 7nm augenscheinlich sparsamer pro MHz als Zen+ in 12LP, und die 75mm² für ein Chiplet sind jetzt auch nicht so viel, dass man da flächenmäßig unbedingt was sparen müsste. Und wenn doch, würde eine Halbierung des L3 mehr bringen.

[Complicated]

Hier gibts mal Größenordnungen zu den Preisen des Interposers: "10's of Dollars"
Die gibt es seit 2015:
https://www.planet3dnow.de/vbulletin/threads/422600-AMD-Interposer-Strategie-Zen-Fiji-HBM-und-Logic-ICs

Kosten des Interposers bei der Herstellung:
Da es passive Interposer sind, sind die Kosten überschaubar. Das ist simples Silizium von einem Wafer ohne wirklich komplizierte Strukturen:
http://electroiq.com/blog/2012/12/li...poser-pricing/

Der Interposer kostet pro 100mm² 1$
Der gesamte Wafer kostet gerade mal 500-650$

[Setsul]

@robbitop:
War aufs ganze SoC bezogen, ist natürlich keine exakte Zahl, das können auch 4mm² sein oder mehr, der Punkt ist dass es absolut lächerlich ist. PRF wird nicht kleiner wenn man AVX2 nicht komplett rausnimmt, was noch mehr Aufwand ist, dann spart man nur 128 bit and EUs, was in 7nm dann 1/4 von dem ist was man bei SKL-X gesehen hat. Es ist den Aufwand nicht wert.

DDR4 = mehr Bandbreite + billiger ist eine Milchmädchenrechnung. Wenn man weniger GDDR6 Chips verbaut verliert man dort mindestens die gleiche Bandbreite die man durch DDR4 gewinnt. Wenn man DDR4 zusätzlich verbaut ist es nicht billiger.
Klar sind getrennte Speichercontroller nett für Latenz aber dafür muss man wieder alles hin und her schieben und hat mehr Requests als vorher.

[robbitop]

Es ist aber billiger die gleiche Speichermenge auf DDR4 und GDDR6 zu verteilen als die komplette Menge GDDR6. Einfach weil GDDR6 teurer ist als DDR4.

[robbitop]

Die PS4 Pro hat einen eigenen Speicher fürs OS. Das war gemeint.


Ist der PS4 Pro extra Speicher nicht nur für die Videoaufnahme?

[Setsul]

Das habe ich doch so geschrieben?
Gleiche Menge = nicht schneller.
Größere Menge = nicht billiger.
Aber schneller + billiger so wie du dir das vorstellst geht nicht.

Und dann muss man rechnen dass ein zusätzlicher Memory Controller + mehr Arbeit beim PCB Layout + unterschiedliche Chips + geringere Stückzahl GDDR6 auch die Kosten wieder steigen lassen.

Ich meine das ist eine der Gründe wieso man ein SoC verbaut und nicht 5 verschiedene Chips.

[Leonidas]

Es ist vielleicht auch einfach eine Frage des (regulären) Speicherinterfaces. 24 GB passen zu 192 oder 384 Bit. 28 GB passt zu 224 oder 448 Bit. 32 GB passen zu 256 oder 512 Bit. Eventuell hat man eine gewisse Interface-Breite im Blick, ist damit bei der Speichermenge automatisch limitiert - und sieht dann, das man eigentlich mehr Speicher bräuchte? Dann würde sich der extra Klimmzug von extra 4 GB DDR4 durchaus lohnen. Denn mehr GDDR6 würde dann auch ein größeres Interface und damit einen größeren Grafikchip bedeuten.

[mczak]

Hier gilt es zu erwähnen dass gddr6 Chips auch mit 12 Gb pro Chip spezifiziert sind. Ob die jemand bauen wird weiss ich aber nicht...

[][immy]

Die PS4 Pro hat einen eigenen Speicher fürs OS. Das war gemeint.

Nicht wirklich.
Die PS4 hatte bereits ein wenig DDR3 Speicher an bord. Dieser wird für die Standby downloads genutzt damit der stromhungrige GDDR5 Speicher nicht genutzt werden muss (zumindest war das der Plan). Mit der PS4 Pro wurde dieser vergrößert. Vermutlich weil es nach wie vor 1 Chip war und der größere quasi gleich wie viel kostet. Um dann 512MB vom Hauptspeicher freizuschaufeln nutzt man diesen extra speicher dann noch um dort Apps zu halten. Eingeplant war das zuvor sicherlich nicht, da man erst sehr spät mitgeteilt hat, das die Spiele auf der Pro auf 512MB mehr speicher zurgreifen können. Da hat man sich einfach nur zu nutze gemacht, das man diesen zweiten Speicherpool jetzt eh noch vergrößert dabei hatte und dann auch sinnvoll nutzen konnte.
Allerdings schon ziemlich lächerlich wie viel die Betriebssysteme und Apps jetzt veranschlagen, wenn man bedenkt das die last gen mit einem Bruchteil für das OS & co auskam (und da war zumindest auch messaging, "teamspeak" & co bei). Manchmal hab ich das gefühl, da wurde einfach nur massig speicher für die Aufnahme-Funktion geopfert.

Es ist vielleicht auch einfach eine Frage des (regulären) Speicherinterfaces. 24 GB passen zu 192 oder 384 Bit. 28 GB passt zu 224 oder 448 Bit. 32 GB passen zu 256 oder 512 Bit. Eventuell hat man eine gewisse Interface-Breite im Blick, ist damit bei der Speichermenge automatisch limitiert - und sieht dann, das man eigentlich mehr Speicher bräuchte? Dann würde sich der extra Klimmzug von extra 4 GB DDR4 durchaus lohnen. Denn mehr GDDR6 würde dann auch ein größeres Interface und damit einen größeren Grafikchip bedeuten.
Ich dachte eigentlich nach PS3 & xb1 wäre man von 2 Speicherpools wieder komplett weg. Sicherlich kann es sich grad zum Anfang lohnen einen "billigeren" Speicher zu nutzen für das OS, aber auf Dauer ist GDDRx dann auch irgendwie verhältnismäßig günstig.
Im Grunde sehe ich bei 2 Speicherpools kein größeres Problem solange beide groß genug sind und nicht der "OS"-Speicher plötzlich als Grafikspeicher mit genutzt wird. Wobei das natürlich nach wie vor am meisten Sinn macht, was den anfänglichen Preis angeht und auch das man den Grafikspeicher nicht für CPU-Aufgaben ausbremst. Je schneller die CPUs, desto eher kommt das nun mal vor.

[unl34shed]

Unterschiedliche Speichertechnologien heißt nicht, dass man auch zwei Speicherpools im System hat.

Für den gemeinsamen Speicherpool muss der zweite memorycontroler nur von GPU und CPU angesprochen werden können. Wobei, wenn da nur das OS drin liegt, bräuchte es das nicht Mal, denn im Prinzip ist der gemeinsame Speicher ja nur für das Spiel interessant und das läuft eh komplett im GDDR.

[Agent117]

Hier gilt es zu erwähnen dass gddr6 Chips auch mit 12 Gb pro Chip spezifiziert sind. Ob die jemand bauen wird weiss ich aber nicht...

Wenn dann für Konsolen, bei dem Abnahmevolumen.Wäre auch für AMD Navi sicher von Vorteil, wenn man 12 Gb bei 256 Bit anbieten kann.

[Rampage 2]

Hier gilt es zu erwähnen dass gddr6 Chips auch mit 12 Gb pro Chip spezifiziert sind. Ob die jemand bauen wird weiss ich aber nicht...

Was ist eigentlich daraus geworden? Also mit der 1.5x Speicherkonfiguration? Seit GDDR5X ist das ja möglich, wurde aber leider von Nvidia bei Turing nicht verwendet.

Ich gehe deswegen davon aus, dass Nvidia mit dem Turing-Nachfolger gleich direkt auf 16GB VRAM für Gx104 gehen wird - oder aber 384Bit-SI mit 12GB VRAM (bzw. 512Bit mit 32GB für Gx102) sofern GDDR6 nicht höher als 20Gbps skaliert.

640GB/sek. Speicherbandbreite erscheinen mir als etwas zu wenig für einen TU104-Nachfolger...

Gibt es eigentlich irgendwelche Infos, dass auch Nvidia auf HBM2/3 umsteigen könnte mit der nachfolgenden Generation?

R2

[Zossel]

Es ist vielleicht auch einfach eine Frage des (regulären) Speicherinterfaces. 24 GB passen zu 192 oder 384 Bit. 28 GB passt zu 224 oder 448 Bit. 32 GB passen zu 256 oder 512 Bit. Eventuell hat man eine gewisse Interface-Breite im Blick, ist damit bei der Speichermenge automatisch limitiert - und sieht dann, das man eigentlich mehr Speicher bräuchte? Dann würde sich der extra Klimmzug von extra 4 GB DDR4 durchaus lohnen. Denn mehr GDDR6 würde dann auch ein größeres Interface und damit einen größeren Grafikchip bedeuten.

Ein RAM-Interface mit einer Breite =! 2^n wird spätestens für CPUs ziemlich umständlich, wieso funzt sowas eigentlich bei GPUs?

Ich tippe nach wie vor auf 4-8GB HBM als HBCC, und den Rest als normales DDR4.

[unl34shed]

Ein RAM-Interface mit einer Breite =! 2^n wird spätestens für CPUs ziemlich umständlich, ...

Nein nicht wirklich, du lädst halt einfach drei (192) oder sechs (384) Instruktionen auf einmal, die landen im Cache. Aus technischer Sicht, sollte das Interface dafür allerdings eine vielfaches der Architectubreite (32/64bit) sein um einen Vorteil draus zu ziehen.

Theoretisch kannst du aber auch kleiner sein und es wird dann mehrmals gelesen, bis man eine Instruktion komplett hat. Das ist natürlich sehr langsam, weswegen es nichts für Systeme mit mehr als ein paar MHz ist.

Bei Mikrocontrollern hast du sogar teilweise über die SPI (serielles 1-8bit Interface) angebundenen Flash, der Code enthält. Da wird auch recht langsam gelesen und gecached, dann läuft es wie interner Speicher.

[amdfanuwe]

Bei Mikrocontrollern hast du sogar teilweise über die SPI (serielles 1-8bit Interface) angebundenen Flash, der Code enthält. Da wird auch recht langsam gelesen und gecached, dann läuft es wie interner Speicher.
Nicht nur bei Microcontrollern. Beim PC steckt das BIOS doch auch nur noch in einem SPI Flash.

[|MatMan|]

Ich tippe nach wie vor auf 4-8GB HBM als HBCC, und den Rest als normales DDR4.
Wieso sollte das so sinnvoll sein? Die Bandbreite das HBCC wäre wohl nur in etwa so hoch wie von einer reinen GDDR6 Lösung (analog zur PS4). Das wäre also kaum ein Geschwindigkeitsvorteil. Ist DDR4 so viel billiger, dass es die zusätzlichen Kosten für HBM + Interposer etc. aufwiegt? Ich glaube kaum, also auch kein Kostenvorteil. HBCC als reiner Cache bringt also auch nicht mehr Kapazität. Also wozu?
Übrigens wäre HBM als HBCC wohl ohnehin nicht ideal. Wenn, dann müssten die Entwickler darüber Kontrolle haben (und damit wäre es kein transparenter Cache mehr), sonst kann nicht garantiert werden, dass zum Zeitpunkt X auch das richtige im HBM ist und damit wäre das Konstrukt ziemlich wertlos.

[robbitop]

Hbcc ist in einer Konsole (fixierte hw, Entwickler hat volle Kenntnis der HW und Komtrolle) nicht notwendig.

[Zossel]

Nein nicht wirklich, du lädst halt einfach drei (192) oder sechs (384) Instruktionen auf einmal, die landen im Cache. Aus technischer Sicht, sollte das Interface dafür allerdings eine vielfaches der Architectubreite (32/64bit) sein um einen Vorteil draus zu ziehen.

Kann man machen löst aber aber nicht das Problem der "krummen" Adressberechnung (x*3/4) die Zeit kostet die man typischerweise nicht hat. Bleibt also noch die Frage offen was bei GPUs anders ist das die mit krummen Breiten gut klarkommen.

Bei Mikrocontrollern hast du sogar teilweise über die SPI (serielles 1-8bit Interface) angebundenen Flash, der Code enthält. Da wird auch recht langsam gelesen und gecached, dann läuft es wie interner Speicher.

Die µc mit denen ich bisher ein wenig rumgespielt habe hatten alle eine ein eigenes ROM für code. SPI-Flash lässt sich anschließen, wird aber in dem Umfeld typischerweise für Daten genutzt. Code der aus einem SPI-Flash gelesen würde die Reaktion auf externe Ereignisse verlangsamen und das ist das typischer Einsatzfeld von µcs. Mag sein das es vielleicht den ein oder anderen µc gibt der so was macht, das ist aber extrem untypisch. Und bei SPI-Flash ist ein Datum typischerweise auch 2^ n breit.

[Zossel]

Nicht nur bei Microcontrollern. Beim PC steckt das BIOS doch auch nur noch in einem SPI Flash.

Bei der Initialisierung spielt Zeit keine Rolle, und ich würde drauf tippen das das so früh wie möglich ins RAM kopiert wird. Als die Dinger noch gesockelt waren konnte man die im Betrieb raus ziehen und einen Neuen im Betrieb rein stecken um den zu brennen.

[Zossel]

Hbcc ist in einer Konsole (fixierte hw, Entwickler hat volle Kenntnis der HW und Komtrolle) nicht notwendig.

Für die Anwendung ist das transparent. Irgendwo im im virtuellen Adressraum liegen vermeintlich Daten rum die nach Bedarf per Pagefault physikalisch da landen wo die eigentlich sein sollten. Bei HBCC nimmt jetzt auch die GPU an diesem Spielchen teil, das ist extrem praktisch. IMHO kann das auch schon jetzt passieren wenn das RAM nur von einem Typ ist. HBCC baut nur eine weitere Hierarchiestufe rein.

[unl34shed]

Kann man machen löst aber aber nicht das Problem der "krummen" Adressberechnung (x*3/4) die Zeit kostet die man typischerweise nicht hat. Bleibt also noch die Frage offen was bei GPUs anders ist das die mit krummen Breiten gut klarkommen.

:confused: Speicher wird Byteweise addressiert, wie kommst du auf 3/4?

[Zossel]

:confused: Speicher wird Byteweise addressiert, wie kommst du auf 3/4?

Jein, bei vielen (non-X86) CPUs gibt es eine (nicht behebbare) Exception wenn non-aligned zugegriffen wird.

Die Adressen müssen auch irgentwann an den Speicher angelegt werden, und bei einer RAM-Bitbreite von z.b 192 ergibt sich eben CPU-Adresse * 3/4 = RAM-Adresse.

Eigentlich sind das alles totale Basics.

[unl34shed]

Das hat damit überhaupt nichts zu tun. Ich habe ehrlich gesagt keine Ahnung was du da durcheinander wirfst.

kleine Info, die 192bit sind der Datenbus, du liest also 24 Byte pro Zugriff -> der nächste Zugriff ist Addresse + 24
Nochmal wie kommst du auf 3/4?

[amdfanuwe]

Bei der Initialisierung spielt Zeit keine Rolle, und ich würde drauf tippen das das so früh wie möglich ins RAM kopiert wird.
Je nach Anwendung spielt es schon eine Rolle, wie schnell das System nach einem Reset wieder ans laufen kommt.
Bei 4MHz SPI Clock dauert es ca. 1 sekunde, bis 512 kByte übertragen sind.
Ist beim PC vertretbar.
Wie ins RAM kopieren? Der RAM wird ja erst durch den Code initialisiert.

[BlacKi]

Hbcc ist in einer Konsole (fixierte hw, Entwickler hat volle Kenntnis der HW und Komtrolle) nicht notwendig.
und wenn hbcc den entwickler einfach einspart?:biggrin:

[Setsul]

Das ist nicht ein MC, das sind mehrere.
Deshalb kann man auch 32 oder 64 bit abschalten.
Die übertragen alle unabhängig voneinander ihre 32 Byte-Blöcke, egal ob es jetzt 6 oder 7 MCs insgesamt gibt.
Die Adressen sind fest, wenn man 7 MCs mit je 1 GB dran hat dann gehen 0 bis (2^30)-1 an MC1, 2^30 bis 2*(2^30)-1 an M2, 2*2^30 bis 3*2^30-1 an MC3 und so weiter.
Das ist bei CPUs mit 3/6 Channels auch nicht anders. Da werden nicht auf einem 2/3 einer Cache Line pro Takt geladen bloß weil jemand nur 2 DIMMs hat.


Es ist vielleicht auch einfach eine Frage des (regulären) Speicherinterfaces. 24 GB passen zu 192 oder 384 Bit. 28 GB passt zu 224 oder 448 Bit. 32 GB passen zu 256 oder 512 Bit. Eventuell hat man eine gewisse Interface-Breite im Blick, ist damit bei der Speichermenge automatisch limitiert - und sieht dann, das man eigentlich mehr Speicher bräuchte? Dann würde sich der extra Klimmzug von extra 4 GB DDR4 durchaus lohnen. Denn mehr GDDR6 würde dann auch ein größeres Interface und damit einen größeren Grafikchip bedeuten.
Und das DDR4-Interface muss auch irgendwo hin und macht auch einen Chip größer. Bestenfalls wenns ein Chiplet Design ist kommt das dann auf den 14nm I/O-Die und man spart sich 1$. Toll.
Monolithisch spart man sich gar nichts und wenn nur geplant war GPU-Die + CPU Chiplet weil das GDDR-Interface sowieso auf den GPU-Die muss und sich dann ein I/O-Die nicht mehr lohnt, dann wirds völlig absurd weil dann entweder DDR4 und GDDR6 auf der GPU sind oder man ein neue Maske fürs CPU Chiplet auflegen muss nur um DDR4 dranzuhängen. Beides nicht billiger.


Abgesehen davon glaube ich nicht, dass so die Planung aussieht.
"Wir bestehen auf 224-bit GDDR6 aber unter 29,68 GB ist das Ding völlig nutzlos also müssen wir noch mindestens 2 GB DDR4 dranhängen."
Im Zweifelsfall gibts eher zu wenig und die Entwickler müssen einfach damit leben.

Entweder da wird ein GPU-Die wiederverwendet und dann gibts keine Spielereien wie 224-bit (nur durch abschalten, aber dann wäre die Größe ja gewollt) aber dann kann ich mir auch nicht vorstellen dass viel Geld dafür in die Hand genommen wird Sonderwünsche wie extra DDR4 zu verwirklichen, oder die GPU ist sowieso custom und sie können sich die Breite aussuchen.


Also wenn DDR4 kommt dann wieder für Low Power Idle, nicht weil es alles schneller, besser und billiger macht (kann es nicht) und auch nicht weil irgendjemanden auffällt dass sie noch 4 GB mehr brauchen sonst ist das Ding Schrott.

[amdfanuwe]

und man spart sich 1$. Toll.

Bei 80 Mil. Konsolen 80 000 000$ gespart. Immer noch Toll?

[Brillus]

Das ist nicht ein MC, das sind mehrere.
Deshalb kann man auch 32 oder 64 bit abschalten.
Die übertragen alle unabhängig voneinander ihre 32 Byte-Blöcke, egal ob es jetzt 6 oder 7 MCs insgesamt gibt.
Die Adressen sind fest, wenn man 7 MCs mit je 1 GB dran hat dann gehen 0 bis (2^30)-1 an MC1, 2^30 bis 2*(2^30)-1 an M2, 2*2^30 bis 3*2^30-1 an MC3 und so weiter.
Das ist bei CPUs mit 3/6 Channels auch nicht anders. Da werden nicht auf einem 2/3 einer Cache Line pro Takt geladen bloß weil jemand nur 2 DIMMs hat.


Macht keinen Sinn die sin 100% interleaved, sonst wurden 90%+ aller Anwendungen nur auf einer channel laufen super toll Speicherbandbreite aus dem fenster geworfen und bei iGPU erst recht lustig.

[Windi]

Die Speichercontroller müssen doch irgendwie unabhängig sein. Sonst würde die Leistung einer CPU mit Dual-Channel völlig zusammen brechen, wenn man nur einen Speicherriegel verwendet. Oder wenn man in einem Speicherslot 8GB und in den anderen 4GB steckt.

Nvidia hat ja bei ihrer "berühmten" Grafikkarte auch 32bit (ein Speicherkanal) deaktiviert und deshalb nur noch 3,5GB anstatt 4GB zur Verfügung gehabt. Trotzdem ist die Leistung nicht zusammen gebrochen, solange man nicht mehr als 3,5GB benötigte.

[Setsul]

@amdfanuwe:
Sollte <1$ sein.
Rechne meinetwegen nochmal genau die Größe nach die man sich mit DDR4 statt GDDR6 Interface spart. Rechne dann den zusätzlichen Aufwand für DDR4 mit ein. Dann am besten noch höherer Stückpreis für GDDR6 weil die Menge sinkt.
Dann schau was übrig bleibt.
Niemand hat jemals GDDR durch DDR ersetzt weil der Chip mit GDDR-Interface zu groß geworden wäre.

@Brillus:
Dann erklär mir wie die 1080 Ti mit 352 bit funktioniert.
Oder wie Skylake mit 6 Channels funktioniert wenn nur 3 oder 4 bestückt sind.
Bei GPUs und CPUs mit Dutzenden Blöcken/Kernen die alle beschäftigt sein sollen runiert man sich die Bandbreite komplett wenn man alles interleaved.
Wenn man 20+ Threads oder noch viel mehr bei einer GPU hat die komplett zufällig im Speicher zumstochern dann will man nicht 8x Interleave. DDR3/4 haben schon 8n Burstlength bei 64 bit = 8 Byte gibt das 64 Byte Bursts. 2x Interleave so wie bei Dual Channel kann man verschmerzen weil meistens sowieso die nächsten Cache Line noch prefetched wird.
Aber 8x würde bedeuten wenn man nur eine einzige 64B Cache Line will muss man, weil die auf alle 8 Channels verteilt ist, von jedem Channel einen Burst lesen, also 8x64B. Weniger lesen geht nicht, nur mehr. Dann wird immer wenn weniger als 512B am Stück gelesen werden Bandbreite wirklich aus dem Fenster geworfen.

GDDR5 hat 8n, GDDR5X/GDDR6 16n, also 32/64 Byte pro 32 bit. Völlig überraschend bei 64/128B Cache Lines baut man dann auf den GPUs Memory Controller in 32 oder 64 bit Blöcken die dann auch getrennt abschaltbar sind.


GPU oder Server-CPUs sind in der Hinsicht völlig anders als eine 4C Desktop CPU. SKL-X ist so auf Gesamtbandbreite optimiert dass ein Kern nichtmal die halbe Bandbreite eines einzigen Channels kriegt. https://www.anandtech.com/show/11544/intel-skylake-ep-vs-amd-epyc-7000-cpu-battle-of-the-decade/12
Das akzeptiert man einfach weil wenn jemand nur einen Thread auf einer 28C/56T CPU laufen lässt macht er was falsch. Genauso ist es bei einer GPU auf der 20-80 Wavefronts/Warps laufen müssen bevor alle Ressourcen genutzt werden können und auf der im Idealfall mehr als 10 mal so viele laufen sollten. Wer da auf single thread optimiert verliert.

[Brillus]

@amdfanuwe:
Sollte <1$ sein.
Rechne meinetwegen nochmal genau die Größe nach die man sich mit DDR4 statt GDDR6 Interface spart. Rechne dann den zusätzlichen Aufwand für DDR4 mit ein. Dann am besten noch höherer Stückpreis für GDDR6 weil die Menge sinkt.
Dann schau was übrig bleibt.
Niemand hat jemals GDDR durch DDR ersetzt weil der Chip mit GDDR-Interface zu groß geworden wäre.

@Brillus:
Dann erklär mir wie die 1080 Ti mit 352 bit funktioniert.
Oder wie Skylake mit 6 Channels funktioniert wenn nur 3 oder 4 bestückt sind.
Bei GPUs und CPUs mit Dutzenden Blöcken/Kernen die alle beschäftigt sein sollen runiert man sich die Bandbreite komplett wenn man alles interleaved.
Wenn man 20+ Threads oder noch viel mehr bei einer GPU hat die komplett zufällig im Speicher zumstochern dann will man nicht 8x Interleave. DDR3/4 haben schon 8n Burstlength bei 64 bit = 8 Byte gibt das 64 Byte Bursts. 2x Interleave so wie bei Dual Channel kann man verschmerzen weil meistens sowieso die nächsten Cache Line noch prefetched wird.
Aber 8x würde bedeuten wenn man nur eine einzige 64B Cache Line will muss man, weil die auf alle 8 Channels verteilt ist, von jedem Channel einen Burst lesen, also 8x64B. Weniger lesen geht nicht, nur mehr. Dann wird immer wenn weniger als 512B am Stück gelesen werden Bandbreite wirklich aus dem Fenster geworfen.

GDDR5 hat 8n, GDDR5X/GDDR6 16n, also 32/64 Byte pro 32 bit. Völlig überraschend bei 64/128B Cache Lines baut man dann auf den GPUs Memory Controller in 32 oder 64 bit Blöcken die dann auch getrennt abschaltbar sind.


GPU oder Server-CPUs sind in der Hinsicht völlig anders als eine 4C Desktop CPU. SKL-X ist so auf Gesamtbandbreite optimiert dass ein Kern nichtmal die halbe Bandbreite eines einzigen Channels kriegt. https://www.anandtech.com/show/11544/intel-skylake-ep-vs-amd-epyc-7000-cpu-battle-of-the-decade/12
Das akzeptiert man einfach weil wenn jemand nur einen Thread auf einer 28C/56T CPU laufen lässt macht er was falsch. Genauso ist es bei einer GPU auf der 20-80 Wavefronts/Warps laufen müssen bevor alle Ressourcen genutzt werden können und auf der im Idealfall mehr als 10 mal so viele laufen sollten. Wer da auf single thread optimiert verliert.

Auch mit mehreren Threads kannst du einfach alles in einem channel haben. Und interleaving macht man naturlich nicht auf byte level sondern cacheline ebene. Und bei allen power of two channel anzahlen bekommt du es ganz einfach mit entsprechendem address bits hin.

[Setsul]

Wenn du im RAM alles so anordnest das alles in einem Channel liegt und der Rest leer ist kann man dir nicht helfen. Das wird auf keinem Server jemals passieren.

Wie gesagt erklär mir es außerhalb von Zweierpotenzen funktioniert. Das existiert offensichtlich.

Wenn du mit "nicht auf byte level sondern cacheline ebene" meinst dass jede Cache Line vollständig in einem Channel liegt dann redest du von etwas anderem als ich gedacht habe und ich verstehe dein Problem nicht. Die Cache Line hat eine Adresse (muss sie haben) und sie liegt in einem Block in einem einzigen Channel, damit sind die Channels völlig unabhängig voneinander.
Es kann Channel 2 egal sein welche Commands Channel 5 gerade schickt. Also kann man die auch getrennt abschalten.

Ob man noch Spielchen mit dem Mapping spielt ist egal. Welche Adresse zu welchem Channel gehört muss schon vorher bekannt sein weil man nicht einfach auf gut Glück an nur einen oder pauschal an alle MCs senden kann. Gerade bei GPUs wo der L2 Cache schon partitioniert ist muss der MC davon nicht unbedingt etwas sehen.

[Zossel]

Je nach Anwendung spielt es schon eine Rolle, wie schnell das System nach einem Reset wieder ans laufen kommt.
Bei 4MHz SPI Clock dauert es ca. 1 sekunde, bis 512 kByte übertragen sind.
Ist beim PC vertretbar.
Wie ins RAM kopieren? Der RAM wird ja erst durch den Code initialisiert.

Irgentwelche Mimiken wird es da schon geben, wahrscheinlich mehrere Boot-Stages.

Da es bei dem ACPI/UEFI Mist mittlerweile Calls aus dem OS in den ROM-Code gibt und es auch nicht maskierbare Interrrupts in den ROM-Code gibt würde die Performance und Latenz unterirdisch werden wenn den dieser immer aus dem SPI geladen würde. Auch lässt sich die Firmware während des Betriebes neu flashen, würde der Code direkt aus dem Flash ausgeführt würde die Kisten während des flashens unweigerlich abstürzen.

Hier ab Seite 30 findet sich was dazu, hab ich aber nicht gelesen: https://www.amd.com/system/files/TechDocs/48751_16h_bkdg.pdf
Andere CPUs ab hier: https://developer.amd.com/resources/developer-guides-manuals/

U. a. findet sich der folgende Satz in dem Link:
2.3.3Using L2 Cache as General Storage During Boot

Prior to initializing the DRAM controller for system memory, BIOS may use the L2 cache as general storage.If BIOS is not using L2 cache as general storage during boot, program MSRC001_102A[ClLinesToL2Dis]=0.



Sicherlich findet sich auch was in den Coreboot Sourcen zu dem Thema. Z.b. hier: https://github.com/pcengines/coreboot

[Zossel]

Macht keinen Sinn die sin 100% interleaved, sonst wurden 90%+ aller Anwendungen nur auf einer channel laufen super toll Speicherbandbreite aus dem fenster geworfen und bei iGPU erst recht lustig.

Die logischen linearen Adressräume die eine Anwendung sieht dürften schon nach recht kurzer uptime komplett verwürfelt im physikalischen Adressraum verteilt sein.

Allerdings bin ich bisher in meinen jugendlichen Leichtsinn davon ausgegangen das Interleaving heute normal wäre.

[Skysnake]

Also zumindest bei Server CPUs kann man das interleaving meist einstellen. Also pro Channel pro Sockel oder numa domain

[gravitationsfeld]

GPUs verwenden definitiv Channel-Interleaving. Die krummen Speicher-Interfaces werden wahrscheinlich mit verschiedenen Längen pro Controller realisiert. Ich wüsste nicht wie das anders gehen soll, sonst hätte man ja ohne Probleme ganze Render-Targets nur auf einem Kanal.

[MR2]

https://www.tweaktown.com/news/65560/amd-launch-next-gen-navi-graphics-cards-e3-2019/index.html

Wieder Mal am 7.7.

[Adam D.]

https://www.tweaktown.com/news/65560/amd-launch-next-gen-navi-graphics-cards-e3-2019/index.html

Wieder Mal am 7.7.
Das Datum erscheint logisch, dass Navi hingegen an der 2080 schnuppert, ist wohl ausgeschlossen.

[basix]

Radeon 7 oder R7 zum zweiten am 7.7.

Und der Ryzen 9 am 7.9.? :devil:

[AlterSack]

Das Datum erscheint logisch, dass Navi hingegen an der 2080 schnuppert, ist wohl ausgeschlossen.


Warum?

[MR2]

In dem Artikel steht ja "schlägt Vega64" und nähert sich der 2080 an.
Das bei wenig Stromverbrauch und gutem Preis und ich kaufe das Ding. Reicht mir für 1440p.

Wenn ich sehe wie sich die Vega56 im Gegensatz zu meiner Fury in Anno1800 macht, kann ich gerne verzichten und warten.

[Der_Korken]

Warum?

Realistisch gesehen müsste AMD ähnlich viele Transistoren in den Ring werfen wie Nvidia, also eine GPU an die 300mm² @7nm, also relativ teuer. Die Aussage, dass die VII die schnellste Karte in 2019 sein wird, dürfte wohl zutreffen, wenn auch nur knapp. Wenn Navi 10 die 2070 mit einer Mainstream-GPU erreicht, wäre das schon sehr gut. Es wäre auch nicht das erste Gerücht, das diese Leistungsklasse nennt.

[AlterSack]

AMD ist in Zugzwang. Wollen sie weiter mitspielen,
müssen sie was Effizientes bringen, sowohl was Energieverbrauch, als auch Flächenverbrauch angeht. Heisst, 200-250 mm² und 2080-Niveau,
denn das wird in 7nm der Mainstream werden. Von 250€ sollte man allerdings
auch nicht träumen. Denke, der Mainstream wird dann zwischen 300
und 350€ liegen.

[AlterSack]

Im Bereich bis 250€ wird uns wohl Polaris noch bisschen erhalten bleiben.

[Adam D.]

AMD ist in Zugzwang. Wollen sie weiter mitspielen,
müssen sie was Effizientes bringen, sowohl was Energieverbrauch, als auch Flächenverbrauch angeht. Heisst, 200-250 mm² und 2080-Niveau,
denn das wird in 7nm der Mainstream werden. Von 250€ sollte man allerdings
auch nicht träumen. Denke, der Mainstream wird dann zwischen 300
und 350€ liegen.
Ach und deshalb bietet man aktuell eine Radeon VII um die 700€ an. Is klar :freak:

[AlterSack]

Ach und deshalb bietet man aktuell eine Radeon VII um die 700€ an. Is klar :freak:

Die fällt nebenbei mit ab und reisst es für AMD auch nicht raus.
Die ist was für Spinner mit zuviel Geld. :freak:
...gerade wegen des Preises. Wenn sie Anteile erobern wollen,
muss was besseres her. ...2080-Niveau und < 150 Watt Verbrauch.
Dass dies nicht für 250€ zu haben sein wird ist mir auch klar.
Aber deutlich unter 400€ sollte es schon liegen.
Die Radeon VII wird im Consumerbereich wegfallen.

[amdfanuwe]

...2080-Niveau und < 150 Watt Verbrauch.
...
Aber deutlich unter 400€ sollte es schon liegen.

Wenn AMD die Leistungs- und Verbrauchswerte erreicht, gibt es die Karte erst für 400€ wenn Nvidia die 2080 für deutlich unter 400€ verkauft.

[Der_Korken]

AMD ist in Zugzwang. Wollen sie weiter mitspielen,
müssen sie was Effizientes bringen, sowohl was Energieverbrauch, als auch Flächenverbrauch angeht. Heisst, 200-250 mm² und 2080-Niveau,
denn das wird in 7nm der Mainstream werden.

Wunschdenken. 250mm² in 7nm wären in 12nm vielleicht irgendwas um die 400 bis 450mm², also nur knapp so groß wie TU106. Selbst wenn man sagt, dass TU104 ohne RT nur so groß wäre, müsste bei Navi schon alles absolut on point sein, um in die Nähe der 2080 zu kommen.

Wenn es gut läuft, bekommen wir einen ~220mm²-Chip mit 48 CUs@1,7Ghz und 10% Bonus durch Architekturverbesserungen bei 150W Gesamtverbrauch und 8GB GDDR6. Das wären 80-90% auf die 580, also etwa 2070 Niveau. Mal so blind ins Blaue geraten.

[Dino-Fossil]

Ganz klar 2080Ti+10% bei 100W und 200€, alles andere wäre ein Totalversagen :ugly:

Da die meisten Gerüchte für einen kleinen Chip sprechen und AMD in den letzten Jahren eher etwas niedriger heraus kam, gehe ich inzwischen von ca V56-V64 aus, bei 150-180W. Bezweifle, dass es viel besser wird als das, würde mir aber als Ersatz für meine 480 reichen, wenn der Preis passt.
Mal sehen.

[pilzsammler2002]

Ganz klar 2080Ti+10% bei 100W und 200€, alles andere wäre ein Totalversagen :ugly:

Da die meisten Gerüchte für einen kleinen Chip sprechen und AMD in den letzten Jahren eher etwas niedriger heraus kam, gehe ich inzwischen von ca V56-V64 aus, bei 150-180W. Bezweifle, dass es viel besser wird als das, würde mir aber als Ersatz für meine 480 reichen, wenn der Preis passt.
Mal sehen.

Da ist jede Vega 56 doch jetzt schon mit UV... :freak: :)

[DK999]

Das Datum erscheint logisch, dass Navi hingegen an der 2080 schnuppert, ist wohl ausgeschlossen.
Der 07.07. ist ein Sonntag.....

[Leonidas]

Spricht nominell dagegen ... aber da man nur einmal im Jahr einen 7.7. hat, konnte man wohl nur abwägen, was man da macht. Releveanter als Wochentage ist immer die Frage, ob der Termin mitten in einer Messe liegt. Die letzten Jahre gab es keinerlei Launches von Consumer-Produkten mitten in einer Messe. Macht sich einfach schlecht, weil die HW-Redakteure sich auch nicht aufteilen können.

[Dino-Fossil]

Da ist jede Vega 56 doch jetzt schon mit UV... :freak: :)

Nur veröffentlicht AMD keine Produkte mit UV.
Meine Polaris zieht auch einiges weniger dank UV und leichter Taktabsenkung, bei minimalstem Performance-Verlust.
Trotzdem entscheidet sich AMD immer wieder, ihre Chips nah an die Kotzgrenze zu prügeln.
Ich fürchte, das wird bei Navi nicht anders sein.

[BlacKi]

https://www.tweaktown.com/news/65560/amd-launch-next-gen-navi-graphics-cards-e3-2019/index.html

Wieder Mal am 7.7.
tut tuuut:biggrin:

[Daredevil]

.
Trotzdem entscheidet sich AMD immer wieder, ihre Chips nah an die Kotzgrenze zu prügeln.
Ich fürchte, das wird bei Navi nicht anders sein.
Solange UV als Volkssport betrieben wird und die Verkaufszahlen nicht extrem drunter leiden, gibts ja auch keinen Grund zum ändern.
AMD wird durch Vega UV ja nicht abgestraft, manche sehen das Potential ja sogar als großen Vorteil an, weil es the real Beast unleaeshed. :D ( und denken, dass das ein AMD exklusives Feature ist ... )

[Dino-Fossil]

Ich sehe das kritisch, zwar ist es eine schöne Spielerei für Bastler und erfahrene Nutzer, aber der Durchschnitts-Nutzer hat inzwischen leider oft verinnerlicht AMD=durstig, heiß & laut.
Marktanteile gewinnt man so nicht. Zumal AMD trotz mglw. vorhandenem undervolting-Potential nicht in der Lage ist, selbiges z.B. für Mobile selbst ordentlich zu nutzen.

[Leonidas]

Mit der aktuellen Generation war man vermutlich einfach drauf angewiesen, auf Kotzgrenze zu prügeln, weil es ansonsten das Performance-Ziel nicht erreicht. Um darauf verzichten zu können, müsste man mal wirklich grundlegend effiziente Chips haben.


Zurück zu Navi am 7.7.: Sofern die Performance-Prognose "grob RTX2070" wirklich passt, sehe ich gute Chancen für kleinere Navi-Chips nachfolgend. Weil die lohnt sich dann aufgrund von Effizienz und Neuheitswert zu bringen. Mittels Navi 12/14 könnte AMD dann vielleicht sogar mal was im Mobile-Segment reißen.

.|Ausrichtung|Technik|Terminlage|Status
Navi 10|Midrange|angen. 250-300mm² @ 7FF|Sommer 2019|ziemlich sicher noch in diesem Jahr erscheinend
Navi 12|mglw. Mainstream |angen. ~150mm² @ 7FF|mglw. Herbst/Winter 2019|sehr unsichere Informationslage
Navi 14|mglw. LowCost|angen. ~80mm² @ 7FF|mglw. Herbst/Winter 2019|sehr unsichere Informationslage
Navi 20|Profi & HighEnd|angen. ~350mm² @ 7FF+|2020|früher sicherlich geplant, aber seitdem nur selten erwähnt

[Dino-Fossil]

Hm, aber war Navi (ausgehend, dass der zuerst gelaunchte gemeint ist) nicht als flächentechnisch "etwas kleiner als Polaris" gehandelt?

Damit würde ich beim mittleren Navi eher von ca (210 +/-10)mm^2 ausgehen.
Was allerdings wohl auch wieder bestimmte Gerüchte zur Performance relativiert.
Naja, das Gerücht zur Größe könnte natürlich auch einfach falsch sein.

[Daredevil]

Große Fläche und wenig Takt = Kostenintensiv, aber effizient
Kleine Fläche und viel Takt = Kostensparsam, aber ineffizient
Ist halt nun die Frage, wie die Grundarchitektur aussieht, damit man sich für eins der beiden entscheiden kann. Den Mittelweg gibt es ja auch noch.

Es gibt mehrere Wege nach Rom. AMD muss den Chip nicht unbedingt winzig klein machen, wenn sie dank 7nm viele Einheiten unterbringen können. Dann könnten sie sich auch ein wenig von der "Kotzgrenze" entfernen, weil sie den Takt massiv hochschrauben müssen. Ist zwar ein Luxusproblem, merzt aber nun einmal das Stromaufnahme Argument schneller aus.

Die Radeon VII zeigt ja ganz gut, wie Navi nicht sein solle. Kleiner DIE, hoher Takt und durch den kleinen DIE halt ebenfalls eine sehr schwere Wärmeabgabe.

[Hakim]

Dafür das die erste Version demnächst kommen soll gibt es auffallend wenig Infos iwie. Damals bei Polaris gabs ja auch Monate vorher hier und da angebliche bench leaks

[Dino-Fossil]

Ich glaube das AMD seit dem Weggang von Koduri und der Umstrukturierung in der RTG deutlich vorsichtiger mit dem Pre-release Marketing geworden ist. Mit Polaris und Vega hatte man eine zu große Erwartung geschürt, die sie dann aber mit dem finalen Produkt nicht halten konnten.
Und Benchmark-Leaks sind in den letzten paar Jahren generell immer seltener geworden, die Hersteller sind da durch die Bank sehr vorsichtig.

[Blediator16]

Ich glaube das AMD seit dem Weggang von Koduri und der Umstrukturierung in der RTG deutlich vorsichtiger mit dem Pre-release Marketing geworden ist. Mit Polaris und Vega hatte man eine zu große Erwartung geschürt, die sie dann aber mit dem finalen Produkt nicht halten konnten.
Und Benchmark-Leaks sind in den letzten paar Jahren generell immer seltener geworden, die Hersteller sind da durch die Bank sehr vorsichtig.


Denke ich auch. Wenn man sich Intels neue PR anschaut, dann sieht man sofort, dass AMDs alte PR Garte dort am Werk ist. Seit Monaten wird über Intels neue GPU geredet und "bekannte" Influenzer eingelullt.

Bei AMD gab es zu R7 absolut nichts und die neuen Produkte, die bald kommen sollen, werden auch nicht gehyped. Bei Polaris wurde erheblich mehr Lärm gemacht.

[BoMbY]

Und wieder eine neue Runde von schlechten Gerüchten ...

Es wird innerhalb der nächsten drei Monate sehr wahrscheinlich keine Navi-Karte geben, da es immer noch keinen Linux-Patch gibt. Und am 7.7. wird es keine Veröffentlichung von irgendwas geben, aller höchstens irgendwelche Ankündigungen, aber auch das ist eher unwahrscheinlich.

Und was die Performance, etc. angeht, dürfte so gut wie niemand außerhalb von AMD auch nur die geringste Ahnung haben (jetzt mal von ehemaligen Mitarbeitern abgesehen, welche sich hüten werde da etwas von zu berichten).

[Daredevil]

Navi kommt mit Ray Tracing Support für die PS5.
https://www.wired.com/story/exclusive-sony-next-gen-console/

[Brillus]

Und wieder eine neue Runde von schlechten Gerüchten ...

Es wird innerhalb der nächsten drei Monate sehr wahrscheinlich keine Navi-Karte geben, da es immer noch keinen Linux-Patch gibt. Und am 7.7. wird es keine Veröffentlichung von irgendwas geben, aller höchstens irgendwelche Ankündigungen, aber auch das ist eher unwahrscheinlich.

Und was die Performance, etc. angeht, dürfte so gut wie niemand außerhalb von AMD auch nur die geringste Ahnung haben (jetzt mal von ehemaligen Mitarbeitern abgesehen, welche sich hüten werde da etwas von zu berichten).

Ne da kannst du nicht drauf gehen bei neuen Consumer karten sind die patches da immer sehr spät nicht selten erst mit der Veröffentlichung. Das hat Birdman schon mal geschrieben da werden sie extrem vom marketing zurück gehalten. Auserdem gbt schon power handling für den nächsten chip.

[Palpatin]

Navi kommt mit Ray Tracing Support für die PS5.
https://www.wired.com/story/exclusive-sony-next-gen-console/
Da alle DX12 fähigen AMD Karten RT können, ist das jetzt nichts besonderes.

[Daredevil]

Wenn ein Sony Entwickler gezielt mit einem Magazin darüber spricht, wird das wohl kaum ein „Schaut mal, Metro in 15fps, aber Raytracing“ werden.

[robbitop]

Ach naja im Vorfeld zur PS4/X1 hat man auch mit GPU compute geworben für Echtzeitphysik.
Das RT nunmal aktuell en vogue ist, und die HW es beherrscht, warum nicht erwähnen? Wenn man es gezielt und sparsam einsetzt, ist es ja auch machbar. Kein festes Indiz für dedizierte RT HW IMO.

[Unicous]

Wenn ein Sony Entwickler gezielt mit einem Magazin darüber spricht, wird das wohl kaum ein „Schaut mal, Metro in 15fps, aber Raytracing“ werden.

Das ist nicht irgendein "Entwickler" das ist der Lead (Hardware) Architect der PS4 (und PS Vita).:freak: (Und natürlich der "PS5";))

[AlterSack]

[QUOTE=Daredevil;11972901
Die Radeon VII zeigt ja ganz gut, wie Navi nicht sein solle. Kleiner DIE, hoher Takt und durch den kleinen DIE halt ebenfalls eine sehr schwere Wärmeabgabe.[/QUOTE]

...kleiner DIE... ;D

[Daredevil]

Naja... groß isser nun auch nicht.

2080ti 754 mm²
2080 545 mm²
Vega64 495 mm²
1080ti 471 mm²
2060 445 mm²
VII 331 mm²
RX590 232 mm²

AMD wird schon gewusst haben, wieso sie auf ein neues Referenz Design wechseln. Wir dachten zwar erst, dass würde die Karte abrunden und das Gesamtpaket attraktiver darstellen lassen, aber mit nem V64+Radi wär das Ding vermutlich total gestorben. Der DIE ist halt im Vergleich wirklich klein, für das was er leistet und für das, was er verbrauchen soll.

[AlterSack]

Dafür dass der NV-Kram in 12nm ist und VII in 7nm
isser schon recht gross. Zumal wenn man bedenkt was seine
Vorgänger in groberen Prozessen maßen.

[Daredevil]

Darum gehts doch in meiner Aussage überhaupt nicht.
Kleinere DIEs sind einfach schwerer zu kühlen. Völlig egal, ob das nun 5nm, 7nm oder 12nm ist. Wenn da 300 Watt abgeführt werden möchten, gewinnt nicht der Fertigungsprozess, sondern eben die Fläche.
Und in der Hinsicht ist die Radeon VII halt einfach sehr klein bei der Fläche und TDP.

[HOT]

Jetzt wo klar ist, dass die PS5 RT beherrscht stellt sich natürlich die Frage ob nicht die gesamte Navi-Serie RT beherrscht. Das würde ja auch zu Lisas Aussage passen, dass man RT erst unterstützen wird, wenn man das von Unten bis Oben hinbekommt. Das wär bei Navi ja der Fall. Das und die Tatsache, dass der SoC sowieso 64CUs abbekommen wird, der er sonst die erforderliche Rechenleistung ja gar nicht bringen kann, läd natürlich zu neuen Spekulationen ein.

N10
64 CUs, 2 HBM Stacks mit 2,4 oder 3,2 GHz (16GB), 330-360mm²
N12
~36 CUs, 192 Bit GDDR6 (12GB), 180-220mm²
N14
~20 CUs, 128 Bit GDDR6 (4-8GB), 100-120mm²
N20
N10-Refresh in N7+ oder N6, evtl mit 4 Stacks, wie V20.

[Zergra]

N12 und 14 kann ich mir so auch noch vorstellen, N10 dann Anfang 2020.

[HOT]

Nene, die werden mit N10 im Sommer starten. Leo hat da schon recht auf seiner Hauptseite. Der Start mit N10, dann N12 und N14 gestaffelt im Herbst. N20 ist dann sicherlich ein Refresh in N6FF mit Profigedöns, so wie V20. All diese Chips sind sicherlich inklusive Renoir in N7FF gefertigt.

N10 ist jetzt Performance bis High-End (so wie Vega eben), N12 sicherlich im Performancebereich. Für Mainstream gibts dann N14. N10 ersetzt V64-VII (also zwischen 2060 und 2080), N12 ist dann zwischen 1660 und 2060 und N14 darunter. Noch weiter runter gehts dann mit Renoir und Picasso. P12 wird man für OEMs sicherlich auch im Programm behalten. Ob man N20 dann in den Desktop bringt, wird man sehen, könnte man sicherlich bis zur 2080Ti mit auffüllen, je nachdem wieviel sich da noch rausholen lässt, denn über 64CUs ist unwahrscheinlich, war bei V20 ja auch nicht der Fall.
NV wird aber sicherlich auf N6FF oder N5FF (oder Samsung Äquivalente) anpeilen, da kommt dann sicherlich auch was.

Navi ist im Grunde sowas wie Cayman war. Das war das VLIW-Finale, das nochmal stark verbessert wurde, bevor man auf GCN umstieg. Der Aufwand für diese Chips war sicherlich ebenfalls recht groß, die VLIW-Architektur nochmals in neue Effizienzhöhen zu heben, man hatte nur etwas pech, dass TSMC damals den 32nm-Prozess cancelte.

[Linmoum]

AMD wird erst dort ansetzen, wo es Marktanteile gibt. Und das ist Navi im Mainstream. Schlicht unnötig, jetzt schon High-End zu bringen, nachdem Polaris im Sommer über drei Jahre am Markt ist. Das braucht dringend eine schnelle Ablösung in dem Markt, wo sich die mit großem Abstand meisten Käufer tummeln.

[BlacKi]

warum sagt man navi zu das er RT kann? warum kann vega und polaris nicht RT? es ist doch teil von dx12?

[dildo4u]

Spekulation da die PS5 RT Support hat,Sony kann aber bei AMD anfragen welche Features sie haben wollen.(Custom Abteilung bei AMD)
Die PS4 Pro unterstützt z.b FP16 obwohl das Polaris nicht kann.

[rentex]

Würde sich aber anbieten..

[dildo4u]

Nicht zwangsweise für 2019,7nm wird in 2020 deutlich billiger sein daher macht der Support für die PS5 Sinn.
Die Frage ist welche Preispunkte sie 2019 mit Navi abdecken wollen.

[rentex]

Dachte auch eher für 2020 oder Navi Nachfolger.

[Dino-Fossil]

Da aktuell wohl davon ausgegangen wird, dass die PS5 erst Ende 2020 kommt, könnte Navi 2019 durchaus ohne Hardware-RT kommen. Würde da noch nichts als wirklich gesichert annehmen.

[HOT]

PS5 wird wohl Q3 kommen. XBox ist weiterhin unbekannt, aber sicherlich auch 2.HJ 2020. Da der Grafikchip in der PS5 offenbar N10 lite heißt, dürfte RT kein Hexenwerk für PC-Navi sein. Ich denke mal, dass RT für die komplette Serie kommt.

[cat]

Turing hat ja 1x RT-Core je 64 FP32 ALUs

GCN hat ja immerschon 64 ALUs je Compute-Unit

Haltet ihr es für möglich, dass Navi eine derart starke Veränderung wie RT-Hardwarebeschleunigung in oder an die Compute-Units gesetzt bekommt ?

Generell ist das kein grober Verstoß gegen die GCN ISA.
Also ziemlich abwärtskompatibel.

Also eine besser auf 7nm optimierte Vega mit RT-Beschleunigung.

[BoMbY]

Die verlässlichen Informationen zu Navi lassen sich in ein oder zwei Sätzen zusammen fassen, trotz 106 Seiten Spekulation und Gerüchten. Aus meiner Sicht ist noch so ziemlich alles möglich.

[Brillus]

Bzgl. RT ist meine Vermutung, das es keine RT Einheiten gibt. Die Aussage hießt die next gen Konsole unterstützt RT. Das heißt nicht dass sie extra Einheiten dafür hat, Crytek hat doch auch schon RT auf Vega56 gezeigt.

[Unicous]

Bzgl. RT ist meine Vermutung, das es keine RT Einheiten gibt. Die Aussage hießt die next gen Konsole unterstützt RT. Das heißt nicht dass sie extra Einheiten dafür hat, Crytek hat doch auch schon RT auf Vega56 gezeigt.

:rolleyes:


Boon Cotter
Lighting artist @Naughty_Dog

Hardware ray tracing. That is all.

https://twitter.com/booncotter/status/1118285369865162752

Full disclosure
It seems some folks have picked up this tweet as some kind of inside confirmation of anything at all, which it isn't. I assumed it's hw cos we can already do sw ray tracing (albeit glacially). *Jedi voice* I am not the source you're looking for.
https://twitter.com/booncotter/status/1118347596924198915

Fazit bleibt dennoch. "Software" RT geht schon seit Ewigkeiten, es ist Hardware-basiert, alles andere macht keinen Sinn.

[Der_Korken]

Hardware Raytracing muss ja nicht heißen, dass es dedizierte Einheiten dafür gibt. Wenn man extra Logik einbaut, um Dreieck-Strahl-Schnittpunkte in normalen ALUs in weniger Takten zu berechnen, wäre die Bezeichnung "Hardware RT" nicht falsch, auch wenn man von Nvidias Implementierung weit entfernt ist.

[reaperrr]

Es gab schon um die Vorstellung von RTX herum die etwas schwammige Aussage, dass MS, Sony und AMD (was übrigens auch damals schon als implizite Bestätigung dafür gesehen werden konnte, dass beide NextGen-Konsolen wieder auf AMD setzen werden) "einen anderen Ansatz" verfolgen würden.
Das heißt nicht automatisch "Software" oder der Crytek-Ansatz, sondern einfach, dass es nicht wie bei NV eine dedizierte RT-Einheit pro CU sein wird.

Ob sie das dann bedeutet, dass AMD das über die normalen Shader-Einheiten laufen lassen (und diese entweder dafür aufgebohrt haben oder einen Weg gefunden haben, die Last von RT-Berechnungen anderweitig deutlich zu reduzieren), ob einfach die RT-Einheiten geballt im Frontend sitzen, oder es noch was ganz anderes gibt, muss man abwarten.

[Brillus]

:rolleyes:



https://twitter.com/booncotter/status/1118285369865162752

Full disclosure

https://twitter.com/booncotter/status/1118347596924198915

Fazit bleibt dennoch. "Software" RT geht schon seit Ewigkeiten, es ist Hardware-basiert, alles andere macht keinen Sinn.
Zumindest in Wired Artikel war nichts von HW Einheiten zu lesen.
Ich habe keine Ahnung wie zuverlässig deine Quelle ist.

[Felis silvestris]

Ich bin zwar keine Expertin aber was würde wirklich gegen "echte"? Hardwarebeschleunigung für Raytracing bei der PS5 sprechen? AMD? :biggrin: Mal im Ernst: DirectX 12 RT als Basis für RTX ist ja nicht vom Himmel gefallen. Mimisoft hat sicher eine Weile gebraucht das zu entwickeln und das ging sicher nicht nur in Absprache mit den "Grünen". So etwas wurde länger vorbereitet und daher wird man bei AMD nicht aus allen Wolken gefallen sein als NV mit der RTX 20X0 ankam.

Also wurde schon länger darüber nachgedacht. Da die Spielstationen ihre eigene API haben, muss die GPU ja auch nicht zwingend DirectX 12 RT beschleunigen. Sie könnte stattdessen auch andere Techniken nutzen. Ich glaube nicht das Sony in 2020 mit reinen Software Raytracing kommt. Vielleicht wird nur eben "anders" gearbeitet, möglicherweise ähnlich der Cryengine. Und diese dann eben hardwarebeschleunigt.

Bein Grafikkarten für den PC ist natürlich DirectX12 Pflichtprogramm. Aber selbst eine Radeon mit hardwarbeschleunigtem RT wäre ja nicht "RTX" kompatibel weil nVidia da ja auch ein wenig mit Gamelworks und Co. ihr eigenes Süppchen kochen. Also gut denkbar das man dann nach FreeSync eben mit OpenRaytracing oder sowas kommt. Und in dem Zuge auch Erfahrungen mit der PS5 mit einbringt (soweit es "So nie!" erlaubt).

[pixeljetstream]

Es gibt kein RTX aus API/Entwickler Sicht. Es gibt DXR und dann irgendwann die standardisierte Version für Vulkan und das reicht den Entwicklern. Das ist imo schon "Open" genug.
Ob und wie andere Effekte wie dlss genutzt werden ist komplett unabhängig.

Ich kenne die Timeline wann wer von was wußte (das Preview von dxr ist ja schon Jahr her) und gehe auch von bissl HW aus. Minimum wäre ISA für die Box/tri Tests für besseren Durchsatz/Energie-effizienz. Evtl aber eben auch mehr.
Man kann auch andere compute features mit RT motivieren die man sonst vielleicht nicht gemacht hätte.
Was ich spannend finde ist das Sony ja meist viel selbst macht (API, Treiber, Compiler, Tools...). Die lassen sicher nix anbrennen.

[=Floi=]

ok, sony macht support, aber wird die amd hardware auch nutzbar sein im sinne von spielbaren fps und echter beschleunigung und keinem pseudo emulator?!
Das feature ist ja bei nv noch nicht mal perfekt und amd hat noch genug andere baustellen.

Ehrlich gesagt reicht es bei der übernächsten gen noch immer dicke aus, wenn games vorhanden sin, sich die nutzbaren rays und die software eingelaufen haben und es auch optisch mehr bringt.
Viel wichtiger wäre ein richtig gutes frontend, damit man die vorhandene und zukünftige breite des chips voll auslasten kann. Darin sehe ich viel mehr potential.
Das ist noch immer die größte baustelle bei amd.
Neue architektur für die nächsten 5 jahre!

Checkerboard ist auf dem pc ebenfalls nicht vorhanden...

[pixeljetstream]

=Floi= imo was wir bisher am PC sahen waren die ersten Gehversuche mit neuer API in einem "worst-case" Szenario, sprich die Technik auf anspruchsvolle Themen schmeißen innerhalb Engines die eigentlich andere Technik zur Grundlage haben.
Da auf der Konsole die Abstraktion (die DXR/VKRay haben) fast wegfällt, kann der Entwickler derartige Features viel leichter als Werkzeug zusammen mit anderen Mitteln einsetzen.
Am PC ist das (selbst für NV) bewusst nicht möglich weil das Interface viel mehr Spielraum für unterschiedliche Herangehensweisen lassen muss (High-Level um sich nicht Ausversehen die Zukunft zu verbauen, bzw. andere Hersteller müssen auch untergebracht werden). Und weil es für Entwickler nicht wirtschaftlich wäre für zig Architekturen jeweils ein Optimum zu finden.

Jemand wie Sony/Nintendo kann für sich viel engere Grenzen bei der Abstraktion um die Hardware ziehen, weil sie die Feature ja konkret einkaufen, bzw. selbst Technologie beisteuern und durch ihre Studios ja auch noch den content selber liefern.

[Käsetoast]

Ich bin zwar keine Expertin aber was würde wirklich gegen "echte"? Hardwarebeschleunigung für Raytracing bei der PS5 sprechen?
In meinen Augen schlichtweg das Geld. Der Preisrahmen so einer Konsole ist ja bekannt. Wir sehen auch wie "gut" eine 2080 Ti die mal für 1250 € alleine über den Tresen gewandert ist Raytracing genutzt kriegt über explizite Recheneinheiten, die nur für RT da sind. Da sieht es in Spielen wie Battlefield 5, die das nennenswert nutzen, von der Performance her aber nur mäßig aus und das in Full HD. Die Konsolen sind aber selbst als Gesamtpaket weit von den Preisen einer 2080 Ti entfernt, könnten also wenn auch sie RT Recheneinheiten bieten wollen nur einen Bruchteil davon haben können aus finanzieller Sicht und schon ist das Thema eigentlich gegessen - zumindest für die anstehende Konsolengeneration. Außerdem brauchen die Konsolen an sich primär erstmal mehr Dampf auf der Rasterizing Seite des Renderings, denn 4k ist ja auch ein Ding und da pfeifen auch die nachgeschobenen Pro Versionen schon lange auf dem letzten Loch bzw. in den meisten Fällen reicht der Dampf nicht für 4k. Man hat da halt den Mund ziemlich voll genommen, 4k ist auch bei den Fernsehern ein Thema und auch abseits von diesem Aspekt gibt es noch das Thema VR das dringend mehr Rechenleistung braucht um auch hier hübschere Grafiken zu ermöglichen...

Aus diesem Grund wird aus meiner Sicht RT hier ziemlich rausfallen. Kann natürlich sein, dass AMD da einen Weg findet, um RT Berechnungen auf Rasterizing Recheneinheiten effektiver zu machen. So könnte man wohl auch begrenzt RT auf den Konsolen betreiben, allerdings bei weitem nicht in dem Umfang wie es bei NVIDIAs RTX Programm proklammiert wird. So gesehen denke ich, dass wir genau das bei Navi sehen werden. Ich denke AMD hatte bei der Chipentwicklung genug Baustellen einen vernünftigen Gamer Chip zu bauen, der gegenüber der Konkurrenz nicht abstinkt was die Performance angeht oder total am Limit laufen muss...

Ideal wären für Navi halt Vega 64 Leistung, vielleicht sogar leicht darüber zum Polaris Preis bei im Vergleich wenig Verbrauch. Wenn man statt dem Vega Computing-Gaming-Kompromiss wieder einen richtigen Gaming Chip baut, man endlich was mehr Manpower reingesteckt hat und dann auch noch den 7nm Prozess nutzt wäre ein Polaris Nachfolger mit Vega 64 + 10% Leistung nicht total unrealisitsch denke ich. Auch am derzeitigen Markt stünde man da nicht schlecht da und ich glaube den 7nm Konter von NVIDIA sehen wir erst gegen Mitte 2020, so dass man da für knapp ein Jahr ein gutes Eisen im Feuer hätte, das hier und da sogar attraktiver wäre als NVIDIAs Turing non-RT Verwurstung...

Da oben drauf dann vielleicht noch irgendeine Anpassung, die RT Berechnungen gegenüber den derzeitigen Lösungen etwas beschleunigt und das wäre ein guter Anfang wie ich finde. Wir werden sehen was die kommenden Wochen so zu bieten haben...

[pixeljetstream]

Käsetoast, das was du als "Anpassung welche die RT Berechnungen beschleunigt", ist ähnlich dem was auch die RT-cores bei NV machen. Sie machen ja nicht alles was irgendwie mit raytracing zu tun hat. Ein Spiel was heute rasterization nutzt, braucht die dafür spezialisierten Einheiten kaum im Vergleich zum Rest der für die shader Ausführung zuständig ist. Sorry wenn ich da bissl kleinlich bin und vielleicht meinst Du das gleiche, aber manchmal entsteht der Eindruck als wäre alles sehr zweckgebunden.

[Käsetoast]

Worauf ich hinaus wollte war, dass man vielleicht guckt wo in den Rasterizer Einheiten sozusagen der Flachenhals sitzt wenn man darüber Raytracing laufen lässt und man investiert dann dort gezielt Transistoren, um das was flotter zu machen. Sind dann keine Riesensprünge, aber wenn sich da ein guter Ansatzpunkt finden lässt wäre man besser als alle anderen GPUs ohne diese Optimierung, was immerhin etwas wäre. Also der Versuch einer internen Optimierung im Compute Bereich wie ich es jetzt einfach mal nenne, anstatt da auf dem DIE einen Bereich mit extra für RT Berechnungen ausgelegten Recheneinheiten wie NVIDIA es macht hinzuzufügen...

[Mangel76]

Hier vom Preisniveau einer 2080Ti auszugehen, ist leider völlig falsch. Die 1200€ sind eine Kombination aus Monopolzuschlag für Nvidia, Early-Adopter Aufschlag für RT sowie Nerdzuschlag für die schnellste Karte (+50% für +25%Leistung). Dies hat alles keine Bedeutung für die Preisbildung eines Konsolenchips. Zudem rechnet man mit einem Durchschnittspreis über einen längeren Zeitraum, in dem sich die Fertigung noch verbilligen wird. Wenn man vom Preis der Ti ausgehen wollte, würde auch bei der PS5 nicht mehr als Polarisniveau herauskommen. Rein von der Fertigung soll doch der Flächenverbrauch für RT gar nicht so viel größer sein. Und letztlich zählt nur das für den Preis.Fragt sich auch, ob AMD einen ähnlichen Weg geht, oder doch einen ganz anderen.

[pixeljetstream]

"Compute oder Shading Leistung" klingt besser als "Rasterizer Einheiten" und ist auch korrekter, darauf wollte ich hinaus.

NV hat auch seine SMs (über die alles Shading, Compute oder Grafik läuft) um diesen RT core erweitert, so dass er sich in die normale Architektur einfügt, wie andere Einheiten auch (ALU, TEX etc.). Die Transistoren dafür sind also schon nah dran. Wieviel Aufgaben diese Instruktionen übernehmen ist dann halt Design Entscheidung.

[horn 12]

Das Event für Navi, Zen 2 ist ja schon um, aber durchgesickert ist zwecks NDA so gut wie nix.

[BoMbY]

Gab es wirklich ein Event, oder war das nur heiße Luft? Ich hab nichts entsprechendes gesehen.

[Dino-Fossil]

War doch nur ein Briefing für die AMD-Partner, ohne Presse o.ä, also wohl ein sehr überschaubarer Personenkreis.
Bis da was nach außen dringt, wird es sicherlich noch ein bisschen dauern.

[HOT]

Ich bin zwar keine Expertin aber was würde wirklich gegen "echte"? Hardwarebeschleunigung für Raytracing bei der PS5 sprechen? AMD? :biggrin: Mal im Ernst: DirectX 12 RT als Basis für RTX ist ja nicht vom Himmel gefallen. Mimisoft hat sicher eine Weile gebraucht das zu entwickeln und das ging sicher nicht nur in Absprache mit den "Grünen". So etwas wurde länger vorbereitet und daher wird man bei AMD nicht aus allen Wolken gefallen sein als NV mit der RTX 20X0 ankam.

Also wurde schon länger darüber nachgedacht. Da die Spielstationen ihre eigene API haben, muss die GPU ja auch nicht zwingend DirectX 12 RT beschleunigen. Sie könnte stattdessen auch andere Techniken nutzen. Ich glaube nicht das Sony in 2020 mit reinen Software Raytracing kommt. Vielleicht wird nur eben "anders" gearbeitet, möglicherweise ähnlich der Cryengine. Und diese dann eben hardwarebeschleunigt.

Bein Grafikkarten für den PC ist natürlich DirectX12 Pflichtprogramm. Aber selbst eine Radeon mit hardwarbeschleunigtem RT wäre ja nicht "RTX" kompatibel weil nVidia da ja auch ein wenig mit Gamelworks und Co. ihr eigenes Süppchen kochen. Also gut denkbar das man dann nach FreeSync eben mit OpenRaytracing oder sowas kommt. Und in dem Zuge auch Erfahrungen mit der PS5 mit einbringt (soweit es "So nie!" erlaubt).


Wenn man noch weiter spekuliert könnte DXR ursprünglich auch gar nichts mit NV zu tun gehabt haben, sondern könnte auch einfach auf Microsofts Initiative für die nächste Konsolengeneration zurückgehen. Damit wäre MS die federführende Kraft hinter RT und NV hat Volta einfach nur nachträglich angepasst (so wie Maxwell2 auf DX12 nachträglich angepasst wurde), als MS diese Pläne an die Hardwarehersteller weitergegeben hat. Vielleicht war sogar AMD als Konsolenhardwarehersteller da schon seit 2015 mit im Boot, also u.U. viel früher als NV. Ich hab mich schon gewundet, dass man bei RT jetzt plötzlich mit "offenen" Standards anfängt und nicht mit irgend nem proprietärem Mist, wie sonst immer.


Wenn man sowas alles bedenkt und das RT diese Konsolengeneration ihren Durchbruch haben wird, ist es schon extrem wahrscheinlich, dass Navi sogar sehr starke Eingriffe in die Architektur hat für RT.

[Brillus]

Die ersten Patches für den Navi OpenSource Support sind aufgetaucht. Genauer für LLVM.

https://www.phoronix.com/scan.php?page=news_item&px=Open-Source-Navi-GFX1010

[Mr.Scott]

Jemand eine Ahnung wie es um den PCIe 4.0 Support bei Navi aussieht?

[Käsetoast]

Wenn man noch weiter spekuliert könnte DXR ursprünglich auch gar nichts mit NV zu tun gehabt haben,
[...] Damit wäre MS die federführende Kraft hinter RT und NV hat Volta einfach nur nachträglich angepasst (so wie Maxwell2 auf DX12 nachträglich angepasst wurde)
Ich denke schon, dass NVIDIA da die treibende Kraft ist / war. Die haben eben schon lange darauf hin gearbeitet, in den Markt für professionelles Rendering & Co hineinzukommen. Da ist Turing ja auch vollkommen drauf ausgelegt. RT an sich geisterte was Realtime Anwendungen angeht ja eh schon immer in der Industrie herum und gerade Intel hat da ja auf kleiner Flamme immer was köcheln gehabt (man denke an die ganzen RT Versionen der diversen Quake Spiele). Mit NVIDIA, die planen da richtig Power reinzustecken wird dann eben der Stein des Anstoßes gegeben worden sein, da für die Realtime Anwendung eine allgemeine API etc. auf die Beine zu stellen. Das wird sich hinter verschlossenen Türen bei allen in der Branche irgendwo abgezeichnet haben. Wie früh man da dann einsteigen will ist dann jedem wohl freigestellt gewesen. Ich sehe da für Konsolen aber keine lohnende Anwendung zum jetzigen Zeitpunkt und auch bei Navi nicht wirklich. Wir haben mit Turing gesehen wieviel Power man braucht bzw. wieviele Gigarays & Co nötig sind um damit bei FullHD Auflösung was ansehnliches auf die Beine zu stellen. So eine Raytracingleistung auf den Konsolen bereitzustellen ohne dass man die Leistung der Rasterizing Grafik merklich beschneidet sehe ich da nicht. Gerade die Konsolen dürsten nach mehr "normaler" Grafikleistung für 4k Auflösung, VR und eben eine schönere Grafik im Hinblick auf Geometriedetail, Texturauflösung und so weiter. Für kleine Spielereien kann man mit RT sicherlich was machen, aber ich denke das was NVIDIA mit ihrem RTX Programm werbeträchtig in Aussicht gestellt hat ist in dem Umfang für Konsolen einfach noch nicht machbar. Man könnte natürlich jetzt die Grundlagen legen um dann in 3 Jahren mit einer Pro Version der Konsolen auch eine ansehnliche Raytracing Leistung zu bieten, aber viel mehr wird denke ich nicht passieren.

Von daher ist Raytracing für Navi an sich sicherlich irgendwo ein Thema, aber ich sehe nicht, dass AMD da einen so starken Fokus drauf legt wie NVIDIA. AMD muss jetzt zuerst mal wieder einen konkurrenzfähigen Chip bringen, der gerade in Punkto Effizienz aufholt und der eher nicht mehr mit starken Ergebnissen bei Crypto Mining oder sonstigen Compute Anwendungen aufwarten kann, sondern endlich beim Gaming nochmal richtig gut Leistung auf die Straße bringt...

[HOT]

Aber genau das passiert doch, die neuen Konsolen können RT. Ich glaube, dass NV hier nur Opportunist gewesen sein könnte. Für Konsolen macht man ja nichts halbgares, sondern was, was Hand und Fuss hat. Das muss ne runde Lösung sein.
So ne Konsolenentwicklung dauert 5 Jahre. Die werden das kurz nach der Fertigstellung der letzten Generation konzeptioniert haben, also muss da RT schon ne wichtige Rolle gespielt haben, denn das ist ja ein Kernfeature. Das ist in jedem Fall weit vor Turing. Man darf nicht vergessen, 2015 hat NV noch mit Volta geplant und GV100 hat kein RT!

Natürlich nutzt man das jetzt weidlich aus, warum auch nicht. Für den Profimarkt ist das ein gefundenes Fressen. Aber nochmal, wenn das früher geplant gewesen wäre, hätte GV100 etwas weniger Shader und dafür RT und es gäb auch ne proprietäre Schnittstelle dafür, das halte ich für absolut plausibel. Ich wette, dass die Volta-GPU-Generation das ist, was jetzt die 1660er sind. Das war in der Form sicherlich nach oben hin geplant, bis 5376 Shader (in 10nm?).
Nun ja, es bleibt natürlich Spekulation, aber das überlass ich jeden selbst. Das sind ja Sachen, die man im Nachhinein nie erfahren wird.

[BoMbY]

Die ersten Patches für den Navi OpenSource Support sind aufgetaucht. Genauer für LLVM.

https://www.phoronix.com/scan.php?page=news_item&px=Open-Source-Navi-GFX1010

Ja, und es scheint auf jeden Fall ein paar mehr Änderungen zu geben. Der wird glaube ich noch nicht erwähnt: https://reviews.llvm.org/D61080

Edit: Scheint auch das erste mal zu sein seit GFX6 das ein neues "Speed Model" benötigt wird (GFX10SpeedModel) mit geänderten Latenzen.

[mczak]

Ich sehe vor allem einen Haufen neuer Bugs :tongue:.
Aber da stehen die Chancen dann wohl gut dass da tatsächlich die Architektur ordentliche Aenderungen hat.
So auf einen Blick am interessantesten scheint mir dieses neue Feature:
FeatureCuMode "Enable CU wavefront execution mode" - aber keine Ahnung was das tun soll :biggrin:.

[BoMbY]

Interessant finde ich persönlich eher das "register banking" und den "register destination cache".

Aber da kommen noch mehr Patches so wie es aussieht:

https://reviews.llvm.org/D61099

https://reviews.llvm.org/D61094

[N0Thing]

Aber genau das passiert doch, die neuen Konsolen können RT. Ich glaube, dass NV hier nur Opportunist gewesen sein könnte. Für Konsolen macht man ja nichts halbgares, sondern was, was Hand und Fuss hat. Das muss ne runde Lösung sein.

Wenn AMD die Triebfeder hinter der RT-Entwicklung gewesen wäre, hätte man sich doch nicht von Nvidia über Monate die Butter vom Brot nehmen lassen.
Und wenn die RT-Leistung der aktuellen Turing-Generation kritisiert wird, kann man doch wohl nicht ernsthaft bessere RT-Ergebnisse in einer 400-500€ Konsole erwarten.

[Locuza]

Ich sehe vor allem einen Haufen neuer Bugs :tongue:.
Aber da stehen die Chancen dann wohl gut dass da tatsächlich die Architektur ordentliche Aenderungen hat.
So auf einen Blick am interessantesten scheint mir dieses neue Feature:
FeatureCuMode "Enable CU wavefront execution mode" - aber keine Ahnung was das tun soll :biggrin:.
Klingt auch relativ nichtssagend.
Es gibt ein Patent von AMD bezüglich Variable Wavefront Sizing, wo auch unterschiedliche Umsetzungen genannt werden, ich habe es mir nicht durchgelesen, aber eine Form spricht von einem normalen Modus wo eine Instruktion auf 64 work items wie bisher angewendet wird und einem second mode, wo eine Instruktion für eine portion der wavefront ausgeführt wird z.B. 32 work items und für die weitere(n) Portion(en) schon die nächste Instruktion.

Patent:
https://patentimages.storage.googleapis.com/c7/90/a1/23f99d6a7a251a/WO2018156635A1.pdf

[HOT]

Wenn AMD die Triebfeder hinter der RT-Entwicklung gewesen wäre, hätte man sich doch nicht von Nvidia über Monate die Butter vom Brot nehmen lassen.
Und wenn die RT-Leistung der aktuellen Turing-Generation kritisiert wird, kann man doch wohl nicht ernsthaft bessere RT-Ergebnisse in einer 400-500€ Konsole erwarten.
Wer redet denn von AMD? Ich sage, dass Microsoft (und auch Sony) die Triebfeder war. Und klar kann man das. Turing Apfel -> Konsole Birne.

[danarcho]

Also, GCN confirmed und sogar das instruction encoding ist größtenteils wie es aussieht sogar komplett gleich geblieben! Und jetzt alle Post-GCN-Träumer mal die Klappe halten, bitte :)

Ich frag mich, was der neue VSCNT zählt

[Gipsel]

Ich frag mich, was der neue VSCNT zähltVector Store CouNT;)

[DrumDub]

Also, GCN confirmed und sogar das instruction encoding ist größtenteils wie es aussieht sogar komplett gleich geblieben! Und jetzt alle Post-GCN-Träumer mal die Klappe halten, bitte :)
das navi die letzte iteration von GCN sein wird, war doch eigentlich jedem halbwegs interssierten schön länger klar. zuletzt gabs träumereien bzgl. was anderem vielleicht vor einem jahr oder so ...

[BoMbY]

Die könnten nach den Patches immer noch relevant sein:

http://www.freepatentsonline.com/y2018/0121386.html

http://www.freepatentsonline.com/y2018/0144435.html

http://www.freepatentsonline.com/y2018/0239606.html

Register Banking, Destination Cache, etc ...

[Mr.Scott]

Jemand eine Ahnung wie es um den PCIe 4.0 Support bei Navi aussieht?

[danarcho]

Vector Store CouNT;)
Meinst, die haben jetzt VMEM load-store decoupled?

das navi die letzte iteration von GCN sein wird, war doch eigentlich jedem halbwegs interssierten schön länger klar. zuletzt gabs träumereien bzgl. was anderem vielleicht vor einem jahr oder so ...
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11949689&postcount=1690
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11949756&postcount=1692
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11949765&postcount=1694
Ja ne, wir sprechen uns dann in einem Jahr nochmal.

Die könnten nach den Patches immer noch relevant sein:

http://www.freepatentsonline.com/y2018/0121386.html

http://www.freepatentsonline.com/y2018/0144435.html

http://www.freepatentsonline.com/y2018/0239606.html

Register Banking, Destination Cache, etc ...
Das ist doch tatsächlich mal was Interessantes :)
Klingt für mich nach so einer Art low-occupancy mode, in dem man die 4 VALUs benutzen kann, um mit forwarding eine einzelne wavefront schneller zu bearbeiten. Also statt einer Instruktion pro 4 cycles, dann jeden cycle eine VALU instruction + die anderen typen. Wirklich überzeugend finde ich diesen Ansatz aber erstmal nicht.

[DrumDub]

https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11949689&postcount=1690
Ja ne, wir sprechen uns dann in einem Jahr nochmal.
haha ... ernsthaft? du weißt schon, wen du da zitierst? ;D und zu den anderen beiden postings muss man nur sagen, dass die autoren das ja auch stark bezweifeln, was da zuvor von der clickbait-website kolportiert wurde.

[HOT]

Jemand eine Ahnung wie es um den PCIe 4.0 Support bei Navi aussieht?
Da V20 schon PCIe 4 hat, wird Navi das auch haben. Die gesamte neue AMD-Infrastruktur ist PCIe 4.


Es war doch lange klar, dass Navi noch GCN ist. Gleichzeitig wird das aber die größten Änderungen in der GCN-Architektur mitbringen, ähnlich wie Cayman damals bei VLIW.
- NGG
- gute Skalierung bis zum 64-CU-Limit
- RT-Erweiterungen

NGG ist mMn der Schlüssel für die Konsolen, um die Qualität drastisch zu steigern.

[Gipsel]

Meinst, die haben jetzt VMEM load-store decoupled?
Aus "lib/Target/AMDGPU/AMDGPU.td":
def FeatureVscnt : SubtargetFeature<"vscnt",
"HasVscnt",
"true",
"Has separate store vscnt counter"
Ob bzw. wie da was decoupled ist, geht daraus ja nicht hervor. Aber man kann damit unnötige Waits vermeiden. Das würde übrigens auch zutreffen, wenn man den LGKM_CNT auseinander genommen hätte. Immerhin zählt der ausstehende LDS-, GDS- und Konstant*- (SMEM-) Speicherzugriffe, alles zusammen. Das ist auch etwas suboptimal, aber offensichtlich hat da einer mal durchsimumuliert und meinte, das lohnt den Aufwand nicht. Keine Ahnung.

*:
Der constant memory wird bei AMD traditionell mit "k" geschrieben, war schon zu VLIW-Zeiten mit dem "konstant cache" so. Und bei GCN übernehmen skalare Speicherzugriffe üblicherweise diese Funktion, weswegen die für SMEM und ein "K" im Namen haben.

[w0mbat]

Wie lange braucht ein Linux-Treiber-Zyklus? 6 Wochen?

Ich hoffe echt, dass wir nächste Woche was zu Navi hören, sonst muss ich mir echt eine 1660 Ti holen...

[aufkrawall]

Wie lange braucht ein Linux-Treiber-Zyklus? 6 Wochen?

Phoronix-Michael spekuliert auf Support in 5.3, der im September als Stable erscheint. RC1 kommt ~sechs Wochen vorher, und wiederum ein paar Wochen vorher dürfte der Support in AMDs WIP-Branches aufschlagen. Wenn die Grundannahme mit 5.3 nicht falsch ist, ist Juli also nicht abwegig.
Gibt allerdings keine Garantie dafür, dass kurze Zeit nach den LLVM-Patches der Rest aufschlägt. Wobei es natürlich plausibel wäre.

[Mr.Scott]

Da V20 schon PCIe 4 hat, wird Navi das auch haben. Die gesamte neue AMD-Infrastruktur ist PCIe 4.


Es war doch lange klar, dass Navi noch GCN ist. Gleichzeitig wird das aber die größten Änderungen in der GCN-Architektur mitbringen, ähnlich wie Cayman damals bei VLIW.
- NGG
- gute Skalierung bis zum 64-CU-Limit
- RT-Erweiterungen

NGG ist mMn der Schlüssel für die Konsolen, um die Qualität drastisch zu steigern.



was ist - NGG?

[BoMbY]

Next Generation Geometry, das was bei Vega immer noch nicht so richtig zu funktionieren scheint.

[danarcho]

Aus "lib/Target/AMDGPU/AMDGPU.td":
def FeatureVscnt : SubtargetFeature<"vscnt",
"HasVscnt",
"true",
"Has separate store vscnt counter"
Ob bzw. wie da was decoupled ist, geht daraus ja nicht hervor. Aber man kann damit unnötige Waits vermeiden. Das würde übrigens auch zutreffen, wenn man den LGKM_CNT auseinander genommen hätte. Immerhin zählt der ausstehende LDS-, GDS- und Konstant*- (SMEM-) Speicherzugriffe, alles zusammen. Das ist auch etwas suboptimal, aber offensichtlich hat da einer mal durchsimumuliert und meinte, das lohnt den Aufwand nicht. Keine Ahnung.

*:
Der constant memory wird bei AMD traditionell mit "k" geschrieben, war schon zu VLIW-Zeiten mit dem "konstant cache" so. Und bei GCN übernehmen skalare Speicherzugriffe üblicherweise diese Funktion, weswegen die für SMEM und ein "K" im Namen haben.
Naja, es würde helfen bei Loads nicht mehr auf alle vorherigen ausstehenden stores warten zu müssen und umgekehrt. Wie häufig das vorkommt, weiß ich aber nicht genau. Auf der anderen Seite, muss eine load-store dependency jetzt doppelt warten, wenn es nicht mehr in-order ist... die werden das schon durchgerechnet haben.
lgkm ist das meiste eh out-of-order. Aber da die alle recht fix sind, ist es nicht so schlimm. Bei cache hits und high occupancy hat man meist gar keine stall cycles.

[robbitop]

Die Frage ist, ob die ISA wirklich so relevant ist für die Güte des Endproduktes. GCN als ISA ist eigentlich sehr vernünftig. Es hapert doch offenbar eher an der Implementierung.

Laut gravitationsfeld haben sich seit Hawaii (also der ersten GCN Iteration) die Timings nicht geändert. Das spricht dafür, dass es keine besonders großen Eingriffe in die Implementation der mArch gab. Das passt auch dazu, dass AMD jahrelang RnD runtergefahren hat und sich voll auf Ryzen und Konsolen konzentriert hat. Entsprechend war offenbar nicht mehr viel an Ressourcen übrig, um wirklich tiefgreifende Änderungen in die mArch zu implementieren.

Da es bei Navi erstmals anscheinend größere Änderungen bei den Timings gibt, spricht das für eine erstmals größere Änderung in die mArch. Dass die ISA gleich bleibt muss also überhaupt nicht schlimm sein.
NV ändert die ISA auch nicht ständig und dennoch sind immer mal wieder richtig große Sprünge in Bezug auf Perf/W möglich.

[Gipsel]

Die Frage ist, ob die ISA wirklich so relevant ist für die Güte des Endproduktes. GCN als ISA ist eigentlich sehr vernünftig. Es hapert doch offenbar eher an der Implementierung.Volle Zustimmung. Genau das sage ich ja seit Jahren. Insofern würde es mich auch nicht wundern, wenn die eigentlichen CUs auch noch nach Navi bei der GCN-ISA (und auch dem Aufbau mit 4 Vector-ALUs + Skalar-ALU) bleiben. VLIW hatte sich irgendwann überlebt (auch wenn es auch mal [z.B. bei nV] Überlegungen gab, das aus Stromspargründen mit kurzen "LIW" mit z.B. 2 Operationen wiederzubeleben), weil es eben für viele "moderne" Shaderprogramme nicht mehr so gut paßte wie in den Anfangszeiten. Aber bei GCN mit dem Vektor+Skalar-Aufbau sehe ich das jetzt so noch nicht. Features wie RT, Wavefront-Neuformierung/variable Wavefront-Größen, anderes Geometrie-Frontend mitsamt Workdistribution kann man auch bei GCN dazubauen. Denn am Ende befaßt sich GCN im Wesentlichen mit den CUs selber.

[BoMbY]

Ja, wir haben ja bereits bei x86 (und was da dran hängt) gesehen das man für ein identisches Instruction Set durchaus deutlich unterschiedliche Implementierungen machen kann, und wie man an den Patches sehen kann gibt es ja auch bei GFX10 neue Instruktionen, nur welche das genau sind war bisher nicht ersichtlich - da wird bestimmt noch was kommen.

[Mr.Scott]

Haltet ihr HBM3 bei Navi20 (Release im Jahr 2020 vorausgesetzt) für realistisch?

https://www.computerbase.de/2017-12/hbm3-ddr5-rambus/

"Sowohl mit HBM3 als auch DDR5-Speicher ist nicht vor den ersten 7-nm-Chips zu rechnen."

[reaperrr]

Haltet ihr HBM3 bei Navi20 (Release im Jahr 2020 vorausgesetzt) für realistisch?

https://www.computerbase.de/2017-12/hbm3-ddr5-rambus/

"Sowohl mit HBM3 als auch DDR5-Speicher ist nicht vor den ersten 7-nm-Chips zu rechnen."
Naja, rein technisch gesehen sind die Unterschiede zwischen den HBM-Varianten eh fließend und zudem gering.

Der HBM2E von Samsung ist schon ziemlich nah an dem, was "echter" HBM3 leisten wird.

Auf jeden Fall spricht die Gerüchteküche bei Navi20 bisher von HBM, und wenn sie wieder auf 2048 bit SI wie bei Vega10 runter wollen (würde aus Kostengründen Sinn machen, da Chip und Interposer dadurch kleiner ausfallen), brauchen sie im Grunde HBM mit wenigstens 50% mehr Bandbreite als bei Vega56/64, vorausgesetzt sie wollen wenigstens im Performance-Bereich der 2080 Ti landen.

[HOT]

Da postet Leo aber auch wieder einen Schrott auf der Hauptseite.
N20 ist ein Refresh von N10. Warum sollte AMD vom bisherigen Namensschema abweichen? das macht 0 Sinn. Und natürlich haben die 64CUs, auch N20.
Mehr wirds erst nach GCN geben.

Wo kommt eigentlich dieser unsägliche Blödsinn her, dass Navi nur "Mainstream" sein darf? Mainstream ist P11/21 und GP107. Da ist P10/20/30 und TU107 jetzt reingeruscht. Da wird sicherlich auch einen Navi geben, aber immer dieses Vorgebete, dass Navi "nur Mainstream" wird ist schlicht und ergreifend falsch.

[Mangel76]

Da postet Leo aber auch wieder einen Schrott auf der Hauptseite.
N20 ist ein Refresh von N10. Warum sollte AMD vom bisherigen Namensschema abweichen? das macht 0 Sinn. Und natürlich haben die 64CUs, auch N20.
Mehr wirds erst nach GCN geben.
So wie V20 ein Refresh von V10 ist?

[robbitop]

Warum sollte das Instructionset die maximale Skalierbarkeit beschränken? Ob GCN oder nicht sagt relativ wenig über die Implementierung aus. Ich glaube viele setzen mit GCN die Implementierung der mArch (die sich seit Hawaii ja nur wenig verändert hat) gleich.

Außerdem gab es IIRC doch mal ein Interview mit AMD, wo verneint wurde, dass es eine harte Grenze von 64 CUs gibt.
Das ist vermutlich nur eine praktikable Grenze der Skalierbarkeit bei der bisherigen Implementierung der mArch mit GCN instruction set.

[iuno]

Ich weiss auch nicht, warum das andauernd behauptet wird. Ist doch derselbe Unsinn, wie dass Navi keine GCN mehr sei.

Fakt ist aber auch, dass man mehr als 64 CUs schlicht bisher nicht gebraucht hat. Das eigentlich stoerende Limit sind doch hier die 4 SEs. Eine GPU mit 6 SEs und je nur 10 CUs waere sicherlich fuer Gaming workloads besser gewesen als V10 mit 4*16 CUs. Wir wissen ja, dass die 16 CUs pro SE nicht optimal sind. Und dann koennte man immer noch eine GPU mit 6*16 bauen. Aber 96 CUs, das ist doch eh erst in 7nm ueberhaupt denkbar. Und nur fuer eine schnellere Gaming-GPU mit 60 CUs war der Aufwand bisher offenbar einfach viel zu hoch.
Man hat es ja auch immer vermieden, 16 CUs pro SE zu verbauen, ausser halt bei Fiji und Vega. Tonga haette z.B. auch in 2 SEs gepasst, es wurden trotzdem 4, P11 hat auch 2 SEs mit je nur 8 CUs. Die effizientesten (Gaming) GPUs hatten halt immer 8-12 CUs pro SE und nicht 16.

Nvidia hat auch seit Maxwell 6 geometry engines und ausserdem den hoeheren Takt. Die 64 CUs sind sicherlich nicht AMDs groesstes Problem.

[Leonidas]

Da postet Leo aber auch wieder einen Schrott auf der Hauptseite.
N20 ist ein Refresh von N10.

Wo kommt eigentlich dieser unsägliche Blödsinn her, dass Navi nur "Mainstream" sein darf?


1. Habe ich was anderes gesagt zu N20? Lese ich nicht.

2. Ich habe "Midrange" geschrieben, nicht "Mainstream". Macht einen Unterschied.

[Piefkee]

N20 ist ein Refresh von N10. Warum sollte AMD vom bisherigen Namensschema abweichen? das macht 0 Sinn. Und natürlich haben die 64CUs, auch N20.



Bullshit! Quelle?

Warum sollt Navi20 ein Navi10 Refresh sein?:freak:
Navi10 wird kein High End das ist bisher bekannt. Daraus lässt sich eher schließen das Navi10 keine 64CU hat, sondern erst Navi20.

[BoMbY]

Woher habt ihr eigentlich alle diese Weisheiten? Von WTTFtech?

[N0Thing]

Anhand des Namensschemas deutet alles darauf hin, dass Navi20 wieder auf den HPC-Bereich abzielt und mit DP und weiteren Features ausgestattet sein wird. Analog zu Vega, könnte auch Navi mit 64CUs kommen und die Salvage Chips füllen das Portfolio nach unten hin auf.

[Leonidas]

Exakt. Solche Infos sind 2 Klicks entfernt:
https://www.3dcenter.org/news/amd-navi

[BoMbY]

Nur sind das bisher alles zu 99% haltlose Gerüchte ohne jeden Beleg ... das ist der entscheidende Punkt.

[reaperrr]

Ist eigentlich außer mir noch jemandem aufgefallen, dass Navi direkt mit mArch Revision 10.1.0 startet, während sämtliche vorherigen GCN-Iterationen mit X.0.0 oder bestenfalls X.0.X starteten?
Bis auf 8.1.0 wurde die zweite Ziffer bisher nie genutzt, und 8.1 ist mWn der unwichtige Stoney Ridge gewesen (k.A. warum sie sich bei dem die Mühe gemacht haben, evtl. irgendwelche Vorstufen von Vega-Features getestet).

Deutliches Indiz dafür, dass entweder a) die Revision 10.0 noch zu verbuggt war, oder b) sich irgendwann abgezeichnet hat, dass 7nm dann doch vom Yield-/Waferpreis-Verhältnis noch länger nicht reif für Mainstream-GPUs sein würde und deshalb die ersten Chips gestrichen oder nochmal überarbeitet wurden.
Würde jedenfalls auch zu dem Gerücht passen, dass zuerst Navi12 kommen soll, während von Navi10 nur Widersprüchliches zu hören ist und Navi11 ziemlich sicher tot ist (gibt ja null Gerüchte zu N11, bisher sind neben N10 nur N12, N14 und eben N20 genannt worden).
Wahrscheinlich waren N10 und N11 ursprünglich GFX10.0, und man hat dann aus einem der o.g. Gründe N11 ganz gestrichen und N10 nochmal überarbeitet und auf GFX10.1 gebracht, wodurch er später fertig wird als N12, der kleiner und von vornherein auf GFX10.1 designt wurde.

Reine Speku, kann alles komplett falsch sein ;)

Das eigentlich stoerende Limit sind doch hier die 4 SEs. Eine GPU mit 6 SEs und je nur 10 CUs waere sicherlich fuer Gaming workloads besser gewesen als V10 mit 4*16 CUs.
Auf die bisherigen GCN-Versionen trifft das zu, das stimmt schon.
Andererseits kommt die 2070 mit nur 3 GPCs auch auf eine ganz ordentliche Leistung.

Das 4-SE-Limit wäre kein wirkliches Problem, wenn eine SE die Leistung/Auslastung eines NV-GPCs und die CUs die gleiche Leistung je ALU/TMU wie zumindest ein Pascal-SM hätten.

Theoretisch müsste AMD die Leistung der V64 (oder noch etwas drüber) einfach mit 48 CUs schaffen, mit entsprechend weniger Fläche und Verbrauch pro MHz, dann wären sie zumindest wieder nah genug an NV dran.
Sollte in 7nm eigentlich drin sein.

[Unicous]

Was ist das denn für ein Quatsch?:confused:

Das bezeichnet doch lediglich die IP-Generation. Außerdem wie kommst du überhaupt darauf?

GFX1000 (und 1001?) soll Navi Lite bezeichnen, bei dem wird momentan vermutet es ist der Codename für eine Konsolen-GPU. 1010 soll Navi 10 sein also ein "vollwertiger" Chip.

Das hat rein gar nichts mit Revisionen zu tun. Wenn es solche Design-"Revisionen" würden die gar nicht in irgendeiner Weise nach außen hin kommuniziert.

Wenn du Revisionen des physischen Chips meinst, werden die seit einiger Zeit auch nicht mehr öffentlich kommuniziert bzw. wenn dann nur "verschlüsselt" in der OPN des Chips.

[Zergra]

Nur sind das bisher alles zu 99% haltlose Gerüchte ohne jeden Beleg ... das ist der entscheidende Punkt.


Naja... Alleine die Existenz von V20 deutet darauf hin das die N10 eine andere Klasse ist und die V20 nicht erreicht. AMD hätte die Karte nie auf den Markt gebracht, wenn sie in 5 Monaten wieder obsolet ist.

[gravitationsfeld]

Warum sollte das Instructionset die maximale Skalierbarkeit beschränken? Ob GCN oder nicht sagt relativ wenig über die Implementierung aus. Ich glaube viele setzen mit GCN die Implementierung der mArch (die sich seit Hawaii ja nur wenig verändert hat) gleich.

Außerdem gab es IIRC doch mal ein Interview mit AMD, wo verneint wurde, dass es eine harte Grenze von 64 CUs gibt.
Das ist vermutlich nur eine praktikable Grenze der Skalierbarkeit bei der bisherigen Implementierung der mArch mit GCN instruction set.
Skalierbarkeit ueber CUs hat nichts mit dem instruction set zu tun. Da geht's um die Interconnects usw.

[reaperrr]

Was ist das denn für ein Quatsch?:confused:

Das bezeichnet doch lediglich die IP-Generation. Außerdem wie kommst du überhaupt darauf?
Ääh... genau das meine ich damit doch? :confused:
Wie komme ich auf was? Ich raff gerade echt nicht ganz, was du da aus meinem Text für eine Aussage herauszulesen meinst... :confused:

Ich wollte darauf hinweisen, dass die für die kommenden Desktop-Navis verwendete Version der IP-Generation GFX10 scheinbar eben nicht die erste ist, sondern schon Updates eingeflossen sind. Dass 10.0 für eine (oder beide) Konsolen ist kann natürlich sein, aber die Subrevisionen (oder meinetwegen Sub-Versionen, wenn du dich am Begriff Revisionen störst...) der jeweiligen IP-Generation bedeuten eigentlich immer, dass die höhere Nummer neuer ist und wenigstens kleine Änderungen unter der Haube hat. Dass die für einzelne Chips stehen habe ich nie behauptet, dann müsste es auch viel mehr Einträge geben.

[Unicous]

GFX10 steht für die neueste Grafikgeneration, davor gab es GFX9, etc. ...

AMD vergibt seit einiger Zeit keine klaren Codenamen mehr für ihre Chips. GFX 1000 und 1001 und 1010 sind einfach nur verschiedene Chips. Ob jetzt "Navi Lite" eine ältere Iteration von Navi ist, ist reine Spekulation und hat bislang keinerlei Grundlage. AMD hatte mal vor einiger Zeit gesagt, dass sie seit einiger Zeit die Designs nach Projektstart nummerieren. Ob das weiterhin der Fall ist wissen wir nicht, aber es ist anzunehmen.
Es gibt mehrere Teams die an den jeweiligen Projekten arbeiten, aber die arbeiten nicht in einer Blase sondern auch hier gibt es regen Austausch.

Die Nomenklatur scheint nach außen hin ziemlich random zu sein, wie man hier gut sehen kann: https://llvm.org/docs/AMDGPUUsage.html#processors

Daraus zu schließen, Navi 1010 wäre eine "Revision" weil Navi1000 verbuggt wäre ist Blödsinn.

GFX10 ist die Familie und dann gibt es nochmal die IP-Blöcke, die einzelne "Funktionslevel" des Chips auflisten. Und auch da ist nicht gleich höhere Zahl=besser. Gutes Beispiel dürfte da Stoney Ridge sein, da hat sich iirc bis auf den "Video" IP-Block nicht viel verändert. GFX IP dürfte da weiterhin Carrizo gewesen sein.


Und so als Info: Diese IDs sind auch dafür da um Features abzufragen. Das sieht man z.B. bei den GPUs die auch HBCC-fähig sind. Sobald HBCC aktiviert wird, ändert sich die ID, siehe Vega 10 (GFX900) und Vega mit HBCC(GFX901)

[gravitationsfeld]

Die LLVM-Auflistung betrifft nur das CU-Instruction-Set. Andere Bloecke der GPU haben ihre eigenen Revisionen. Z.B. verschiedene Command-Prozessoren., Video-Block etc.

Der ganze Chip ist einfach nicht mit einer Zahl zu beschreiben.

[Unicous]

Nichts anderes habe ich geschrieben?:confused:

https://www.techpowerup.com/forums/threads/amd-graphics-ip.243974/

Auf die Schnelle habe ich diese Auflistung gefunden.

[Tarkin]

https://youtu.be/ckJIy0L7LHY

PCB Analyse eines AMD Boards mit GDDR6 (Buildzoid)

[BoMbY]

Dass es auch GDDR6 für GFX10 geben wird ist kein großes Geheimnis mehr: https://github.com/GPUOpen-Drivers/pal/commit/ee4e837d08ec933714df20e76abe0aebee42d457#diff-2a796a8411a20d227df820aff4996b0d

[RitterRost]

https://youtu.be/ckJIy0L7LHY

PCB Analyse eines AMD Boards mit GDDR6 (Buildzoid)

Ach du Scheiße :-(
2x8Pin für Midrange
Bitte nicht.

[Zergra]

Naja dann können wir jedenfalls eine V64+ Leistung erreichen 🤔

[N0Thing]

Ach du Scheiße :-(
2x8Pin für Midrange
Bitte nicht.

Von einem Board aus der Entwicklung würde ich nicht auf das Endprodukt schließen. Abgesehen davon haben ja auch einige GTX 1080 custom PCBs 2x8 Lötstellen, ohne dass es notwendig wäre.

[w0mbat]

Ach du Scheiße :-(
2x8Pin für Midrange
Bitte nicht.
Besser als 6GB VRAM.

[SKYNET]

Besser als 6GB VRAM.


+1111111111111111

da kommt wohl doch noch was dickes von AMD dieses jahr... ;D

[N0Thing]

+1111111111111111

da kommt wohl doch noch was dickes von AMD dieses jahr... ;D

Mit einem 256bit Speicherinterface wird man wohl eher den Bereich einer RTX 2070/2080 anvisieren.

[danarcho]

Die Frage ist, ob die ISA wirklich so relevant ist für die Güte des Endproduktes. GCN als ISA ist eigentlich sehr vernünftig. Es hapert doch offenbar eher an der Implementierung.

Laut gravitationsfeld haben sich seit Hawaii (also der ersten GCN Iteration) die Timings nicht geändert. Das spricht dafür, dass es keine besonders großen Eingriffe in die Implementation der mArch gab.
Zwischen Fiji und Polaris wurden die CUs verändert ohne jeglichen Änderungen an der ISA. Zwischen Polaris und Vega nochmals (um die Taktrate zu erhöhen) und die ISA-Änderungen waren wieder minimal.

Nichts anderes habe ich geschrieben?:confused:

https://www.techpowerup.com/forums/threads/amd-graphics-ip.243974/

Auf die Schnelle habe ich diese Auflistung gefunden.
Diese Liste hat halt rein gar nichts damit zu tun. Du siehst doch selbst, dass z.B DCE für die GFX Version keine Rolle spielt, genausowenig kannst du aus einer GFX Version immer eindeutig auf einen Chip schließen - mehrere Chips können die gleiche Version haben, aber ein Chip auch mehrere wie zB Hawaii. Die GFX Version bezieht sich ausschließlich auf das (funktionierende) Vorhandensein der Instruktionen. Probiers lieber mal mit dieser Liste: https://llvm.org/docs/AMDGPUUsage.html#processors
Der Grund für mehrere Versionen in einer Generationen ist eher HW-Bugs in einzelnen Chips, oder z.B xnack für APUs, und anscheinend auch DP:SP.

[aufkrawall]

Mit einem 256bit Speicherinterface wird man wohl eher den Bereich einer RTX 2070/2080 anvisieren.
Seit wann erreicht AMD bei gleich großem Interface die gleiche Performance wie NV?

[amdfanuwe]

Seit wann erreicht AMD bei gleich großem Interface die gleiche Performance wie NV?
Seit Navi?

[aufkrawall]

Seit Navi?
Beitraggehalt: 0.

[amdfanuwe]

Beitraggehalt: 0.
Dann hast du es wohl nicht verstanden.

[aufkrawall]

Oder ich erzähl einfach keinen unseriösen Stuss, wo der Wunsch Vater des Gedanken ist.

[amdfanuwe]

Oder ich erzähl einfach keinen unseriösen Stuss, wo der Wunsch Vater des Gedanken ist.
Nicht? Warum unterstellst du denn AMD auch in Zukunft nicht Effizient sein zu können?

[Loeschzwerg]

Habe die Bilder des PCB mal hier hochgeladen, für alle die kein YT gucken wollen.

[RitterRost]

Von einem Board aus der Entwicklung würde ich nicht auf das Endprodukt schließen. Abgesehen davon haben ja auch einige GTX 1080 custom PCBs 2x8 Lötstellen, ohne dass es notwendig wäre.

Ich hoffe auch, dass das nur eine Testplatine mit worst case Stromversorgung ist.
Allerdings steht unter dem Youtube Video in den Kommentaren: Where did you find this picture?
Und einer Antwortet:
this was first leaked on baidu foru,ms, someone who allegedly works at a pcb factory. this pcb production is a big volume order apparently. glad buildzoid made a video about this

"...big volume order..." - also keine Hand voll Testplatinen.
Ich hoffe, er hat unrecht.

[Screemer]

Freu mich auf jeden Fall über usb-c

[aufkrawall]

Nicht? Warum unterstellst du denn AMD auch in Zukunft nicht Effizient sein zu können?
Ist ja auch erst zehn Jahre her, dass das das letzte Mal der Fall war. :freak:

[N0Thing]

Seit wann erreicht AMD bei gleich großem Interface die gleiche Performance wie NV?

Seit wann erreicht AMD bei kleinerem Interface die gleiche Performance wie NV?

Mein Beitrag war eine Antwort und steht nicht im luftleeren Raum, aber ich füge mal ein Zitat ein, damit es klarer wird.
AMD kann natürlich auf das PCB eine noch kleinere Lösung setzen, aber es wird kaum ein dickes Ding.

[Daredevil]

Nicht? Warum unterstellst du denn AMD auch in Zukunft nicht Effizient sein zu können?

Effizienz kostet Ressourcen und damit halt Geld.
Wenn ich Chip A groß mache und effizient betreibe, kann ich das gleiche auch mit einem kleineren Chip B machen, welcher hoch getaktet ist und dafür kleiner. AMD ist in der Hinsicht Effizent, Kosteneffizient. :<

[N0Thing]

Ich hoffe auch, dass das nur eine Testplatine mit worst case Stromversorgung ist.
Allerdings steht unter dem Youtube Video in den Kommentaren: Where did you find this picture?
Und einer Antwortet:
this was first leaked on baidu foru,ms, someone who allegedly works at a pcb factory. this pcb production is a big volume order apparently. glad buildzoid made a video about this

"...big volume order..." - also keine Hand voll Testplatinen.
Ich hoffe, er hat unrecht.

Dann bin ich mal gespannt.
Dafür, dass Navi ja eher im Herbst erwartet wird, wäre eine Massenproduktion der PCBs zu diesem Zeitpunkt doch ziemlich früh, oder nicht?

[robbitop]

Seit wann erreicht AMD bei gleich großem Interface die gleiche Performance wie NV?

Wobei Turing deutlich mehr Bandbreite hat pro gflop als Pascal. Für RT ist Bandbreite wohl entscheidend.

[BlacKi]

Ach du Scheiße :-(
2x8Pin für Midrange
Bitte nicht.
es sind nicht nur die pins, die stromversorgung ist ebenfalls sehr stark ausgefallen. aber als ausgleich gibts dafür RGB auf dem referenzkühler für die wahren gamer, zusammen mit einem fancy blower design für die 300w karte:biggrin:

wenn man von dem board ausgeht würde ich 2070 2080 performance bei 300w nicht mehr ausschließen, auch wenn man bei dem SI etwas optimismus braucht.

[Blediator16]

es sind nicht nur die pins, die stromversorgung ist ebenfalls sehr stark ausgefallen. aber als ausgleich gibts dafür RGB auf dem referenzkühler für die wahren gamer, zusammen mit einem fancy blower design für die 300w karte:biggrin:

wenn man von dem board ausgeht würde ich 2070 2080 performance bei 300w nicht mehr ausschließen, auch wenn man bei dem SI etwas optimismus braucht.

also wie eine r7 nur ohne hbm :freak:

[Zergra]

Naja V64 Leistung bei 300Watt bekommen wir doch jetzt auch schon, da müssten dann 15% mehr möglich sein...

[Linmoum]

Vega64 +15% bei 300W wären eine Vollkatastrophe, selbst bei +25% kann man das nicht anders bezeichnen.

Wir reden hier immerhin nicht wie bei der VII von einem "reinen" weiteren Shrink der Vega-Architektur. Mit dem, was man da sieht, sollte man eine 2080 hinter sich lassen. Alles andere wäre noch fataler als damals die Vega64 mit ihrem viel zu späten Launch und der unter Berücksichtigung aller Umstände schwachen (Gaming-)Performance.

Es ergibt nichts wirklich Sinn. Midrange erst recht nicht, weil man da 'ne Referenz nicht mit 2x8-Pin ausstattet. Zumal alleine 7nm einen ordentlichen Effizienzvorteil bieten, in der Hinsicht müsste man also massiv irgendwas vergeigt haben, wenn das eine "580/590-Lösung" wäre. Und wenn man jetzt auf High-End/Enthusiast schielt, dann hat man 8GB die dafür einfach keinen Sinn ergeben. Insofern keine Ahnung, was man da jetzt mit anfangen soll bzgl. der Einordnung in irgendein (Performance-)Segment.

[amdfanuwe]

Effizienz kostet Ressourcen und damit halt Geld.

Da hatte AMD die letzten Jahre Problem. Heißt aber nicht, dass es in Zukunft so bleibt.
Ich meine, Intel hat Ressourcen und Geld, bekommt im Moment aber dennoch nichts gebacken.
Nvidia verkaufte damals die 970 mit 3,5GB RAM für >300€. Da war die 480 mit 8GB für 250€ eine Überraschung.
Leider fehlte das Geld für schnellere Designs.
Vega war eher für HPC gedacht und im Gamingbereich eine Notlösung.
Die Konsolen dürften die Triebfeder für NAVI sein, effiziente Gaming Lösungen.
Mal sehen, was AMD damit im Desktop anstellt, werden sie gut oder muß AMD wieder über Takt und Preis gehen, damit sie was verkaufen könne.
Ich lass mich überraschen.

[w0mbat]

Dann bin ich mal gespannt.
Dafür, dass Navi ja eher im Herbst erwartet wird, wäre eine Massenproduktion der PCBs zu diesem Zeitpunkt doch ziemlich früh, oder nicht?
Navi soll in ca. 2 Monaten kommen (7/7), das sagen schon lange alle Gerüchte. Woher hast du Herbst?

[Linmoum]

Und Gerüchte besagen natürlich immer die Wahrheit und liegen nie daneben.

[BlacKi]

Naja V64 Leistung bei 300Watt bekommen wir doch jetzt auch schon, da müssten dann 15% mehr möglich sein...
hbm hatte enorme vorteile im verbrauch und bandbreite. die fehlen navi.

ich glaub eher r7 performance und verbrauch zu einem günstigen preis. so zwischen +-450€ 8gb als auch 550€ als 16gb?

[Unicous]

Diese Liste hat halt rein gar nichts damit zu tun. Du siehst doch selbst, dass z.B DCE für die GFX Version keine Rolle spielt, genausowenig kannst du aus einer GFX Version immer eindeutig auf einen Chip schließen - mehrere Chips können die gleiche Version haben, aber ein Chip auch mehrere wie zB Hawaii. Die GFX Version bezieht sich ausschließlich auf das (funktionierende) Vorhandensein der Instruktionen. Probiers lieber mal mit dieser Liste: https://llvm.org/docs/AMDGPUUsage.html#processors
Der Grund für mehrere Versionen in einer Generationen ist eher HW-Bugs in einzelnen Chips, oder z.B xnack für APUs, und anscheinend auch DP:SP.

Ist das dein Ernst? Bin ich hier im falschen Film?:confused:

Was denkst du was ich hier verlinkt habe? https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11980675#post11980675

Und jetzt kommst du mir großkotzig mit demselben Link. Le fuck?:freak:

Hawaii hat im Übrigen nur 2 IDs und die trennen sehr klar zwischen den Pro Chips und den Consumer Chips und man kann rein gar nicht unterscheiden, wie der Chip konfiguriert ist oder gar ablesen was für Hardware Bugs angeblich gefixed wurden, keine Ahnung wie du überhaupt darauf kommst.:confused:

Wenn ein Chip eine neue Revision des Dies inklusive Bug Fixes bekommt, dann wird das jedenfalls nicht (afaik) in der ID festgehalten. Der Microcode/Firmware wird entsprechend verändert und die Revision kann bzw. konnte man auslesen, im Moment scheint es jedenfalls nicht so einfach möglich zu sein.

Auch bei den Device IDs (PCI-ID) geht es eher konfus zu, man kann meist die "SKU"-Konfigurationen unterscheiden, aber iirc sind oft die IDs auch mehrfach vergeben.

Ich habe auch nie gesagt, dass man auf irgendetwas schließen kann, ich habe lustigerweise genau das Gegenteil gesagt und du versuchst mir daraus einen Strick zu drehen... warum?:freak:

[Hakim]

Wenn es wirklich so kommt, und "Big volume Order" deutet es zumindest an, könnte man einerseits sagen ok, man macht evtl. nicht die gleichen Fehler wie beim 480 Release, aber anderseits könnte man sich wieder am Kopf fassen wenn so ein Ding die Konkurrenz zu 2060 werden soll (gehe immer noch von Midrange, also 2060 Konkurrenz bei Navi aus). Ich hoffe nicht das AMD erneut an die Grenzen gehen muss und es nah an der Kotzgrenze betreibt nur um die Jeweilige Konkurrenz Karte im Schacht zu halten.

Aber türlich abwarten und Tee Trinken was dann wirklich kommt. Ich habe immer noch Hoffnung das AMD endlich mal einen Sprung bei der Effizienz gemacht hat.

[w0mbat]

Und Gerüchte besagen natürlich immer die Wahrheit und liegen nie daneben.
Was soll das jetzt bedeuten?

[Linmoum]

Dass man aufhören sollte sich darauf zu versteifen, was irgendwelche Gerüchte an Releaseterminen verbreiten? Jetzt eigentlich nicht so schwer zu verstehen. Die können genauso absoluter BS sein (und sind es mehrheitlich auch), zumal der 7.7. noch immer ein Sonntag ist.

[w0mbat]

Wir sind im Gerüchte-Thread. Ich hab nur gesagt, dass die Gerüchte aktuell 7/7 sagen und gefragt woher er den Herbst her hat. Da musst du doch nicht kommen und nochmal sagen, dass es Gerüchte sind :rolleyes:

[Der_Korken]

Vega64 +15% bei 300W wären eine Vollkatastrophe, selbst bei +25% kann man das nicht anders bezeichnen.

So sieht es aus. Dass AMD nicht plötzlich einen Riesensprung macht und Nvidia meilenweit überholt, war natürlich klar. Aber wenn man aus einem Fullnode und 3 Jahren Zeit keine 20% Effizienz rausholt, ist das so leid es mir tut "armselig". Da braucht sich AMD nachher nicht wundern, wenn die Karten nen schlechten Ruf bekommen, weil sie Strom fressen und dementsprechend laut sind. Wie soll das erst aussehen, wenn Nvidia eien 7nm-Gen bringt? Ein TU106@7nm würde die V64+15% vermutlich mit ~250mm² und <=120W hinbekommen. RT-Cores schon eingerechnet. Hoffe daher auf falsche Info und dass die Grakas wenigstens so effizient wie Turing@12nm wird.

[N0Thing]

Navi soll in ca. 2 Monaten kommen (7/7), das sagen schon lange alle Gerüchte. Woher hast du Herbst?

Stimmt, ich hatte mit dem 7.7. die Ankündigung verknüpft. Ursprünglich hat man Navi ja eher für Q3 erwartet. Dann könnte es mit dem Anlaufen der Massenproduktion ja doch ganz gut passen, sofern die Quellen von TweakTown richtig liegen.

[Daredevil]

Zwei mal 8 Pin kann auch einfach 200-220w Asic bedeuten und 250w Gesamtverbrauch. Ich verstehe nicht , wieso manche sich aufgrund der Pinbelegung jetzt so aufregen.
250w wäre für 2080 Leistung „okay“, wenn der Preis mitspielt.
Eine Vega 56 hatte btw. auch zwei 8 Pin und war bei um die 200w.

Vielleicht sollte man die Erwartung mal senken, dass AMD mit 2070 Leistung um die Ecke kommt, gepaart mit 12GB und 150w Verbrauch. :D
AMD muss stark auf ihre Kosten achten und hat nun einmal nicht die besten Designer der Industrie.
Effizienz bei einem Produkt bedeutet niedrigere Marge oder hoher Preis und dadurch niedrigere Stückzahlen. AMD will aber hohe Margen und hohe Stückzahlen in dem Mainstream Bereich, irgendeinen Tod muss man dann sterben.

[Alkibiades]

Ich hoffe auch, dass das nur eine Testplatine mit worst case Stromversorgung ist.
Allerdings steht unter dem Youtube Video in den Kommentaren: Where did you find this picture?
Und einer Antwortet:
this was first leaked on baidu foru,ms, someone who allegedly works at a pcb factory. this pcb production is a big volume order apparently. glad buildzoid made a video about this

"...big volume order..." - also keine Hand voll Testplatinen.
Ich hoffe, er hat unrecht.

Im Video bei etwa 10:58 zeigt er auf configuration switches, welche wohl eher auf ein ES hindeuten

[gas3t]

Es könnte auch sein, dass sie das gleiche PCB für alle 8GB-Versionen planen:

RX 3060 mit 120 Watt: 6-Pin-Stecker mit Leistung @ V56
RX 3070 mit 150 Watt: 8-Pin-Stecker mit Leistung @ V64
RX 3080 mit 225 Watt: 8-Pin + 6-Pin-Stecker mit Leistung @ V64 + 15%
RX 3090 mit 300 Watt: 2x8-Pin-Stecker mit Leistung @ V7

Die V7 hätte dann zumindest noch 16GB HBM2 als Vorteil und bleibt wie jetzt schon Niesche.

[Daredevil]

Es kann auch einfach jede Version mit 2x 8 Pin daherkommen, weil jedes Netzteil diesen mittlerweile Standard erfüllt bei modernen Netzteilen ab 400w.
Wie gesagt, die V56 war auch bei 210w Verbrauch und hatte theoretisch 375w zu Verfügung.

Eine dicke Spannungsversorgung ist auch bei kleinen Karten ein Effizenzmerkmal.

[BlacKi]

Zwei mal 8 Pin kann auch einfach 200-220w Asic bedeuten und 250w Gesamtverbrauch. Ich verstehe nicht , wieso manche sich aufgrund der Pinbelegung jetzt so aufregen.
250w wäre für 2080 Leistung „okay“, wenn der Preis mitspielt.
Eine Vega 56 hatte btw. auch zwei 8 Pin und war bei um die 200w.

Vielleicht sollte man die Erwartung mal senken, dass AMD mit 2070 Leistung um die Ecke kommt, gepaart mit 12GB und 150w Verbrauch. :D
AMD muss stark auf ihre Kosten achten und hat nun einmal nicht die besten Designer der Industrie.
Effizienz bei einem Produkt bedeutet niedrigere Marge oder hoher Preis und dadurch niedrigere Stückzahlen. AMD will aber hohe Margen und hohe Stückzahlen in dem Mainstream Bereich, irgendeinen Tod muss man dann sterben.
die phasen vorbereitung ist 33% größer als das reference pcb der rx 480/580. das ist auch der verbrauch den ich erwarte. 220-270w. kann auch richtung 300 gehen. die luft wäre vorhanden.

die v56 hat den stromanschluss der großen karte. die hat 300w pt.

[Alkibiades]

Fest steht, aufgrund des GDDR6-Speicher und Amd-Logo handelt es sich um ein PCB der Navi-Generation (hat er im Video auch so erklärt). Da die Stromversorgung auf 300 Watt und mehr ausgelegt ist, gehört das PCB ziemlich sicher zu dem Navi-Topmodell (man wird ja wohl keine Grafikkarten mehr mit mehr als 300 Watt Stromverbrauch veröffentlichen).

Das deutet auch daraufhin, das Amd mit dem Navi-Topmodell beim Navi-Release 2019 beginnt und nicht erst 2020.

Falls Amd die Leistung von Navi nicht verschlechtert hat, sollte das Navi Topmodell mindestens Radeon VII-Leistung haben, laut dem geleakten PCB mit nur einem 256 bit Speicherinterface

[Linmoum]

(man wird ja wohl keine Grafikkarten mehr mit mehr als 300 Watt Stromverbrauch veröffentlichen)
Redest du jetzt von AMD/Nvidia oder den Boardpartnern? ;)

[Der_Korken]

Wenn die Leistung stimmt, sind 300W natürlich "OK", aber ich glaube nicht, dass Navi über die VII hinaus kommen wird. Da sprechen die 256bit SI einfach gegen. Diese passen eher zu den Gerüchten eines ~200mm²-Midrange-Chips und der wird die VII nicht knacken.

[Alkibiades]

Redest du jetzt von AMD/Nvidia oder den Boardpartnern? ;)
300 Watt als Maximum war jetzt von mir allgemein gemeint. Hat sich ja etabliert, abseits von speziellen Herstellerdesigns, die psychologisch wichtige Grenze von 300 Watt nicht zu überschreiten

[Zergra]

Wenn die Leistung stimmt, sind 300W natürlich "OK", aber ich glaube nicht, dass Navi über die VII hinaus kommen wird. Da sprechen die 256bit SI einfach gegen. Diese passen eher zu den Gerüchten eines ~200mm²-Midrange-Chips und der wird die VII nicht knacken.
Eben, AMD hätte davon viel mehr mit einer Karte die knapp 200Watt braucht -> und dann knapp unter der V7 ist, Kühlbar und mit OC wohl die V7 erreicht. Dazu ein guter Preis und die Karte verkauft sich ganz gut. Also sowas um die 400€.

[Daredevil]

Oha, in dem Video wird aber halt auch gesagt, dass dort vermutlich Bohrungen für nen Radial Lüfter sind. Also ist das für uns Enduser ja ( HOFFENTLICH ) eh nicht gedacht. :D

[Alkibiades]

Um mal was positives zum Stromverbrauch zu spekulieren:

Der größte Teil des Stromverbrauches eines Prozessors (auch Grafikprozessors) geht auf auf die Kommunikation (Speicherinterface, Cache-Kommunikation, usw.) zurück. Unter anderem deswegen wurde Nvidia mit Maxwell so effizient, weil es Nvidia gelang die benötigte Kommunikation durch irgendwelche Tiled-based-Rendering Ansätze und weiteren Maßnahmen zu reduzieren.

Selbst wenn es AMD mit Navi gelingt auf gleicher Art und Weise den Stromverbrauch deutlich zu reduzieren, müssen erstmal die Treiber entsprechend programmiert werden. Daher kann es auch sein, dass die 250-300 Watt nur für das engineering sample gebraucht werden um die Treiber fertigzustellen, die fertigen Consumer-Varianten mit passenden Treiber können dann viel sparsamer sein (Deshalb vielleicht auch der Lüfter downgrade von Axiallüfter der Radeon VII zu Radiallüfter).

[Der_Korken]

Die einzige Karte, die per Software später nochmal sparsamer wurde, war afaik die 480 wegen der Sache mit dem 1x6pin und >150W Verbrauch. Selbst wenn man per Software noch ordentlich Effizienz rausholen könnte (ich bezweifle stark, dass es so kommt), dann würde man den Verbrauch lieber so lassen und den gesparten Strom in mehr Takt reinvestieren. Schließlich muss man Kühlung und Spannungsversorgung eh auf den höheren Verbrauch auslegen.

[BlacKi]

Oha, in dem Video wird aber halt auch gesagt, dass dort vermutlich Bohrungen für nen Radial Lüfter sind. Also ist das für uns Enduser ja ( HOFFENTLICH ) eh nicht gedacht. :D
natürlich wird man wieder radiallüfter referenzkarten sehen.

[Daredevil]

Natürlich.

[Alkibiades]

Die einzige Karte, die per Software später nochmal sparsamer wurde, war afaik die 480

Die Radeon RX 480 war die einzige Karte die nach Release sparsamer wurde, meine Spekulation bezieht sich aber auf ein engineering sample, welches keinesfall final sein muss und ggf. nur für interne Entwicklungszwecke gedacht ist.

Zudem lass mich doch mal was positives zu Amd Grafikkarten und Stromverbrauch spekulieren (was nicht ganz einfach ist)

[BlacKi]

Die Radeon RX 480 war die einzige Karte die nach Release sparsamer wurde, meine Spekulation bezieht sich aber auf ein engineering sample, welches keinesfall final sein muss und ggf. nur für interne Entwicklungszwecke gedacht ist.

Zudem lass mich doch mal was positives zu Amd Grafikkarten und Stromverbrauch spekulieren (was wie Du siehst nicht ganz einfach ist)
welches engineering sample? das passt nicht zu der high volume info.

[Alkibiades]

welches engineering sample? das passt nicht zu der high volume info.

Im Video bei etwa 10:58 zeigt er die configuration switches, welches auf ein engineering sample hindeuten. Die high volume info könnte eventuell einfach nur dazugedichtet sein, wie es manchmal bei Leaks ist, die durch mehrere Leute durchgereicht werden

Wenn die Leistung stimmt, sind 300W natürlich "OK", aber ich glaube nicht, dass Navi über die VII hinaus kommen wird. Da sprechen die 256bit SI einfach gegen. Diese passen eher zu den Gerüchten eines ~200mm²-Midrange-Chips und der wird die VII nicht knacken.

Also die 300 Watt deuten ziemlich eindeutig auf das Navi-Topmodell hin. Wenn Amd die Radeon VII Leistung nicht mit Navi hinbekommt, haben die ihre Architektur verschlechtert. Das ist ziemlich unglaubwürdig, es sei denn, die Stromversorgung ist nur sehr sehr großzügig dimensioniert und wird nicht im Ansatz benötigt.

Nvidia schafft mit der RTX 2080 mit einem 256 bit GDDR6 Speicherinterface die Radeon VII Leistung gut zu überbieten. Wobei ich glaube, dass die volle Bandbreite eher für Raytracing benötigt wird, weniger für normale Rasterizer-Grafik?

Daher sollte VII Leistung mit 256 bit Interface nicht unmöglich sein.

[Korvaun]

Mal wieder bis an die Grenze mit 300W? Wo ist denn die 7nm Effizienz hin? Radeon VII schön und gut, war hauptsächlich nen "simpler" Shrink, aber NAVI? Wird also doch nur nen Bugfix-Design von VEGA in 7nm, bäh :(

[Der_Korken]

Also die 300 Watt deuten ziemlich eindeutig auf das Navi-Topmodell hin. Wenn Amd die Radeon VII Leistung nicht mit Navi hinbekommt, haben die ihre Architektur verschlechtert. Das ist ziemlich unglaubwürdig.

Nvidia schafft mit der RTX 2080 mit einem 256 bit GDDR6 Speicherinterface die Radeon VII Leistung gut zu überbieten. Wobei ich glaube, dass die volle Bandbreite eher für Raytracing benötigt wird, weniger für normale Rasterizer-Grafik???

Wie gesagt, wenn die Leistung stimmt, können auch 300W OK sein. Das müsste dann aber schon 2080Ti-Niveau sein imho, ansonsten wäre AMD mit 7nm klar schlechter als Nvidia mit 12nm. Das kann jeder sehen wie er will, einigen ist das auch völlig egal so lange sie unter 100°C bleibt damit keine Spiele crashen und die Sicherung nicht rausfliegt. Ich finde es aber sehr bedenklich wenn AMD selbst mit einem Fullnode Vorsprung hinter Nvidia zurückbleibt. Beim Speicherinterface sollte man imho einrechnen, dass Nvidia hier immer noch deutlich effizienter sein wird. Da müssen schon deutliche Änderungen an der Architektur her um diesen Rückstand aufzuholen.

Eigentlich bin ich auch nicht der, der den Teufel in Bezug auf AMD an die Wand malt, aber ich bin sowohl von Polaris als auch von Vega als auch von Vega@7nm enttäuscht worden (und nein ich saß nicht auf dem Hypetrain) und es würde mich mittlerweile nicht mehr überraschen, wenn AMD einen 200mm²-Chip auf 300W hochprügelt.

Und ich bin gerade etwas salty, weil ich mir das BVB-Spiel angeguckt habe :redface:

[unl34shed]

Nur weil das Board 2x 8Pin hat wir die Karte also immer 300W ziehen (eigentlich sind sogar 375W drinne!!!). :confused:

[Daredevil]

Wenn NVIDIA eine 2070 mit 300w Verbrauch raus bringen würde für 500€, welche so schnell ist wie eine 2080, würde sich da auch selten jemand drüber beschweren. Solang der Bums relativ okay laut ist, reicht es der Masse, würde ich mal behaupten. ( Beispiel Vega 64 Custom Designs )

AMD muss hier nicht den 7nm Samariter spielen, hier gehts um Balkenlänge!!!1111. Zudem hat der Wattman immer die Option, dass man alles für sich selbst einstellen kann. Drei Profile, drei unterschiedliche Karten.

[Dino-Fossil]

Entweder nur engineering Sample oder wir sehen doch schneller als gedacht eine High-end Navi.
Midrange kommt sicher nicht @300W+, nicht mal bei AMD :ugly:

[AlterSack]

es sind nicht nur die pins, die stromversorgung ist ebenfalls sehr stark ausgefallen. aber als ausgleich gibts dafür RGB auf dem referenzkühler für die wahren gamer, zusammen mit einem fancy blower design für die 300w karte:biggrin:

wenn man von dem board ausgeht würde ich 2070 2080 performance bei 300w nicht mehr ausschließen, auch wenn man bei dem SI etwas optimismus braucht.

Das hat man ja jetzt schon.

[BlacKi]

Im Video bei etwa 10:58 zeigt er die configuration switches, welches auf ein engineering sample hindeuten. Die high volume info könnte eventuell einfach nur dazugedichtet sein, wie es manchmal bei Leaks ist, die durch mehrere Leute durchgereicht werden
er hält es für wahrscheinlicher das die switches für die RGB beleuchtung sein werden. oder war das nicht ernst gemeint? ich habs jedenfalls so verstanden.

was die 2080 performance mit den 256bit angeht ist NV dafür bekannt weniger bandbreite zu benötigen als amd(compression). dazu müsste amd massiv daran geschraubt haben, was nicht unmöglich, aber wohl unwahrscheinlich ist. wenn ich hier eine performance annahme versuche, dann in einem wahrscheinlichen szenario und nicht das best mögliche.

Das hat man ja jetzt schon.
nicht mit 256bit gddr6. in einem szenario wo eine r7 mitgddr6 30-40w mehr verbrauchen würde(der grafikchip müsste runtertakten um die 30-40w einzusparen) und mit weniger als der hälfte der bandbreite zurechkommen müsste, wäre sie wohl unter der 2070 einzuordnen.

[AlterSack]

Wenn es wirklich so kommt, und "Big volume Order" deutet es zumindest an, könnte man einerseits sagen ok, man macht evtl. nicht die gleichen Fehler wie beim 480 Release, aber anderseits könnte man sich wieder am Kopf fassen wenn so ein Ding die Konkurrenz zu 2060 werden soll (gehe immer noch von Midrange, also 2060 Konkurrenz bei Navi aus). Ich hoffe nicht das AMD erneut an die Grenzen gehen muss und es nah an der Kotzgrenze betreibt nur um die Jeweilige Konkurrenz Karte im Schacht zu halten.

Aber türlich abwarten und Tee Trinken was dann wirklich kommt. Ich habe immer noch Hoffnung das AMD endlich mal einen Sprung bei der Effizienz gemacht hat.

So wie es aussieht, hat AMD die ganzen Konsolen SOC der nächsten Generation an Land gezogen.
Denke, das hätten sie nicht, könnten sie Sony und MS nicht davon überzeugen,
leistungsfähige und effiziente GPUs zu designen in der Lage zu sein!

[AlterSack]

Vielleicht sollte man die Erwartung mal senken, dass AMD mit 2070 Leistung um die Ecke kommt, gepaart mit 12GB und 150w Verbrauch. :D

Die 12 GB nicht und 150W wären noch immer zuviel.
AMD mus langsam was Effizienteres liefern um im Rennen zu bleiben.
Sonst hätte man rein aus Effizienzsicht nicht die Chance, bei 7nm
im Highend mitzuspielen, sobald NV Nachfolger der 2000er Serie bringt.
Für die kommenden Konsolen müssen sie ja auch was zu bieten haben.
da können sie nicht mit einem 300W SOC um die Ecke kommen.

[BlacKi]

So wie es aussieht, hat AMD die ganzen Konsolen SOC der nächsten Generation an Land gezogen.
Denke, das hätten sie nicht, könnten sie Sony und MS nicht davon überzeugen,
leistungsfähige und effiziente GPUs zu designen in der Lage zu sein!
das kommt immer drauf an mit welchem takt man sie betreibt.
Die 12 GB nicht und 150W wären noch immer zuviel.
AMD mus langsam was Effizienteres liefern um im Rennen zu bleiben.
Sonst hätte man rein aus Effizienzsicht nicht die Chance, bei 7nm
im Highend mitzuspielen, sobald NV Nachfolger der 2000er Serie bringt.
Für die kommenden Konsolen müssen sie ja auch was zu bieten haben.
da können sie nicht mit einem 300W SOC um die Ecke kommen.
die karten selbst können effizient sein, man muss sie aber eben dort betreiben. leider betreibt amd seine desktop karten immer an der kotzgrenze, die ausnahmen sind immer nur die verhältnismäßig teuren nano karten.

[AlterSack]

Naja, die Hoffnung stirbt zuletzt.
Dass aus ZEN was Gescheites wird, bezweifelten
bis zu dessen Vorstellung auch viele.