PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : AMD/ATI - VEGA (Vega10, Vega11, Vega12, Vega20) - 2017


Seiten : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 [24] 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61

BlacKi
2017-06-04, 20:29:09
Doppelt so viele Transistoren wie Fiji wird Vega wohl kaum haben. Wenn man die Packdichte von Polaris hochrechent und noch ein bischen was draufschlägt, landet man irgendwo im Bereich von 12-13 Mrd. Das sind keine 50% mehr als Fiji.
ich hab ja nicht den chip gemeint sondern den 28nm vs 14nm prozess. amd opfert packdichte für mehr takt. deshalb und wegen des hbcc halbiert sich die chipfläche leider nicht. ansonsten würde sie es zumindest ungefähr.

Digidi
2017-06-04, 23:48:12
Nicht wirklich. Aber wie ich AMD einschätze, haben sie dort Features wie das "Draw Stream Binning" und den "Primitive Discard Accelerator" (wahrscheinlich in verbesserter Form) mitgerechnet, die 11 dürften also wahrscheinlich eher der best-case sein.

Die 11 Polygonen bezogen sich aber soweit ich weiß nur auf das Draw Stream Binning und nicht auf den Discard Accelerator?!

-=Popeye=-
2017-06-04, 23:57:40
Fury bringt auch mehr MH/s als Polaris, also wird Vega noch ne Schippe drauflegen.

Wo wir wieder bei knapp über Fury Performance wären. Polaris war gesamt gesehen ein Schuss in den Ofen.

gedi
2017-06-05, 00:27:11
Wo wir wieder bei knapp über Fury Performance wären. Polaris war gesamt gesehen ein Schuss in den Ofen.

Warum? Polaris stellt sich gegen Fury unter 1080p eigentlich ganz gut an. Zudem ist Polaris für den Moment de facto ausverkauft. Dass die Zielgruppe jetzt nicht im Gaming-Segment zu suchen ist, braucht AMD nicht zu interessieren. Ein Schuss in Ofen sieht imo anders aus.

-=Popeye=-
2017-06-05, 00:44:25
Fury krankt nur am VRAM und ist insgesamt gesehen immer schneller als Polaris (aka 390x LoL), also kann Polaris nicht wirklich mit Fury mithalten.

edit: Ich bleib dabei Vega wird kein 1080Ti/TitanXp Killer, wenn es hoch kommt wird 1080 Performance erreicht und dies ist schon hoch geschätzt.

gedi
2017-06-05, 00:48:48
Cherrypicking ahoi, aber trotzdem: http://www.guru3d.com/articles-pages/powercolor-radeon-rx-580-red-devil-review,11.html

In DX11 fehlt wirklich nicht viel zur Fury in 1080p. Für mehr ist Polaris nicht zu gebrauchen und für mehr wurde er wohl auch nicht entwickelt.

-=Popeye=-
2017-06-05, 00:55:09
Ernsthaft?

http://www.pcgameshardware.de/Radeon-RX-580-8G-Grafikkarte-265939/Tests/RX-570-Review-Benchmarks-1225896/2/#a2

gedi
2017-06-05, 01:03:17
Ja ernsthaft: https://www.computerbase.de/thema/grafikkarte/rangliste/

Das wird allerdings wieder arg OT. Zu Vega meine Einschätzung: AMD gibt eine bessere IPC von 40% im Vergleich zum Vorgänger aus in Verbund mit ~ 60% mehr Takt - das könnte schon etwas werden mit Vega.

-=Popeye=-
2017-06-05, 01:20:46
Ich glaube nicht dran, AMDs Priorität lag die letzten Jahre eher im CPU Bereich und da sind sie aktuell gut aufgestellt, bei den GPUs hängen sie nach wie vor hinter her.

Digidi
2017-06-05, 02:16:53
Ich glaube nicht dran, AMDs Priorität lag die letzten Jahre eher im CPU Bereich und da sind sie aktuell gut aufgestellt, bei den GPUs hängen sie nach wie vor hinter her.

Ah ja du kennst die Strategie von Lisa Su. Nur mal so am Rande. Mit Raja Koduri


"Vor seiner Tätigkeit bei AMD war Raja Koduri Direktor des Bereichs Graphics Architecture bei Apple Inc. Dort war er an der Erstellung eines führenden Grafiksubsystems für die gesamte Mac-Produktfamilie beteiligt und leitete den Umstieg auf Retina-Displays für Computer. Vor seiner Einstellung bei Apple war Raja Koduri in verschiedene Leitungspositionen tätig. Dabei zeichnete er nicht nur verantwortlich für Initiativen zur Sicherstellung einer optimalen GPU-Performance bei Hardware und Software, sondern arbeitete auch maßgeblich am Design der GPU-Systemarchitektur. "

http://www.amd.com/de-de/who-we-are/corporate-information/leadership/raja-koduri

Ich will nicht wissen was AMD Ihm als Ablöse on Apple bezahlt hat. Das dürften dann wohl auch die Prioritäten sein.

Im Übrigen wird erst Navi der Chip sein wo Raja von Anfang bis Ende das Zepter in der Hand hat.

-=Popeye=-
2017-06-05, 02:33:21
Alles nur Blabla... Gelaber. Gehypt von RyZen, wird jetzt das gute abschneiden auf VEGA umgemünzt.

Gipsel
2017-06-05, 02:42:58
Ich glaube nicht dranGlauben kannst Du in der Kirche. Irgendwelche Argumente für Deine Meinung, die ich bisher verpaßt habe?

-=Popeye=-
2017-06-05, 03:18:56
Kirche? Lol

Gegen Frage: Welche sind denn die das VEGA genau dies wird?

Gipsel
2017-06-05, 03:33:46
Also nicht. Danke für das Gespräch. :rolleyes:

-=Popeye=-
2017-06-05, 03:51:28
Hä? In Anbetracht der Polaris plus Refresh Performance kann VEGA gar keinen derart großen Sprung hinlegen. mM

StefanV
2017-06-05, 04:04:07
Ich glaube nicht dran
Hä? In Anbetracht der Polaris plus Refresh Performance kann VEGA gar keinen derart großen Sprung hinlegen. mM
Wenn du keine AHnung hast, wäre es schön, wenn du dich bedeckt halten würdest - DANKE!

Irgendeine sinnlose Anti-AMD Propaganda, die nur auf 'ich glaube' basiert, brauchen wir hier nicht. Hier wäre es schön, wenn du dich auf Fakten beziehen würdest. Und die widersprechen dir nunmal sehr stark.

Halten wir also mal fest:
Ohne Architekturverbesserungen hat VEGA schon mal +50% Takt.
DAS wäre also schon mal in der Region, in der du ganz doll und fest glaubst, dass VEGA landen wird. DAS wäre der Worst Case.

Aber es gibt auch noch 'ne ganze Stange an Verbesserungen - wie den Tiled Renderer. Und noch ganz viele andere Dinge.
Was glaubst du, warum AMD bei VEGA NICHT mehr von GCN spricht?! WARUM sprechen sie von NCU?!
Eben, weil man einiges geändert hat...

Das ganze bedeutet, dass es nur die Benches von AMD selbst gibt, an denen wir uns orientieren können - was schon auf recht wackeligen Füßen steht. Wenn wir jetzt von 'Berechnungen anhand der Architektur' sprechen, kommt nur Unsinn bei raus.
Das ist so, als wenn du die Performance von Tahiti anhand von Cypress ev. Cayman die Performance von Tahiti berechnen wolltest. Also total an den Haaren Herbeigezogen...

[MK2]Mythos
2017-06-05, 06:21:05
Hä? In Anbetracht der Polaris plus Refresh Performance kann VEGA gar keinen derart großen Sprung hinlegen. mM
:facepalm:
Das war der Trump des Tages. Vielen Dank!

Linmoum
2017-06-05, 07:03:39
Gegen Frage: Welche sind denn die das VEGA genau dies wird?
Hä? In Anbetracht der Polaris plus Refresh Performance kann VEGA gar keinen derart großen Sprung hinlegen. mM
Es ist immer wieder der Knaller, wenn man als Grundlage für Vega mit Polaris als Vergleich um die Ecke kommt. Ich dachte, mittlerweile hätte jeder kapiert, dass das Humbug ist.

Ansonsten, wie schon mehrfacht erwähnt, würde Fiji bereits mit ~1600MHz eine 1080 knacken. Dass Vega maximal dort landet, ist aufgrund der ganzen architekturellen Veränderungen eigentlich schon ausgeschlossen. Wäre das der Fall, hätte AMD geschlampt und das Performanceplus würde einzig und alleine vom Takt kommen.

Achim_Anders
2017-06-05, 07:45:27
Woher kommt denn die Taktsteigerung? Könnte es im worst case nicht sein, dass die Veränderungen nur zu höheren Taktraten führen und ansonsten doch auf fiji Niveau liegen?

Thunder99
2017-06-05, 08:08:41
Denke da eher nicht. AMD muss ja mal was neues zusammen basteln was einschlägt.

+/- Ti Niveau finde ich jetzt schon realistisch. Mehr wäre aber besser, da ja Nvidia auch noch mit der nächsten Entwicklung kommen wird.

StefanV
2017-06-05, 08:20:06
Woher kommt denn die Taktsteigerung?
Redesign der Einheiten, auf mehr Takt und weniger Dichte optimiert.
Daher ist VEGA auch deutlich größer als ein geshrinkter Fiji.


Könnte es im worst case nicht sein, dass die Veränderungen nur zu höheren Taktraten führen und ansonsten doch auf fiji Niveau liegen?
Nein, das ist absolut ausgeschlossen...
Dafür sind die Änderungen zu gravierend.

Der Unterschied von Polaris -> Vega ist am ehesten mit Cypress/Cayman -> Tahiti zu vergleichen. "komplett" neue Architektur.
Deswegen spricht man ja auch von NCU und sowas, weniger bis gar nicht von GCN...

Sie haben ja auch selbst gesagt, dass das die größte Änderung seit GCN ist...

Eldoran
2017-06-05, 10:31:14
Redesign der Einheiten, auf mehr Takt und weniger Dichte optimiert.
Daher ist VEGA auch deutlich größer als ein geshrinkter Fiji.
Das macht Sinn und passt zu den bekannten Fakten. Wer jetzt allerdings so etwas wie Phenom->Bulldozer oder PentiumIII->Pentium4 denkt, liegt tendenziell falsch. Gerade bei CPUs ist der maximale Takt des Designs normalerweise mit einer Reduktion der IPC verbunden. I.d.R. verursacht durch Branch Misprediction oder andere Pipeline Stalls. Das ist bei GPUs nicht der Fall, dort lassen sich derartige Probleme normalerweise umgehen. Auch Unterschiede bei Out of Order/superscalar (https://en.wikipedia.org/wiki/Superscalar_processor) sofern das relevant ist, sollte bei Vega identisch oder besser als Fiji sein.
Es gibt also derzeit keinen Grund anzunehmen, dass mit dem Takt die IPC sinkt. Der einzige plausible Unsicherheitsfaktor ist der Speicher. Bewiesen ist bisher nur, dass es Speichermangel besser skaliert. Erschwerend kommt hinzu, dass eher unklar ist, wie effektiv die neuen Optimierungen Speicherzugriffe vermeiden können.
Auch wenn es noch nicht offiziell ist, gibt es doch einen guten Schätzwert für die Brutto-Bandbreite des HBM, wie hoch die Netto-Bandbreite ausfällt ist eigentlich unbekannt. Nebenbei bemerkt ist auch bei klassischen GDDR5 ein klarer Unterschied, der etwa beim Refresh mit der Speichermenge größer wird. Beim HBCC kommt noch der Overhead für die Tags hinzu (wie hoch auch immer der sein mag!). Da spielen viele Faktoren hinein, die allerdings noch unbekannt sind. Die AMD Patente dazu lesen sich für mich wenig optimistisch.

N0Thing
2017-06-05, 11:52:41
Ansonsten, wie schon mehrfacht erwähnt, würde Fiji bereits mit ~1600MHz eine 1080 knacken. Dass Vega maximal dort landet, ist aufgrund der ganzen architekturellen Veränderungen eigentlich schon ausgeschlossen. Wäre das der Fall, hätte AMD geschlampt und das Performanceplus würde einzig und alleine vom Takt kommen.

Ich weiß, daß ein Vergleich mit Fiji auf Grund der Änderungen bei Vega eher den Charakter einer Milchmädchenrechnung hat, aber wie gut skaliert Fiji denn mit einer Takterhöhung?

Beim damaligen PCGH-Review kamen bei ca. 10% mehr Takt nur ~5% mehr Leistung heraus. Gibt es eine Seite, die sich detaillierter und mit mehreren Spielen dem Übertaktungspotential von Fiji gewidmet hat?

victore99
2017-06-05, 12:04:53
Ich weiß, daß ein Vergleich mit Fiji auf Grund der Änderungen bei Vega eher den Charakter einer Milchmädchenrechnung hat, aber wie gut skaliert Fiji denn mit einer Takterhöhung?

Beim damaligen PCGH-Review kamen bei ca. 10% mehr Takt nur ~5% mehr Leistung heraus. Gibt es eine Seite, die sich detaillierter und mit mehreren Spielen dem Übertaktungspotential von Fiji gewidmet hat?
irgendein Extremübertakter hat doch mal Fiji auf 1400/1000 bekommen, ausgehend von 1050/500. kam auch was krasses raus, auch wenn der Bandbreitenvergleich so null passt...

basix
2017-06-05, 12:27:26
Sind wir ehrlich: Momentan weiss man praktisch gar nichts über Vega bis auf die in etwa zu erwartende Rohleistung.

Aber jetzt den Teufel an die Wand zu malen finde ich einfach unüberlegt bis hin zu falsch. Folgende Gründe dazu:
- Neue Architektur = NCU
- NCU = optimiert auf mehr Takt
- NCU = optimiert auf mehr IPC
- NCU = optimiert auf reduzierten Overhead (weniger Triangles etc. müssen berechnet werden, z.B. aufgrund Tiling)
- Speichersubsystem / Cache auf optimale Speicher- und Bandbreiten Ausnutzung ausgelegt, erhöhte Datenlokalität
- Neue Architektur = garantiert bessere Skalierbarkeit von mehr Einheiten nach oben (ansonsten kann man sich das ganze ja sparen)
Also ich persönlich und die meisten anderen hier können anhand der Auflistung nicht annehmen, dass Vega nur auf Fiji Niveau + mehr Takt liegt. Das macht mM nach auch keinen Sinn. Falls es kein zweites R600 Disaster gibt, spricht momentan nichts gegen einen 1080 Ti Konkurrenten.

Digidi
2017-06-05, 14:32:55
Woher kommt denn die Taktsteigerung? Könnte es im worst case nicht sein, dass die Veränderungen nur zu höheren Taktraten führen und ansonsten doch auf fiji Niveau liegen?

Eine Taktsteigerung deutet einen Massiven Umbau Innerhalb der GPU an. Um das zu erreichen musst du die Transistoren auf der GPU komplett neu verdrahten.

So ganz verstehe ich es auch nicht. Aber man muss auf jedenfall die Signalwege verkürzen oder die Anzahl der Transisotren verdoppeln um den Wiederstand für das Signal klein zu halten. Könnte mir gut vorstellen das man mehr Refresh Transistoren eingebaut hat die direkt an die 1V angeschlossen sind und nichts anderes machen als das Signal wieder aufzufrischen, ansonsten verliert sich das Signal bei hohen Taktraten am Ende.

Eldoran
2017-06-05, 15:10:58
Wie die Taktratensteigerung erreicht wurde ist derzeit einmal unbekannt. In diesem Fall sind auf jedem Fall deutliche Änderungen bei den Transistoren passiert, einfach weil der Fertigungsprozess sich deutlich unterscheidet. Bei einer CPU wären auch klassisch mehr Stufen in der Pipeline anzunehmen. Da kommen noch so Sachen wie Transistorgeometrie oder Wahl der jeweiligen logisch äquivalenten Transistorschaltung hinzu oder die von Digidi erwähnten Dinge. Wobei anzunehmen ist, dass sich bei den Signalwegen einiges geändert hat, schon allein um die ganzen neuen Funktionen (wie Primitive Shader) zu implementieren. Infinity Fabric wäre da auch noch zu erwähnen.

Nachdem aber schon entsprechend schnell laufende Samples bekannt sind, ist anzunehmen, dass das soweit geklappt hat. Und wie schon erwähnt, es ist nicht zu erwarten, dass sich diese Änderungen negativ auf die IPC auswirken und damit die Vorteile wieder auffressen.
An sich ist bei so etwas immer die Gefahr, dass bei einer Taktratensteigerung der Strombedarf und/oder der Flächenbedarf so ansteigt, dass pro Fläche nicht mehr Leistung herausschaut.

Linmoum
2017-06-05, 15:30:45
Auf der Siggraph wird nun eine Präsentation von AMD erwartet und aus der soll eine nun geleakte Folie stammen [...]
http://www.pcgameshardware.de/Vega-Codename-265481/News/Laut-gelakter-Praesentationsfolie-schneller-als-Titan-Xp-1229586/

Mal ganz ehrlich, wer schreibt da eigentlich mittlerweile die Artikel bei PCGH? :freak:
Nicht nur, dass unten links NDA vom 8. Mai steht... nein, die "Folie" geistert auch schon seit längerem durch die Weiten des Internets. "Nun" geleakt... ;D

https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11350338&postcount=3020

BlacKi
2017-06-05, 15:52:00
Wenn du keine AHnung hast, wäre es schön, wenn du dich bedeckt halten würdest - DANKE!

Irgendeine sinnlose Anti-AMD Propaganda, die nur auf 'ich glaube' basiert, brauchen wir hier nicht. Hier wäre es schön, wenn du dich auf Fakten beziehen würdest. Und die widersprechen dir nunmal sehr stark.

Halten wir also mal fest:
Ohne Architekturverbesserungen hat VEGA schon mal +50% Takt.
DAS wäre also schon mal in der Region, in der du ganz doll und fest glaubst, dass VEGA landen wird. DAS wäre der Worst Case.
dein rumgeheule machts aber auch nicht besser... musst du jedes mal wenn einer seine meinung hier lässt rumbellen wie so n hund, der sein revier verteidigt?:rolleyes:

btt:
wie schon erwähnt machen 50% mehr takt keine 50% mehr performance, weder bei fiji noch bei vega.

zudem, und das soll kein bashing sein, sondern ist einfach tradition, das die release treiber leider das nicht wiederspiegeln welche performance vega später abliefern könnte. deshalb könnte ich mir die 1080ti performance in einem jahr gut vorstellen, aber im august werden wir diese performance wohl nicht sehen.

AlphaNUSS
2017-06-05, 15:56:07
Da Vega jetzt erst so spät kommt, kann ich mir vorstellen, dass die Treiber zu Release schon gut was taugen.

OgrEGT
2017-06-05, 17:50:47
http://www.pcgameshardware.de/Vega-Codename-265481/News/Laut-gelakter-Praesentationsfolie-schneller-als-Titan-Xp-1229586/

Mal ganz ehrlich, wer schreibt da eigentlich mittlerweile die Artikel bei PCGH? :freak:
Nicht nur, dass unten links NDA vom 8. Mai steht... nein, die "Folie" geistert auch schon seit längerem durch die Weiten des Internets. "Nun" geleakt... ;D

https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11350338&postcount=3020

Was wäre das für ein Paukenschlag wenn es so kommt XD

dargo
2017-06-05, 17:55:47
Bitte nicht schon wieder über diese Schwachsinnsfolie diskutieren. :usad: Oder hast du schon mal gesehen, dass GP102 89% schneller als GP104 ist? Ich noch nicht. Es sei denn in 4k geht GP104 der Vram stellenweise aus. Kann ich mir aber kaum vorstellen, dass für 4k >8GB in Doom @Vulkan nötig sind.

OgrEGT
2017-06-05, 18:09:54
Schon klar... ich glaube auch dass die Folie nicht unbedingt echt ist... für den Markt an sich wäre aber eine überzeugende Leistung von Vega nur gut damit es endlich wieder Konkurrenz gibt :)

OgrEGT
2017-06-05, 18:14:23
Weiß jemand wann genau die Vega FE Karten an die Reviewer versendet werden also wann wir ca mit Leaks rechnen können?

Screemer
2017-06-05, 18:26:34
Da sich die frontier Edition an ein professionelles Klientel richtet bezweifle ich, dass gaming Redakionen bermustert werden. Da ist wohl Eigeninitiative gefragt und das kann ohne Sourcen bei oems teuer werden.

reaperrr
2017-06-05, 19:39:36
Da sich die frontier Edition an ein professionelles Klientel richtet bezweifle ich, dass gaming Redakionen bermustert werden. Da ist wohl Eigeninitiative gefragt und das kann ohne Sourcen bei oems teuer werden.
Denke ich auch. Zumal die FE nicht das schnellste Modell für Gamer wird (laut Raja höchstselbst), und dann bewirbt man es auch lieber nicht als Gamer-Karte.

Tamagothi
2017-06-05, 19:50:58
Es wird mit 1000% Reviews geben. Nur um zu sagen wir waren erster.

deekey777
2017-06-05, 19:57:28
iMac Pro bekommt Vega mit 11 TFLOPS/22 TFLOPS Half.

yamamoto_dc
2017-06-05, 19:58:34
iMac Pro bekommt Vega mit 11 TFLOPS/22 TFLOPS Half.

Mist schneller... ;-)

Linmoum
2017-06-05, 19:58:55
Und bis zu 16GB.

Nakai
2017-06-05, 20:09:29
Das ist schonmal eine Ansage. Vor allem wenn man bedenkt, dass der Formfaktor im iMac eher kleiner ausfallen sollte. Ein ziemlich fetter Design-Win und Vega ist noch nichtmal am Start. Nun wird es auch langsam klar, wieso Vega wieder später kommt. Die Chips gehen an Apple.

fondness
2017-06-05, 20:12:44
Das Apple Vega nimmt war klar. Apple braucht eine GPU nicht primär für Spiele, Apple braucht einen schnellen Streamprozessor und da ist GCN nach wie vor eine Bank. Nicht umsonst kaufen auch die Miner die AMD-Karten leer.

zer0fx
2017-06-05, 20:13:25
iMac Pro bekommt Vega mit 11 TFLOPS/22 TFLOPS Half.

Quelle?

Nakai
2017-06-05, 20:14:18
Quelle?

https://twitter.com/GFXChipTweeter?lang=de

deekey777
2017-06-05, 20:14:23
Quelle?
Glaskugel.

Das Apple Vega nimmt war klar. Apple braucht eine GPU nicht primär für Spiele, Apple braucht einen schnellen Streamprozessor und da ist GCN nach wie vor eine Bank. Nicht umsonst kaufen auch die Miner die AMD-Karten leer.

Oder AMD hat einfach ein besseres Angebot gemacht.

fondness
2017-06-05, 20:15:37
Quelle?

Von der Apple WWDC:

https://s13.postimg.org/igniv9l7r/Screen-_Shot-2017-06-05-at-10.56.26-_PM.png (https://postimg.org/image/d58majz4z/)

https://s13.postimg.org/m1jeehprb/Screen-_Shot-2017-06-05-at-10.56.03-_PM.png (https://postimg.org/image/v9bmv6wtf/)

dargo
2017-06-05, 20:16:00
Quellen sind schon was ganz feines. :rolleyes:
http://www.macgadget.de/News/2017/06/05/Apple-iMac-Pro-mit-bis-zu-18-Xeon-Prozessorkernen-Radeon-Vega-Grafikkarte-und-ECC-Sp

Nakai
2017-06-05, 20:18:02
Glaskugel.

Oder AMD hat einfach ein besseres Angebot gemacht.

Apple hat den Fokus auf OpenCL. Der OpenCL-Support von NV ist grottig. Und NV würde eher Cuda auf den Apples durchdrücken wollen.

deekey777
2017-06-05, 20:28:53
Apple hat den Fokus auf OpenCL. Der OpenCL-Support von NV ist grottig. Und NV würde eher Cuda auf den Apples durchdrücken wollen.
Unterstützt Apple überhaupt neuere OpenCL-Versionen als 1.2?

Hinzu kommt, dass High Sierra mehr auf Metal/Metal 2 setzt.

Nakai
2017-06-05, 20:33:00
Unterstüzt Apple überhaupt neuere OpenCL-Versionen als 1.2?

Hinzu kommt, dass High Sierra mehr auf Metal/Metal 2 setzt.

Tatsache:

https://support.apple.com/de-de/HT202823

Maximal OpenCL 1.2.

deekey777
2017-06-05, 20:43:17
Tatsache:

https://support.apple.com/de-de/HT202823

Maximal OpenCL 1.2.


OT:
Apple war die treibende Kraft hinter OpenCL, aber spätestens mit Metal haben sie Lust an OpenCL verloren.

Noch mehr OT:

Glaubt hier jemand wirklich nach der heutigen Präsentation an kombinierte SoCs aus Intel-CPU und Radeon? Es sei denn, Apple bringt noch einen Mac Mini mit so einer Kombi.

Nakai
2017-06-05, 20:46:22
OT:
Apple war die treibende Kraft hinter OpenCL, aber spätestens mit Metal haben sie Lust an OpenCL verloren.

Noch mehr OT:

Glaubt hier jemand wirklich nach der heutigen Präsentation an kombinierte SoCs aus Intel-CPU und Radeon? Es sei denn, Apple bringt noch einen Mac Mini mit so einer Kombi.

Womöglich bietet Intel nur die Möglichkeit hierfür. Eventuell setzt das Apple dann einfach um. Ich frage mich nur, welche AMD GPU reinkommen könnte. Vega11?

fondness
2017-06-05, 20:47:08
Glaubt hier jemand wirklich nach der heutigen Präsentation an kombinierte SoCs aus Intel-CPU und Radeon? Es sei denn, Apple bringt noch einen Mac Mini mit so einer Kombi.

Das hat schon AMD ziemlich deutlich negiert. Also nein. Vielleicht als Kombination on package, aber sicher nicht als SoC.

gravitationsfeld
2017-06-05, 20:51:13
Apple hat den Fokus auf OpenCL. Der OpenCL-Support von NV ist grottig. Und NV würde eher Cuda auf den Apples durchdrücken wollen.
Spielt keine Rolle, Apple schreibt alle Treiber selber.

Troyan
2017-06-05, 21:43:28
Grafik
Vega GPU

Radeon Pro Vega 56 Grafikprozessor mit 8 GB HBM2 Grafikspeicher
Optional mit Radeon Pro Vega 64 Grafikprozessor mit 16 GB HBM2 Grafikspeicher


https://www.apple.com/de/imac-pro/specs/

Einstiegsgerät wird wohl weniger als 10TFLOPs haben.

Digidi
2017-06-05, 21:49:57
Spielt keine Rolle, Apple schreibt alle Treiber selber.
Ja Apple schreibt seine Treiber selbst. Aber so kann Nvidia auch wieder Cuda durchdrücken. Man supportet Apple einfach nicht beim schreiben der Treiber. Bin mal gespannt wie erfolgreich das dann ist. :wink:

Locuza
2017-06-05, 21:50:24
Die englische Seite spricht noch von bis zu 400GB/s:
On-package HBM2 replaces external VRAM, so the GPU can fetch data at up to 400GB/s.

https://www.apple.com/imac-pro/

basix
2017-06-05, 21:53:58
Interessant ist die Namensgebung Vega 64 und Vega 56. Somit 56 NCUs / 3584 Shader für den Salvage Part?

Dazu die Ansage "over 3 times faster than any prior iMac GFX". Was war das? Tonga?

Digidi
2017-06-05, 21:54:55
Wegen der kompakten Kühllösung die auch noch Leise sein muss wird man wohl die vollen Chips mit weniger Takt anbrigen.

Immerhin 16GB Vram.

Jetzt weiß man auch warum Vega später kommt. Man produziert massive für Apple vor.

gedi
2017-06-05, 22:05:06
Interessant ist die Namensgebung Vega 64 und Vega 56. Somit 56 NCUs / 3584 Shader für den Salvage Part?

Dazu die Ansage "over 3 times faster than any prior iMac GFX". Was war das? Tonga?

Bestellen könnte man derzeit max. einen 27" iMac mit einer Radeon Pro 580 8G

https://www.apple.com/de/mac/compare/results/?product1=imac-retina-21&product2=imac-retina-27

Kartenlehrling
2017-06-05, 22:07:44
Jetzt weiß man auch warum Vega später kommt. Man produziert massive für Apple vor.

Ab Dezember erhältlich

Nicht wirklich :)

Mancko
2017-06-05, 22:11:52
Nicht wirklich :)

Vor allem weiß man sowas vorher und ordert entsprechend Kapazitäten. Das Teil ist einfach später weil es später ist. Entweder lags an HBM2 oder an der GPU selber. Ist doch am Ende egal warum. Später bleibt halt später.

transstilben
2017-06-05, 22:18:40
Bis zu 500 Watt auf dem Schreibtisch. Trotzdem extrem lecker der iMac pro.

Troyan
2017-06-05, 22:25:00
Interessant ist die Namensgebung Vega 64 und Vega 56. Somit 56 NCUs / 3584 Shader für den Salvage Part?

Dazu die Ansage "over 3 times faster than any prior iMac GFX". Was war das? Tonga?

Der Mülleimer hat 2x Tonga: https://www.apple.com/mac-pro/specs/

Aber 11TFLOPs entsprechend exakt 3x D700.

Die englische Seite spricht noch von bis zu 400GB/s:

https://www.apple.com/imac-pro/

Es werden wahrscheinlich 400GB/s für iMac Pro sein. Weniger Bandbreite = weniger Stromverbrauch.

Linmoum
2017-06-05, 22:30:35
Bin gespannt, ob man das auch für den Desktop so handhaben wird.

Full Vega mit 16GB, der Salvage mit 8GB. Wobei ich das eigentlich für unwahrscheinlich halte.

MR2
2017-06-05, 22:34:39
https://videocardz.com/newz/amd-releases-vega-gpu-die-shot

yamamoto_dc
2017-06-05, 23:08:38
Wurde die Analystenkonferenz mit Jim Anderson von heute schon diskutiert?

In the in the Ryzen, Ryzen processor is just as an example, we've launched seven versions of the Ryzen processor to-date and if you look at those seven versions relative to their Intel competitor that's most nearly priced competitor you'll see we're bringing anywhere from 30%, sometimes over 70% performance advantage. And when we launch our Vega graphics processor that's coming very shortly, it will come later this month, you'll see similar level of competitive performance in high-end part of the desktop or high-end part of the graphics market.

https://seekingalpha.com/article/4078955-advanced-micro-devices-amd-management-presents-stifel-nicolaus-2017-technology-internet-and?part=single

Vega scheint ein großer Wurf zu werden.

Linmoum
2017-06-05, 23:19:22
https://videocardz.com/newz/amd-releases-vega-gpu-die-shot
8 Shader Engines?

Raja hatte mit seinem "es gibt ja Samsung und Hynix die produzieren" beim AMA schon so ein wenig etwas angedeutet, aber HBM2 (auch) von Samsung wäre schon interessant. Vor allem dann, wenn es ebenfalls die 8Hi Stacks betrifft.

Blediator16
2017-06-05, 23:24:59
Vor allem weiß man sowas vorher und ordert entsprechend Kapazitäten. Das Teil ist einfach später weil es später ist. Entweder lags an HBM2 oder an der GPU selber. Ist doch am Ende egal warum. Später bleibt halt später.

Hast recht. In den Sinn kommt dir wohl nicht, dass es auch an Intels 18 Kern Xeons liegen könnte?

Digidi
2017-06-05, 23:37:42
8 Shader Engines?


Vega hat 4 Shader Engines.

Nakai
2017-06-05, 23:38:00
8 Shader Engines?

Raja hatte mit seinem "es gibt ja Samsung und Hynix die produzieren" beim AMA schon so ein wenig etwas angedeutet, aber HBM2 (auch) von Samsung wäre schon interessant. Vor allem dann, wenn es ebenfalls die 8Hi Stacks betrifft.

Im Treiber sind es 4. Aber wie diese intern aufgebaut sind, weiß man noch nicht. 8 Rasterizer sind sehr naheliegend.

Digidi
2017-06-05, 23:40:54
Im Treiber sind es 4. Aber wie diese intern aufgebaut sind, weiß man noch nicht. 8 Rasterizer sind sehr naheliegend.
Wie geht das 8 Rasterizer mit 4 Shader Engines???

Immerhin würde dies die 11 Polygonen erklären und würde für eine Massive Tesselationleistung sprechen.

Hmm 8 ist das nicht Overkill? Der GV100 hat auch nur 6 Rasterizer. 6 sind doch mehr als genug?

Setsul
2017-06-05, 23:42:19
Hat sich eigentlich schon irgendjemand überlegt, dass Hynix/Samsung vielleicht einfach mit der Reihenfolge nicht ganz glücklich sind?
V11 sollte eigentlich >50% V10 sein, sonst wird der Abstand zu groß. Ich glaube auch nicht dass AMD zu sehr am Speicher hängen will, 1024 bit mehr brauchen nicht so viel Platz und wenn man nicht auf sehr interessante Formen ausweicht ist der Interposer sowieso genauso groß, also scheinen 2 Stacks logisch. Das bedeutet niedrigerer Takt (z.B. 1,6 GHz) wäre ausreichend.
Für den vollen V10 hätte AMD gerne 2,0 GHz. Salvage mit z.B. 56/64 sollte auch eher 1,8 als 1,6 bekommen.
Was kommt zuerst?
Das ist exakt die umgekehrte Reihenfolge die man während des Ramp Ups gerne hätte. Weder Samsung noch Hynix sind scharf darauf, dass AMD monatelang nur >1,8 GHz kauft und sie auf dem Rest sitzenbleiben bis V11 kommt.

Nur so ein Gedanke.

Eldoran
2017-06-06, 00:54:06
@setsul: Nun, es wäre vermutlich einfacher zuerst die weniger anspruchsvollen Teile zu fertigen, aber AMD ist nicht der einzige Abnehmer von HBM2. Mittlerweile ist das nicht nur bei nvidia im Gebrauch, sondern auch auf diversen ICs, die wir niemals zu Gesicht bekommen werden. Auch die Interposer Geschichte ist mittlerweile durchaus in Gebrauch.

Nakai
2017-06-06, 01:04:46
Außerdem, der Dieshot sieht ziemlich nach Bullshot aus. Nett nachbearbeitet, um Details zu überdecken. Einfach mal abwarten.

mczak
2017-06-06, 01:11:57
Der Mülleimer hat 2x Tonga: https://www.apple.com/mac-pro/specs/
Nein, das Teil ist VIEL zu alt für Tonga. Das sind Original GCN 1.0 GPUs, die ältesten die's überhaupt gibt - Tahiti.

(edit: der einzige Unterschied zur Originalkonfiguration von 2013 bzgl. GPU (bei den CPUs sieht's ähnlich aus) ist es gibt die Dual D300 als Standardkonfiguration nicht mehr - das war 2xPitcairn.)

Eldoran
2017-06-06, 01:42:24
Außerdem, der Dieshot sieht ziemlich nach Bullshot aus. Nett nachbearbeitet, um Details zu überdecken. Einfach mal abwarten.
Bei Polaris gab es auch so etwas, das hat sich auch als korrekt herausgestellt.
http://www.pcgameshardware.de/screenshots/970x546/2016/06/Polaris-P10-Summary-und-Die-Shot-pcgh.jpg
etwas detailierter:
http://diit.cz/sites/default/files/polaris_10_die_layout.png
zum vergleich ein "echter" die shot:
https://www.reddit.com/r/Amd/comments/4xf6n7/so_i_decided_to_annotate_the_polaris_10_die_shot/

nebenbei bemerkt, das hat große Ähnlichkeiten mit dem angeblichen von Vega.

Gipsel
2017-06-06, 01:56:29
Bei Polaris gab es auch so etwas, das hat sich auch als korrekt herausgestellt.
http://www.pcgameshardware.de/screenshots/970x546/2016/06/Polaris-P10-Summary-und-Die-Shot-pcgh.jpg
etwas detailierter:
http://diit.cz/sites/default/files/polaris_10_die_layout.pngNa kommt drauf an, was Du als "korrekt" bezeichnest. Ein Komposit aus Die-Plot (bzw. Floor-Map aus Layout-Programm) der Funktionsblöcke am Rande mit einem verfremdeten und mehr einem Blockdiagramm ähnelndem Part in der Mitte ist nunmal kein Die-Shot (also ein echtes Foto).
zum vergleich ein "echter" die shot:
https://www.reddit.com/r/Amd/comments/4xf6n7/so_i_decided_to_annotate_the_polaris_10_die_shot/Das ist einer. Leider sind dort einige Sachen grob falsch eingezeichnet (z.B. enthalten die Blöcke mit den angeblichen Render-Backends zwei der vier SIMDs der CUs :rolleyes:). Aber egal.
nebenbei bemerkt, das hat große Ähnlichkeiten mit dem angeblichen von Vega.Das ist maximal eine grobe Version der Floormap, die jemand über ein Foto des Packages gelegt hat.

Digidi
2017-06-06, 06:11:14
Außerdem, der Dieshot sieht ziemlich nach Bullshot aus. Nett nachbearbeitet, um Details zu überdecken. Einfach mal abwarten.

Da es direkt von AMD kommt glaube ich nicht das es ein Bullshot ist. Natürlich verbergen sie einiges aber das grobe Layout sollte stimmen, sonst wäre das bewusste Irreführung, das käme nicht gut bei den Aktionären an. Also sind 8 Shaderblöcke gesichert. Die Frage ist nun ob vor oder nach dem Rasterizer es von 4 auf 8 geht :confused:

basix
2017-06-06, 07:21:31
Wenn ich schätzen müsste sähe ich überall Vielfache von 8 was die Shader Arrays anbelangt. Schön zu sehen ist das HBM Interface. Sieht für mich aber ein wenig gross aus? Und das dazwischen / daneben ist der HBCC?

mironicus
2017-06-06, 10:30:46
Was meint ihr? Wird der größte Vega wie im Mac Pro auch gleich mit 16 GB HBM2 als Gamerkarte erscheinen?

Brillus
2017-06-06, 10:37:33
Da es direkt von AMD kommt glaube ich nicht das es ein Bullshot ist. Natürlich verbergen sie einiges aber das grobe Layout sollte stimmen, sonst wäre das bewusste Irreführung, das käme nicht gut bei den Aktionären an. Also sind 8 Shaderblöcke gesichert. Die Frage ist nun ob vor oder nach dem Rasterizer es von 4 auf 8 geht :confused:
Wobei AMD mal im interview gesagt hat, das sie nie ungephotoshopte Die-shots raus geben, wegen Geheimnisse und so. (War 1-2 Jahre her hab keinen Link dazu bevor du fragst).

Der_Korken
2017-06-06, 10:46:11
Warum sind die CUs bei AMD eigentlich so extrem länglich? Bei dem Vega-Shot sieht es sogar noch extremer aus als bei den vorigen GPUs. Wäre es nicht besser alles zusammengehörende auch räumlich dicht beisammen zu haben wegen kürzerer Signallaufwege oder hab ich da einfach ganz falsche Vorstellungen? Bei Nvidia sind die SMs deutlich quadratischer.

Edit: Kann man erahnen, was die 24 Rechtecke zwischen CUs und HBM PHYs ist? Sind 64 ROPs sicher oder könnten es auch 96 (24*4) sein?

bloub
2017-06-06, 10:47:54
Ein ziemlich fetter Design-Win und Vega ist noch nichtmal am Start. Nun wird es auch langsam klar, wieso Vega wieder später kommt. Die Chips gehen an Apple.

5000 dollar für das kleinste modell, soviele vega chips wird apple also nicht brauchen bis zum marktstart.

Nakai
2017-06-06, 11:05:34
Das sagte ich nicht. Wie bei Tonga, bekommt Apple erstmal die XXUTLRABESTFABRICATED-VEGAs, dann kommt der professionelle Markt und dann wir...die Gamer. Die Reihenfolge und nicht anders.:)

Troyan
2017-06-06, 12:22:08
Frontier-Edition in einem eGPU-Gehäuse an einem Notebook: http://www.3dmark.com/compare/3dm11/12202976/3dm11/12028898#

Eldoran
2017-06-06, 12:27:50
Nein, es sind tatsächlich 4 Shader Engines, nur die NCU sind wie bei Polaris effektiv als 2 gespiegelte Blöcke pro Shader Engine am Die angeordnet. Wie bei Polaris sind zwischen den beiden 4-er Gruppen NCU die Restlichen Teile der Shader Engines zu finden - oben 2 blöcke von 2 Shader Engines, dann etwas anders, dann die restlichen 2 - genau wie bei Polaris.
Allerdings sind laut pseudo-die shot die NCU jeweils in 2 blöcke getrennt. sofern das am Die tatsächlich so ist, dürfte das wohl wie bei Ryzen/CCX auf einen Unterschied bei der Kommunikation hindeuten (etwa diese Blöcke sind jeweils als Einheit, die per IF mit den anderen Funktionseinheiten verbunden und teilen sich einen Controller/Bandbreite).
Das könnte zu einer anderen Spekulation passen, dass eben je nach Auslastung Ressourcen verschoben werden können, das könnte bedeuten, dass je nach Auslastung der jeweiligen NCU in den Shader Engines diese Blöcke an eine andere verliehen werden können.
Die jeweils 8 Klötzchen Linien könnten die ROPs sein. Sind die zwei je 3x4 Blöcke unten der L2?

fondness
2017-06-06, 12:31:29
Oder es sind doch 8 Shader-Engines. :)

dargo
2017-06-06, 12:31:51
Frontier-Edition in einem eGPU-Gehäuse an einem Notebook: http://www.3dmark.com/compare/3dm11/12202976/3dm11/12028898#
Ich könnte wetten daraus leiten gleich wieder welche die Desktopperformance von Vega ab. GTX1070 Speed = Fail. ;D

DrumDub
2017-06-06, 12:33:24
Frontier-Edition in einem eGPU-Gehäuse an einem Notebook: http://www.3dmark.com/compare/3dm11/12202976/3dm11/12028898# noe.

Screemer
2017-06-06, 12:35:04
Frontier-Edition in einem eGPU-Gehäuse an einem Notebook: http://www.3dmark.com/compare/3dm11/12202976/3dm11/12028898#
der treiber ist auf jeden fall schon mal einer, der nicht veröffentlicht ist.

schick ist aber beim frontier system: Maximum turbo core clock 897 MHz

Gipsel
2017-06-06, 12:43:59
der treiber ist auf jeden fall schon mal einer, der nicht veröffentlicht ist.Und mit aktueller Nomenklatur auch erst im Jahre 2022 veröffentlicht wird? Hmm, vielleicht doch eher ein Fake mit einer nV-GPU. ;)

deekey777
2017-06-06, 12:55:11
Das hat schon AMD ziemlich deutlich negiert. Also nein. Vielleicht als Kombination on package, aber sicher nicht als SoC.
Ich bin zwar bei den Begrifflichkeiten durcheinandergekommen, aber die Message ist die gleiche:

So lange niemand das neue 15'' MacBook Pro oder den großen iMac aufmacht und feststellt, dass auf dem Package eine Radeon sitzt, so wird es in diesem Jahr eine solche Kombi nicht geben.

Achill
2017-06-06, 13:09:23
Und mit aktueller Nomenklatur auch erst im Jahre 2022 veröffentlicht wird? Hmm, vielleicht doch eher ein Fake mit einer nV-GPU. ;)

VEGA für 2022 *confirmed* ... ;) :weg:

basix
2017-06-06, 13:36:35
Das ist die Apple Nomenklatur. Vega 2022 anstatt Vega 64 / 56. 2022*64 = 129'408 Shader :D

Screemer
2017-06-06, 13:37:55
Und mit aktueller Nomenklatur auch erst im Jahre 2022 veröffentlicht wird? Hmm, vielleicht doch eher ein Fake mit einer nV-GPU. ;)
gibt einen haufen fury benches in der db mit ähnlichen strings für treiber. dabei handelt es sich wohl um die windows driver store version:

Radeon Software Crimson ReLive Edition 17.4.4 Driver Version 17.10.1731. (Windows Driver Store Version 22.19.162.4)

Gipsel
2017-06-06, 14:26:56
gibt einen haufen fury benches in der db mit ähnlichen strings für treiber. dabei handelt es sich wohl um die windows driver store version:

Radeon Software Crimson ReLive Edition 17.4.4 Driver Version 17.10.1731. (Windows Driver Store Version 22.19.162.4)
Ich würde mal pauschal behaupten, daß Vega mit irgendeiner Version aus dem Windows Driver Store nicht (vernünftig) läuft.

Hübie
2017-06-06, 14:40:54
Wer weiß. Ich kenne es zumindest von NV das Treiber oftmals schon Code für die next gen drin hat, aber per inf nicht eingepflegt wird. So pauschal würde ich es also nicht abtun. Über eGPU verliert man iirc 10-15% Leistung und niemand sagt dass es sich bei dem Modell um den top dog handelt (wenn es denn kein Fake ist).
Oder es ist einfach nur ein Fake. :D

Nakai
2017-06-06, 14:48:47
Oder es sind doch 8 Shader-Engines. :)

Wir kennen den internen Aufbau nicht. In einer Präsi wurde gesagt, dass Vega 4 Geometry-Engines hat. Im Treiber sind von 4 ShaderEngines die Rede. Eventuell hat jede Shader-Engine zwei Shader-Arrays mit je 8 NCUs. Davor gibt es eben jeweils einen Rasterizer.

Ich denke der interne Aufbau der Shader Engines wird etwas verschieden sein, als manche annehmen.

deekey777
2017-06-06, 14:57:16
Spielt keine Rolle, Apple schreibt alle Treiber selber.
Gilt das für alle Treiber oder nur für OpenCL? Denn erst im April hat Nvidia Pascal-Treiber für macOS veröffentlicht.

HOT
2017-06-06, 15:26:17
Gilt das für alle Treiber oder nur für OpenCL? Denn erst im April hat Nvidia Pascal-Treiber für macOS veröffentlicht.
Das war mMn pure Verzweiflung, weil Apple den Markt für NV einfach dicht gemacht hat. Ob das jemals einer nutzen wird...

dildo4u
2017-06-06, 15:29:08
Mich wundern die ganzen Apple Deals,Pascal würde deutlich besser passen wenn man sieht wie kompakt die Geräte sind.Vega muss ja schon deutlich langsamer laufen um in den neuen iMac Pro zu passen.

pilzsammler2002
2017-06-06, 15:30:49
Vega muss ja schon deutlich kühler laufen um in den neuen iMac Pro zu passen.
FTFY :freak:

fondness
2017-06-06, 15:34:43
Mich wundern die ganzen Apple Deals,Pascal würde deutlich besser passen wenn man sieht wie kompakt die Geräte sind.Vega muss ja schon deutlich langsamer laufen um in den neuen iMac Pro zu passen.

AMDs CGN Architektur ist der wesentlich flexiblere und schnellere Co-Prozessor. Pascal wäre vielleicht besser als Spiele-GPU, aber dafür braucht Apple das Ding nicht. Nicht umsonst kaufen die Miner die AMD-Karten leer und verwenden auch nur als zweite Wahl Nvidia-Karten.

Screemer
2017-06-06, 15:35:45
Ich würde mal pauschal behaupten, daß Vega mit irgendeiner Version aus dem Windows Driver Store nicht (vernünftig) läuft.
irgend ein treiber ist es auf jeden fall nicht, denn der aktuellste 17.5.2 hat als windows driver store number 22.19.165.512. 17.5.1 hat 22.19.165.1. scheint also zumindest ein treiber branch zu sein, der noch nicht das licht der öffentlichkeit gesehen hat.

HOT
2017-06-06, 15:37:09
Seit Tonga gibts ja auch GPU-Virtualisierung, FP16 usw., daran wird Apple großes Interesse haben. Bietet Pascal ja alles nicht. Und die verschlafene Erneuerung des Mac Pro fällt ja gut mit der Vega-Generation zusammen, wieso also auf den featurearmen Pascal wechseln.



AMD wollte doch nen komplett neuen Shadercompiler wegen Vega schreiben, kein Wunder, dass da ein neuer Branch fällig ist.

deekey777
2017-06-06, 15:39:36
Das war mMn pure Verzweiflung, weil Apple den Markt für NV einfach dicht gemacht hat. Ob das jemals einer nutzen wird...
Wenn man eine externe Pascal anschließen will, dann wird man den Treiber auch nutzen. Hinzu kommt noch Hackintosh (da haben sich die Nutzer noch mehr gefreut).

HOT
2017-06-06, 15:42:14
Wenn man eine externe Pascal anschließen will, dann wird man den Treiber auch nutzen. Hinzu kommt noch Hackintosh (da haben sich die Nutzer noch mehr gefreut).
Ja, super für die 0,0000001% die das nutzen.

Hübie
2017-06-06, 15:49:46
Korrekterweise bietet es nur GP100 und alle Maxwells. Aber das wird Apple schlicht zu teuer und abgeregelt sein, so dass man mit AMD besser fährt.

vinacis_vivids
2017-06-06, 16:33:52
Was meint ihr? Wird der größte Vega wie im Mac Pro auch gleich mit 16 GB HBM2 als Gamerkarte erscheinen?

Eher nein. Die 16GB HBM2 bringen bei Games nichts außer Kosten. Im Pro Bereich sieht es anders aus.

N0Thing
2017-06-06, 16:39:09
Ich würde mal pauschal behaupten, daß Vega mit irgendeiner Version aus dem Windows Driver Store nicht (vernünftig) läuft.

Warum nicht? Sollte doch nur ein anderer Name für die gleiche Software sein.
Zudem wird auch bei anderen Ergebnissen diese Art der Treiberbezeichnung ausgelesen: http://www.3dmark.com/compare/3dm11/11947367/3dm11/11856175#

uweskw
2017-06-06, 17:00:26
Eher nein. Die 16GB HBM2 bringen bei Games nichts außer Kosten. Im Pro Bereich sieht es anders aus.

Dann bleibt nur zu hoffen, dass die HW-Tester den 8GB HBM gründlich auf den Zahn fühlen ob die wirklich in allen Real-World-Anwendungen ausreichen.

greetz
US

dildo4u
2017-06-06, 17:02:58
Die Bandbreite wird eher das Problem sein wenn die 8GB Version wirklich nur mit 400GB/sec läuft.

Screemer
2017-06-06, 17:03:38
Warum nicht? Sollte doch nur ein anderer Name für die gleiche Software sein.
Zudem wird auch bei anderen Ergebnissen diese Art der Treiberbezeichnung ausgelesen: http://www.3dmark.com/compare/3dm11/11947367/3dm11/11856175#
you don't say ;)

https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11394452#post11394452

dargo
2017-06-06, 17:13:35
Dann bleibt nur zu hoffen, dass die HW-Tester den 8GB HBM gründlich auf den Zahn fühlen ob die wirklich in allen Real-World-Anwendungen ausreichen.

Könnte schwierig werden, selbst ohne HBCC.

N0Thing
2017-06-06, 17:18:02
you don't say ;)

https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11394452#post11394452

Habe ich gelesen. Ich wollte aber von Gipsel wissen, warum ein Treiber aus dem Windows Driver Store mit Vega nicht (vernünftig) laufen sollte.

Gipsel
2017-06-06, 17:25:31
Warum nicht? Sollte doch nur ein anderer Name für die gleiche Software sein.Weil die typischerweise etwas hinterherhinken, was neue Treiber angeht. Das könnten also z.B. die sein, mit denen die ersten Demos vor ein paar Monaten liefen (gerüchteweise leicht modifizierte Fiji-Treiber). Den aktuellen Branch mit allem drum und dran hat AMD vermutlich einfach noch nicht an MS geschickt. Da werden die wohl noch bis kurz vor dem Launch dran basteln.

Digidi
2017-06-06, 17:27:18
Wir kennen den internen Aufbau nicht. In einer Präsi wurde gesagt, dass Vega 4 Geometry-Engines hat. Im Treiber sind von 4 ShaderEngines die Rede. Eventuell hat jede Shader-Engine zwei Shader-Arrays mit je 8 NCUs. Davor gibt es eben jeweils einen Rasterizer.

Ich denke der interne Aufbau der Shader Engines wird etwas verschieden sein, als manche annehmen.

Das könnte ein logischer Schritt sein 4 Geometrie Engines und 8 Rasterizer. Die 4 Geometrie Engines fügen ja sozusagen noch Polygonen (Dreiecke) zum bestehenden Netzt hinzu. Da man dann ja Massiv mehr Polygonen hat, braucht man jetzt praktisch 8 Rasterizer um die Polygonen aus der CPU und die zusätzlichen Polygonen aus der Geometrie Engine in Pixel umzuwandeln. Klingt schlüssig.

Screemer
2017-06-06, 17:40:06
Weil die typischerweise etwas hinterherhinken, was neue Treiber angeht. Das könnten also z.B. die sein, mit denen die ersten Demos vor ein paar Monaten liefen (gerüchteweise leicht modifizierte Fiji-Treiber). Den aktuellen Branch mit allem drum und dran hat AMD vermutlich einfach noch nicht an MS geschickt. Da werden die wohl noch bis kurz vor dem Launch dran basteln.
ich glaub da hast du was missverstanden. windows hält auch mit extra setup installierte treiber im treiber store vor. das hat jetzt erst mal nix mit treibern zu tun die ms direkt ausliefert. den 17.5.2 mit der windows driver store nummer 22.19.165.512 und auch den vorgänger 17.5.1 mit der storenummer 22.19.165.1 gibts noch nicht per windows update, denn der ist beta. der aktuellste treiber von ms wäre der 22.19.162.4 (https://www.catalog.update.microsoft.com/Search.aspx?q=rx%20580) und das ist der hotfix 17.4.4. es ist also durchaus realistisch, dass 22.19.384.11 ein neuer treiber oder ein unveröffentlichter branch ist.

zu finden ist der windows driver store und quasi alle jemals installierten treiber unter C:\Windows\System32\DriverStore\FileRepository. mit dem tool DriverStore Explorer [RAPR] (https://github.com/lostindark/DriverStoreExplorer). da kann sich gigabyteweise müll ansammeln.

uweskw
2017-06-06, 17:43:33
Könnte schwierig werden, selbst ohne HBCC.

Ich gehe mal davon aus, dass in Realworld-Szenarien die 11GB der 1080Ti eher limitieren als die 8GB HBM der Vegakarte.
Ich befürchte nur, dass sich unsere superqualifizierten Youtube-HW-Tester darauf beschränken zu sagen: "8 GB sind zu wenig, denn Spiel XY belegt schon 10GB bei der 1080TI.....:freak:"

greetz
US

Troyan
2017-06-06, 17:46:34
Genau, die mit 480GB/s angebundenen 11GB der GTX1080TI werden eher limitieren als die mit 480GB/s angebundenen 8GB der RX Vega Karte. :lol:

Manche haben eine Vorstellung von Technik. Unglaublich.

Linmoum
2017-06-06, 18:00:49
Wusste gar nicht, dass es zum HBCC schon Testberichte gibt. Wäre schön, wenn du die dann auch entsprechend verlinken könntest.

Oh, gibt es noch nicht? Sowas aber auch, dann vielleicht einfach mal nicht wieder den Trollyan geben, sondern Füße still halten und abwarten, was am Ende herumkommt.

basix
2017-06-06, 18:00:51
HBCC und so? Manche Leute haben eine Ignoranz. Unglaublich.

24p
2017-06-06, 18:15:52
Das ist halt typisch für diese Threads. Da gibt es ein paar Buzzwords und schon ist die Spekulation nach ein paar Wochen ausgemachte Sache. Wahrscheinlich ist es mit HBCC so wie mit AC. Viel Wind um fast nichts.

Troyan
2017-06-06, 18:16:29
Wusste gar nicht, dass es zum HBCC schon Testberichte gibt. Wäre schön, wenn du die dann auch entsprechend verlinken könntest.

Oh, gibt es noch nicht? Sowas aber auch, dann vielleicht einfach mal nicht wieder den Trollyan geben, sondern Füße still halten und abwarten, was am Ende herumkommt.

Wusste gar nicht, dass 16GB/s ausreichend sind für 12,5TFLOPs. Frage mich da dann, wieso AMD überhaupt teuren HBM2 Speicher verbaut, wenn ein 64bit GDDR5 Interface schon keine Limitierung mehr darstellt.

vinacis_vivids
2017-06-06, 18:17:49
Die Bandbreite wird eher das Problem sein wenn die 8GB Version wirklich nur mit 400GB/sec läuft.

Die kleine kastrierte 4GB Vega kann auch 400GB/s haben, um die 1070/1080 zu kassieren. Dafür preislich attraktiv bei 400€.

Topdog 8GB eher 512GB/s.

BlacKi
2017-06-06, 18:20:02
Ich gehe mal davon aus, dass in Realworld-Szenarien die 11GB der 1080Ti eher limitieren als die 8GB HBM der Vegakarte.
Ich befürchte nur, dass sich unsere superqualifizierten Youtube-HW-Tester darauf beschränken zu sagen: "8 GB sind zu wenig, denn Spiel XY belegt schon 10GB bei der 1080TI.....:freak:"

greetz
US
glaub ich nicht. mit 8gb läuft derzeit alles rund.

ich bin eher mal gespannt ob man den hbcc deaktivieren kann oder nicht und mögliche probleme die daraus entstehen könnten.

vinacis_vivids
2017-06-06, 18:22:24
Ohne HBCC hätte AMD gleich GDDR5 nehmen können...
Völlig sinnfreier Post.

HOT
2017-06-06, 18:25:58
Die Bandbreite wird eher das Problem sein wenn die 8GB Version wirklich nur mit 400GB/sec läuft.
Nur Salvage der Pro. Hat mit RX nix zu tun.

Das ist halt typisch für diese Threads. Da gibt es ein paar Buzzwords und schon ist die Spekulation nach ein paar Wochen ausgemachte Sache. Wahrscheinlich ist es mit HBCC so wie mit AC. Viel Wind um fast nichts.

Also das ist ja mal ne qualifizierte Aussage :freak:
Mal im ernst, was ansync compute angeht haben wir die allerersten Anfänge gesehen, viele davon nur preemtion für Pascal und viele davon FL11_0. Doom ist da schon ein anderes Kaliber.
Das wird irgendwann essenziell werden, die Frage stellt sich einfach nicht. So eine Aussage disqualifiziert einfach für ne sinnvolle Diskussion darüber. Low level + async compute + FP16 wird in Summe die klassische DX11-Implementation einfach obsolet machen, das wird da einfach nicht mehr mitkommen.

Eldoran
2017-06-06, 18:40:04
glaub ich nicht. mit 8gb läuft derzeit alles rund.

ich bin eher mal gespannt ob man den hbcc deaktivieren kann oder nicht und mögliche probleme die daraus entstehen könnten.
Deaktivieren im klassischen Sinn vermutlich nicht, dann würde ja der Vega nicht mehr funktionieren. Das wäre in etwa so sinnvoll wie bei Ryzen das DDR4 Speicherinterface zu deaktivieren.
Bei der Demo hat AMD angeblich das dem HBCC zugewiesene RAM größer oder gleich groß wie den (reduzierten) HBM gesetzt. Nebenbei bemerkt war es zumindest vor ein paar Jahren so, dass Windows automatisch die gleiche Menge RAM wie VRAM reserviert hat.

Hübie
2017-06-06, 18:58:42
ich glaub da hast du was missverstanden. windows hält auch mit extra setup installierte treiber im treiber store vor. das hat jetzt erst mal nix mit treibern zu tun die ms direkt ausliefert. den 17.5.2 mit der windows driver store nummer 22.19.165.512 und auch den vorgänger 17.5.1 mit der storenummer 22.19.165.1 gibts noch nicht per windows update, denn der ist beta. der aktuellste treiber von ms wäre der 22.19.162.4 (https://www.catalog.update.microsoft.com/Search.aspx?q=rx%20580) und das ist der hotfix 17.4.4. es ist also durchaus realistisch, dass 22.19.384.11 ein neuer treiber oder ein unveröffentlichter branch ist.

zu finden ist der windows driver store und quasi alle jemals installierten treiber unter C:\Windows\System32\DriverStore\FileRepository. mit dem tool DriverStore Explorer [RAPR] (https://github.com/lostindark/DriverStoreExplorer). da kann sich gigabyteweise müll ansammeln.

Wusste übrigens gar nicht, dass es die Installationsroutinen im Store gibt.

24p
2017-06-06, 19:12:50
Nur Salvage der Pro. Hat mit RX nix zu tun.



Also das ist ja mal ne qualifizierte Aussage :freak:
Mal im ernst, was ansync compute angeht haben wir die allerersten Anfänge gesehen, viele davon nur preemtion für Pascal und viele davon FL11_0. Doom ist da schon ein anderes Kaliber.
Das wird irgendwann essenziell werden, die Frage stellt sich einfach nicht. So eine Aussage disqualifiziert einfach für ne sinnvolle Diskussion darüber. Low level + async compute + FP16 wird in Summe die klassische DX11-Implementation einfach obsolet machen, das wird da einfach nicht mehr mitkommen.

Nicht mehr oder weniger qualifiziert als der übliche Hype hier. Und nein, essentiell wird da auch nach 2 Jahren Hype nichts. Man darf eben nicht den Fehler machen jedes kleinste Feature einer GPU Architektur mit Buzzwords zu versehen und dabei das große ganze aus dem Blick zu verlieren.

basix
2017-06-06, 19:19:58
Async Compute als "kleines" Feature zu betrachten finde ich aber auch falsch. Wird momentan nur wenig genutzt (z.B. weil Nvidia es eher schlecht als recht unterstützt und deutlicher Marktführer ist). Wenn ein einzelnes Feature zum Teil 10% oder mehr bringen kann ist das nicht unbedingt klein. Gibt es da Zahlen zu den Konsolen? Dort wird das sicher mehr genutzt, insbesondere wegen der schwachen CPU.

Hübie
2017-06-06, 19:34:45
Everything counts. Depeche Mode 1983. :D

dargo
2017-06-06, 19:39:48
Das ist halt typisch für diese Threads. Da gibt es ein paar Buzzwords und schon ist die Spekulation nach ein paar Wochen ausgemachte Sache. Wahrscheinlich ist es mit HBCC so wie mit AC. Viel Wind um fast nichts.
Keine Sorge... bis die Entwickler starken Einsatz von AC verwenden wird Nvidia nicht mehr hinterher hinken. Und dann interessierts wieder keine Sau was die letzte oder vorletzte Nvidia Generation leistet.

24p
2017-06-06, 19:41:42
Du wiederholst dich mit deinen Verschwörungstheorien.

Async Compute als "kleines" Feature zu betrachten finde ich aber auch falsch. Wird momentan nur wenig genutzt (z.B. weil Nvidia es eher schlecht als recht unterstützt und deutlicher Marktführer ist). Wenn ein einzelnes Feature zum Teil 10% oder mehr bringen kann ist das nicht unbedingt klein. Gibt es da Zahlen zu den Konsolen? Dort wird das sicher mehr genutzt, insbesondere wegen der schwachen CPU.

Die selbe Leier hört man jetzt schon seit zwei Jahren.

Hübie
2017-06-06, 19:49:47
Keine Sorge... bis die Entwickler starken Einsatz von AC verwenden wird Nvidia nicht mehr hinterher hinken. Und dann interessierts wieder keine Sau was die letzte oder vorletzte Nvidia Generation leistet.

Ehrlich gesagt kann man doch froh sein wenn AMD dadurch wieder Boden gut machen konnte, denn sein wir mal ehrlich: Jeder GM200 ist bei äquivalentem Verbrauch zu 99% schneller als Fiji und so war es dann ausgeglichener zumindest in AotS. Man muss das halt nur konsequent fortführen. Gleiches gilt ja auch für GM204 und Hawaii/Grenada.

fondness
2017-06-06, 20:06:25
https://s9.postimg.org/8f130olwv/AMD-_Vega-10-_HP-_Omen.jpg (https://postimg.org/image/awcu7y5t7/)

https://videocardz.com/newz/hp-omen-desktop-pc-to-ship-with-amd-vega-10

HOT
2017-06-06, 20:23:28
Nicht mehr oder weniger qualifiziert als der übliche Hype hier. Und nein, essentiell wird da auch nach 2 Jahren Hype nichts. Man darf eben nicht den Fehler machen jedes kleinste Feature einer GPU Architektur mit Buzzwords zu versehen und dabei das große ganze aus dem Blick zu verlieren.
Das ist nur blöderweise kein "Feature", schon da bist du einfach total auf dem Holzweg. Das ist genauso wenig ein "Feature" wie multithreaded zu programmieren. Das erfordert KnowHow. Wenn das aufgebaut ist, wird das einfach zum täglich Brot für die Spieleentwickler. Siehst du warum du auf der flaschen Fährte bist?

Keine Sorge... bis die Entwickler starken Einsatz von AC verwenden wird Nvidia nicht mehr hinterher hinken. Und dann interessierts wieder keine Sau was die letzte oder vorletzte Nvidia Generation leistet.

Na ja, mal abwarten, wie Volta aussieht.

Ehrlich gesagt kann man doch froh sein wenn AMD dadurch wieder Boden gut machen konnte, denn sein wir mal ehrlich: Jeder GM200 ist bei äquivalentem Verbrauch zu 99% schneller als Fiji und so war es dann ausgeglichener zumindest in AotS. Man muss das halt nur konsequent fortführen. Gleiches gilt ja auch für GM204 und Hawaii/Grenada.

Das liegt wohl vor allem am tile cache rendering. Dass Maxwell / Pascal schlecht auf async compute vorbereitet sind, spielt dafür ja keine Rolle. Der Vorteil des tilings überwiegt einfach. Vega holt das aber auf - da könnten solche Vorteile dann plötzlich relevant werden.

24p
2017-06-06, 20:36:44
Du wiederholst dich mit deinen Buzzwords. Und nein, ich bin nicht auf der falschen Fährte. Du bist es. Da ändern auch deine Umdefinitionen nichts.

dildo4u
2017-06-06, 20:42:16
Ich sehe nicht wo das ein Nachteil sein soll,das wäre einer wenn NV nicht wie am Fließband neue GPU's liefert.Wenn Volta dort massive Vorteile hat gibt es wieder ein Grund mehr aufzurüsten,wobei Pascal keine wirklichen Probleme hat das wurde per Treiber gefixt.Es war die letzten 2 Jahre deutlich wichtiger 6 oder 8GB zu haben als Asynchron Compute mit einer Fury.

Pirx
2017-06-06, 20:44:47
...Und nein, ich bin nicht auf der falschen Fährte. ....
Hast du überhaupt die fachlichen Kenntnisse, um das zu beurteilen?

fondness
2017-06-06, 20:44:58
Ich sehe nicht wo das ein Nachteil sein soll,das wäre einer wenn NV nicht wie am Fließband neue GPU's liefert.Wenn Volta dort massive Vorteile hat gibt es wieder ein Grund mehr aufzurüsten,wobei Pascal keine wirklichen Probleme hat das wurde per Treiber gefixt.Es war die letzten 2 Jahre deutlich wichtiger 6 oder 8GB zu haben als Asynchron Compute mit einer Fury.

Natürlich war es wichtiger, weil NV mit ihrem hohen Marktanteil längst den Fortschritt bremst. Was NV nicht hat setzt sich eben nicht durch.

Complicated
2017-06-06, 21:19:31
Du wiederholst dich mit deinen Buzzwords. Und nein, ich bin nicht auf der falschen Fährte. Du bist es. Da ändern auch deine Umdefinitionen nichts.
Offensichtlich vetstehst du die technischen Zusammenhänge nicht und nennst das dann Buzzwords. Daher weisst du wohl auch nicht was Buzzwords sind.

Vega muss gut werden, denn immer dann tauchen diese Marketing-Guerillas in den AMD Threads auf wenige Wochen vor Release und verbreiten unqualifizierten FUD.

StefanV
2017-06-06, 21:26:01
Das war mMn pure Verzweiflung, weil Apple den Markt für NV einfach dicht gemacht hat. Ob das jemals einer nutzen wird...
Hackintosh!!

vinacis_vivids
2017-06-06, 21:37:42
Wieso haben so viele Angst, dass Vega schneller sein wird als Pascal? Verstehe das nicht.

AC Schwäche wird Pascal zwar nicht zum Verhängnis, aber den Schwachpunkt wird Vega deutlich herausarbeiten.
Dazu gesellt sich noch der krasse Einbruch unter 4k/UHD. Hier wird der Sinn von +10% oder mehr durch AC deutlicher sichtbar werden.
Das hilft dann auch kein NV wundertreiber.

BlacKi
2017-06-06, 21:59:47
für mich ist vega, egal wie schnell vega wird, eh keine 4k karte. nicht wegen des Vrams, sondern der fps wegen. 4k ist für mich in 4-5 jahren vl ein thema. die grafikkarten werden durchschnittlich pro jahr zwar 30% schneller, zu dumm das die neuen spiele, zumindest gefühlt, 20% davon verschlingen.

M4xw0lf
2017-06-06, 22:06:53
OT, aber 4k geht jetzt schon super zum Zocken, passenden Geldbeutel oder nötige Flexibilität vorausgesetzt.

Blediator16
2017-06-06, 22:10:35
OT, aber 4k geht jetzt schon super zum Zocken, passenden Geldbeutel oder nötige Flexibilität vorausgesetzt.

Bei manchen ist nach all den Jahren noch nicht durchgedrungen, dass alle Einstellungen auf Ultra(Max) visuell meistens nichts bringen außer -fps :freak:

BlacKi
2017-06-06, 22:17:36
OT, aber 4k geht jetzt schon super zum Zocken, passenden Geldbeutel oder nötige Flexibilität vorausgesetzt.
mit 2 1080ti vl und auch nur vl. ich brauch meine 80-100fps sonst krieg ich schlechte laune. besser wären 120-144fps.

Gipsel
2017-06-06, 22:42:30
ich glaub da hast du was missverstanden. windows hält auch mit extra setup installierte treiber im treiber store vor. das hat jetzt erst mal nix mit treibern zu tun die ms direkt ausliefert. den 17.5.2 mit der windows driver store nummer 22.19.165.512 und auch den vorgänger 17.5.1 mit der storenummer 22.19.165.1 gibts noch nicht per windows update, denn der ist beta. der aktuellste treiber von ms wäre der 22.19.162.4 (https://www.catalog.update.microsoft.com/Search.aspx?q=rx%20580) und das ist der hotfix 17.4.4. es ist also durchaus realistisch, dass 22.19.384.11 ein neuer treiber oder ein unveröffentlichter branch ist.Okay, mir war nicht bewußt, daß da auch andere Versionsnummern vergeben werden, wenn man mit separatem Setup Treiber installiert. Wann wird denn welche Versionsnummer im 3DMark angezeigt? Die Windows Driver Store Nummer, wenn man einen vormals installierten Treiber darüber wieder installiert?

Wie auch immer, das Argument mit der Versionsnummer fällt dann natürlich weg.

Hübie
2017-06-06, 22:50:15
Bei manchen ist nach all den Jahren noch nicht durchgedrungen, dass alle Einstellungen auf Ultra(Max) visuell meistens nichts bringen außer -fps :freak:

Nicht von sich auf andere schließen :rolleyes: Es muss ja nicht Maximal sein, aber gewisse Einstellungen will man einfach nicht mehr herunter schrauben.

Dazu kommt noch der psychologische Effekt wenn man viel Geld* für ein Produkt ausgibt. Da steigen die Erwartungen laut einigen Theorien überproportional bis exponentiell. :freak:

*Das ist rein subjektives empfinden. Manche meiner Freunde sehen 300 Euro für eine Grafikkarte schon als viel zu viel an. Andere sagen auch 1.000 Euro wären OK.

Edit: Gipsel wo du gerade da bist: Würde beim HBC der HBM dann transparent sein? Hab's immer noch nicht gecheckt, sorry! Landen dort dann auch die Pagetables bzw. 'TLB'?

Gipsel
2017-06-06, 23:07:05
Gipsel wo du gerade da bist: Würde beim HBC der HBM dann transparent sein? Hab's immer noch nicht gecheckt, sorry! Landen dort dann auch die Pagetables bzw. 'TLB'?Na ja, ziemlich transparent dürfte es schon werden. Für eine normale Anwendung, welche nur die normalen DX-/Vulkan-/OpenCL-APIs benutzt, dürfte nicht ersichtlich sein, was wo liegt (also VRAM oder System-RAM). Eventuell bietet aber AMD Extensions an, die eine weitergehende Kontrolle ermöglichen.
Und die Pagetables für die GPU liegen natürlich im VRAM (HBM), genau wie die Pagetables für die CPU im System-RAM liegen. Die TLBs sind aber on-chip Caches, die spezialisiert die Pagetables cachen. Die liegen also nicht im HBM sondern on-chip bei der GPU (bzw. in der CPU für deren TLBs).

gravitationsfeld
2017-06-06, 23:34:09
Vulkan hat sehr wohl explizite memory property flags fuer VRAM oder System-RAM:


typedef enum VkMemoryPropertyFlagBits {
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT = 0x00000001,
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT = 0x00000002,
VK_MEMORY_PROPERTY_HOST_COHERENT_BIT = 0x00000004,
VK_MEMORY_PROPERTY_HOST_CACHED_BIT = 0x00000008,
VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT = 0x00000010,
VK_MEMORY_PROPERTY_FLAG_BITS_MAX_ENUM = 0x7FFFFFFF
} VkMemoryPropertyFlagBits;
typedef VkFlags VkMemoryPropertyFlags;

"Device" ist VRAM (falls nicht UMA), "Host" ist CPU-Speicher. "Lazily Allocated" TBDR-Zeug.

Edit: Gut, ist nicht ganz wahr. WDDM kann DEVICE-Speicher falls nötig auslagern.

yamamoto_dc
2017-06-06, 23:36:30
MArc Papermaster heute bei Bank of America Merril Lynch:


So, we announced Vega. We're starting shipping end of this month with the Frontier edition, with the rest of the SKUs to follow and it is incredibly high performance. So that's going to expand your TAM across the full spec discrete graphics and will allow us to have further share gain and just like my response on PCs gives you the same response on discrete graphics. We see no reason why we can't attain historical share presence.

Screemer
2017-06-06, 23:56:31
Das nen sogar ich ganz schön vollmundig. Hoffentlich gibts da kein backlash

BoMbY
2017-06-07, 01:14:36
Und natürlich leider wieder keine zitierfähige Quelle.

Linmoum
2017-06-07, 01:20:25
Dürfte wie immer von seekingalpha sein.

https://seekingalpha.com/article/4079307-advanced-micro-devices-amd-presents-advanced-micro-devices-bank-america-merrill-lynch-global

BoMbY
2017-06-07, 01:25:14
Man kann es auch im Webcast hören (https://www.veracast.com/webcasts/baml/technology2017/id82104393276.cfm), kurz vor Minute 22 einsteigen. Aber ist das so schwer sowas mal irgendwo bei zu schreiben?

Gynoug MD
2017-06-07, 02:46:57
die grafikkarten werden durchschnittlich pro jahr zwar 30% schneller, zu dumm das die neuen spiele, zumindest gefühlt, 20% davon verschlingen.
d.h. Stillstand bei der Grafik, dafür aber 1-2 Jahre früher sehr hohe FPS@4k?:freak:

iuno
2017-06-07, 04:08:07
Vulkan hat sehr wohl explizite memory property flags fuer VRAM oder System-RAM
Wenn man mit device local flag allokiert und der VRAM voll ist, reagiert der Treiber mit einem Fehler oder kommt es in den Hauptspeicher? Darum geht es ja hier eigentlich.

Verstehe uebrigens nicht wieso man in das Schaubild (mehr ist es nicht) so viel hineininterpretiert. 4 raster/geometry engines sind eigentlich offiziell bestaetigt.

gravitationsfeld
2017-06-07, 05:43:19
Die Allokation gibt einen Fehler zurück und es ist die Aufgabe der Applikation auf den Host-Heap zurückzufallen.

vinacis_vivids
2017-06-07, 06:11:14
mit 2 1080ti vl und auch nur vl. ich brauch meine 80-100fps sonst krieg ich schlechte laune. besser wären 120-144fps.

Mit einem 60hz Monitor?

Leonidas
2017-06-07, 06:16:31
Das ist halt typisch für diese Threads. Da gibt es ein paar Buzzwords und schon ist die Spekulation nach ein paar Wochen ausgemachte Sache. Wahrscheinlich ist es mit HBCC so wie mit AC. Viel Wind um fast nichts.


Korrekt & kann passieren. Trotzdem gilt: Man sollte der Technik seine Chance lassen, ehe man ein *Urteil* fällt.

24p
2017-06-07, 06:54:57
Jop, denn unzweifelhaft braucht es Konkurrenz im High-End Sektor. Die hier tw beschriebenen Wunderdinge glaube ich jedoch genauso wenig wie dass Vega deutlich langsamer als eine 1080Ti FE sein soll.


Ansonsten sehe ich das mit 4K so wie mein Vorposter, Ultra Details sind in den meisten Fälle nutzlos und kosten nur Leistung ohne viel optische BQ zu bieten.

vinacis_vivids
2017-06-07, 07:54:18
Alter, deutlich langsamer als 1080ti, :freak:
Das wäre 1080 Niveau und unter 4k low level API ist die FuryX schon nah dran. Also laber mal keinen Stuss.

Edit:
Leseverständnis...
Danke Screemer...

Screemer
2017-06-07, 07:58:05
Du solltest an deinem Leseverständnis arbeiten.

basix
2017-06-07, 08:42:03
Für mich sieht es nach einem 1080 Ti Konkurrenten aus. Vorsichtig optimistisch eher noch ein wenig schneller. Ob dies mit einer vergleichbaren Energieffizienz einhergeht steht auf einem anderen Blatt. Meiner Meinung nach ist das die wichtigere Grösse und dazu weiss man wirklich gar nichts, ausser dass man effizienter sein wird als alle AMD Vorgängerchips.

tm0975
2017-06-07, 09:03:50
also wenn amd mit vega den markt umkrempeln wikll, dann muß vega so schnell sein, dass es für diejeniegen, die noch 700 € in eine 1080 gesteckt haben zum umstieg lohnt. damit müßte sie dann auch schneller sein als eine 1080 ti. wäre ja prima. hoffentlich ist vega dann keine mining-rakete, sonst wirds für gamer noch ne ordentliche warteschlange geben.

HOT
2017-06-07, 09:14:23
Korrekt & kann passieren. Trotzdem gilt: Man sollte der Technik seine Chance lassen, ehe man ein *Urteil* fällt.
Nein er liegt einfach komplett falsch. Es geht hier nunmal nicht um irgendein Feature, sondern um eine Möglichkeit durch Computeshader effizienteren Code zu schreiben. Das ist so grundsätzlich und evolutionär, da kann man so einen Quatsch nicht schreiben. Was HBCC angeht wird man einfach sehen müssen wie effizient das ist. Wenn es vollständig transparent ist, wie Gipsel schreibt, liegt er (24p) da ebenfalls komplett daneben.

(Kit)Kat(e)
2017-06-07, 09:35:47
also wenn amd mit vega den markt umkrempeln wikll, dann muß vega so schnell sein, dass es für diejeniegen, die noch 700 € in eine 1080 gesteckt haben zum umstieg lohnt. damit müßte sie dann auch schneller sein als eine 1080 ti. wäre ja prima. hoffentlich ist vega dann keine mining-rakete, sonst wirds für gamer noch ne ordentliche warteschlange geben.
Ich glaube "so schnell sein das sich ein Umstieg lohnt" wird schwierig, wer gerade das Geld für eine 1080 Ti auf den Tisch gelegt hat wird meist nicht so schnell eine neue Grafikkarte kaufen. Auch wenn Vega beispielsweise um die 20% schneller wäre (was dann schon sehr optimistisch und die oberste Sitze der Fahnenstange wäre). Bei Neukäufern siehts dagegen vielleicht anders aus. Abgesehen von denen, welche aus Prinzip nichts kaufen was nicht von Mr. Huang vorgestellt wird. :wink:

LG Kat

tm0975
2017-06-07, 10:15:31
drum schrieb ich ja 1080 und nicht 1080ti als basis der käufer.

ZOCKERHERZ
2017-06-07, 10:20:26
Gab genug Leute die ihre 980TI im voraus für 450Euro verkauft hatten um für 700Euro eine 1080 zu holen. Da waren auch keine 20% Mehrleistung drin. Ich hoffe dass AMD bei der GPU eine großen Wurf geling wie bei der CPU.

dildo4u
2017-06-07, 10:25:27
Gab genug Leute die ihre 980TI im voraus für 450Euro verkauft hatten um für 700Euro eine 1080 zu holen. Da waren auch keine 20% Mehrleistung drin. Ich hoffe dass AMD bei der GPU eine großen Wurf geling wie bei der CPU.
Welche Benches meinst du 1080p?

http://abload.de/img/gtx1080z6rvt.png

https://www.computerbase.de/thema/grafikkarte/rangliste/#diagramm-performancerating-3840-2160

tm0975
2017-06-07, 10:31:34
und nun setze mal die 100% bei der 1080 gamin x+

(Kit)Kat(e)
2017-06-07, 10:37:49
drum schrieb ich ja 1080 und nicht 1080ti als basis der käufer.
Huch, da hatte ich wohl Wärmeleitpaste auf den Augen ! :eek::biggrin:
Gab genug Leute die ihre 980TI im voraus für 450Euro verkauft hatten um für 700Euro eine 1080 zu holen. Da waren auch keine 20% Mehrleistung drin. Ich hoffe dass AMD bei der GPU eine großen Wurf geling wie bei der CPU.
Das stimmt natürlich. Ich habe mittlererweile auch eine 1080 drin aber die wird eine Weile drinbleiben einfach weil ich nicht Krösus bin. Auch wenn ich AMD für einen "großen Wurf" gerne die Daumen drücke!

LG Kat

uweskw
2017-06-07, 10:49:23
also wenn amd mit vega den markt umkrempeln wikll, dann muß vega so schnell sein, dass es für diejeniegen, die noch 700 € in eine 1080 gesteckt haben zum umstieg lohnt. damit müßte sie dann auch schneller sein als eine 1080 ti. wäre ja prima. hoffentlich ist vega dann keine mining-rakete, sonst wirds für gamer noch ne ordentliche warteschlange geben.

Quatsch, es gibt genug die noch mit einer 980, 980Ti, Fury oder sogar noch älter unterwegs sind und wenn Vega wirklich irgendwo auf 1080 Ti Niveau liegt gerne mal wieder AMD kaufen würden.
NV hat sich durch virales Marketing und seinem Marktgebaren doch recht unsympatisch dagestellt. Nur geht auch bei mir alle Sympatie nicht soweit, dass ich noch ewig warte.
Wenn Vega wirklich auf 1080Ti Niveau liegt, wird es langsam Zeit für einen substantiellen Leak, damit ich weiss ob sich das Warten lohnt.

greetz
US

basix
2017-06-07, 11:04:48
Quatsch, es gibt genug die noch mit einer 980, 980Ti, Fury oder sogar noch älter unterwegs sind und wenn Vega wirklich irgendwo auf 1080 Ti Niveau liegt gerne mal wieder AMD kaufen würden.

So einer wäre ich :D Würde auch lieber Freesync als ein proprietäres G-Sync unterstützen.

Mancko
2017-06-07, 11:20:01
So einer wäre ich :D Würde auch lieber Freesync als ein proprietäres G-Sync unterstützen.

Das nützt Dir ja am Ende auch nix. Aus der Kundensicht bist ja damit dann trotzdem festgenagelt.

Mancko
2017-06-07, 11:22:51
NV hat sich durch virales Marketing und seinem Marktgebaren doch recht unsympatisch dagestellt.


Das ist doch maximal im Promillebereich. Da gibt es mit Sicherheit auch eine ganze Reihe Leute, ebenfalls im Promillebereich, die von AMDs Versprechungen die Nase voll haben. Wie soll ich denn Roy Taylors Aussagen zu months ahead, overclockers dream, designed for mobile und blah werten? Im Angesicht der verfügbaren Konkurrenzprodukte waren das in Teilen einfach Lügen (months ahead) gepaart mit nicht eingehaltenen Versprechen (overclockers dream und designed for mobile).

Es gibt natürlich grundsätzlich noch Kunden die nicht aufgerüstet haben. Aber von denen wartet keiner wegen Deiner oben von mir zitierten Aussage. Das ist total vernachlässigbar.

24p
2017-06-07, 11:25:32
drum schrieb ich ja 1080 und nicht 1080ti als basis der käufer.

Wer 20% mehr Leistung als mit einer 1080 will hat sich idR schon mit der 1080Ti eingedeckt.

Und ja von der 980TI auf die 1080 waren es 20-25%. Man muss nur eben Äpfel mit Äpfeln vergleichen.

BlacKi
2017-06-07, 11:42:45
Mit einem 60hz Monitor?
wie gesagt, 60hz/fps geht bei mir nicht mehr, da hilft kein gsync/freesync.

dargo
2017-06-07, 11:48:10
Das nützt Dir ja am Ende auch nix. Aus der Kundensicht bist ja damit dann trotzdem festgenagelt.
Klar nutzt das was. Du denkst da einfach zu kurzsichtig. Wenn NV merkt, dass denen die Kundschaft wegläuft ist ruck zuck G-Sync tot und/oder NV unterstützt zusätzlich A-Sync am Desktop. Im Mobilesektor tut sie dies bereits.

grauenvoll
2017-06-07, 12:12:03
Wenn NV merkt, dass denen die Kundschaft wegläuft ist ruck zuck G-Sync tot und/oder NV unterstützt zusätzlich A-Sync am Desktop. Im Mobilesektor tut sie dies bereits.

Und all diejenigen Deppen, die sich einen G-Sync Monitor gekauft haben, haben dann eben Pech gehabt. Einzelschicksale...

Da würde ich mich als Kunde doch ziemlich verarscht fühlen und Jensen Huang die Pest an den Hals wünschen!

dargo
2017-06-07, 12:18:09
Man kann beide Techniken parallel eine Zeit lang laufen lassen. Sowas gibt man nicht von heute auf morgen auf.


Da würde ich mich als Kunde doch ziemlich verarscht fühlen und Jensen Huang die Pest an den Hals wünschen!
Mit der GTX970 wurden auch jede Menge Spieler verarscht. Gestört hat es wenige.

Pirx
2017-06-07, 12:19:36
Und all diejenigen Deppen, die sich einen G-Sync Monitor gekauft haben, haben dann eben Pech gehabt. Einzelschicksale...

Da würde ich mich als Kunde doch ziemlich verarscht fühlen und Jensen Huang die Pest an den Hals wünschen!
Wer proprietären Mist unterstützt hat sowieso eine Strafe verdient und wenn es nur der höhere Kaufpreis wäre, denn funktionieren würden die G-Sync Monitore doch weiterhin.

Brillus
2017-06-07, 12:21:45
Und all diejenigen Deppen, die sich einen G-Sync Monitor gekauft haben, haben dann eben Pech gehabt. Einzelschicksale...

Da würde ich mich als Kunde doch ziemlich verarscht fühlen und Jensen Huang die Pest an den Hals wünschen!
Glaube es ist möglich beides zu unterstützen. Ich erwarte da eher ein sowohl als auch und die Monitorhersteller erledigen den Rest.

Mancko
2017-06-07, 13:08:45
Klar nutzt das was. Du denkst da einfach zu kurzsichtig. Wenn NV merkt, dass denen die Kundschaft wegläuft ist ruck zuck G-Sync tot und/oder NV unterstützt zusätzlich A-Sync am Desktop. Im Mobilesektor tut sie dies bereits.

Die Kundschaft läuft aber nicht weg. Die kauft trotzdem sehr gern Nvidia. Genau das ist der Punkt.

Wer proprietären Mist unterstützt hat sowieso eine Strafe verdient und wenn es nur der höhere Kaufpreis wäre, denn funktionieren würden die G-Sync Monitore doch weiterhin.

Dann dürftest du gar keinen x86 basierten PC kaufen und auch nicht Windows basiert, denn das ist nichts anderes als proprietärer Mist.

dargo
2017-06-07, 13:12:14
Die Kundschaft läuft aber nicht weg. Die kauft trotzdem sehr gern Nvidia. Genau das ist der Punkt.
Noch.

Dann dürftest du gar keinen x86 basierten PC kaufen und auch nicht Windows basiert, denn das ist nichts anderes als proprietärer Mist.
Der Vergleich hinkt. Bei x86 gibt es immer noch zwei wichtige Konkurrenten, und das ist auch gut so! Dass du das anders sieht wissen wir mittlerweile denn du betrachtest die Sachen nicht aus Kundensicht. Bei Windows gebe ich dir zwar recht. Allerdings kostet ein Windows keine bis zu 1.300€ (*hust* Titan XP) und man hat wesentlich länger was davon. So ein Windows kann man durchaus ~10 Jahre zum Gamen verwenden.

iuno
2017-06-07, 14:26:07
Die Allokation gibt einen Fehler zurück und es ist die Aufgabe der Applikation auf den Host-Heap zurückzufallen.
Danke, in diesem Fall kann man dann natuerlich nicht viel machen, wenn man konform bleiben will.

G3cko
2017-06-07, 14:44:52
Abgesehen von denen, welche aus Prinzip nichts kaufen was nicht von Mr. Huang vorgestellt wird. :wink:


.. außer ich bekomme seine Lederjacke gratis dazu. Dann verkaufe ich das ganze bei eby als "Private Founders Edition" an Schaffe. Davon kaufe ich mir dann 5x Vega, für jeden PCIe-Slot eine. ;D

N0Thing
2017-06-07, 15:03:58
Bezüglich meiner Frage, wie die Skalierung von Fiji bei anderen Testern ausgefallen ist: https://www.computerbase.de/2015-06/amd-radeon-r9-fury-x-test/10/#abschnitt_uebertaktbarkeit

Dort Resultiert eine Übertaktung von ca. 5% in ca. 3% mehr Performance, die abgespeckte Fury legt bei 8% Taktsteigerung 4%-7% zu.
https://www.computerbase.de/2015-07/sapphire-radeon-r9-fury-tri-x-oc-test/8/#abschnitt_uebertaktbarkeit

Daraus Schlußfolgerungen auf die Performance-Gewinne bei Vega durch den erhöhten Takt zu ziehen, erscheint mir bei der starken Schwankung je nach Titel als unmöglich.

Gipsel
2017-06-07, 16:19:47
Mit der Diskussion zu dem CB-Test bitte dort (https://www.forum-3dcenter.org/vbulletin/showthread.php?t=577870&page=20) weiter machen.

Danke.

Gipsel
2017-06-07, 16:31:50
Danke, in diesem Fall kann man dann natuerlich nicht viel machen, wenn man konform bleiben will.Na klar kannst Du da was machen. Ein x86er-Programm merkt ja auch nicht direkt, ob der belegte Speicher teilweise auf die Platte ausgelagert wurde oder nicht, das Paging ist aus Anwendungssicht transparent (nur die Performance wird beeinflußt, nicht die Funktion). Man kann die entsprechend vorhandenen Bits auch umdeuten, solange das für die App transparent erfolgt.

Im Prinzip macht man beinahe das Umgekehrte wie MS bei der XB1 und Scorpio. Die XB1 hat zwei getrennte Speicherpools (mit gemeinsamem Adressraum), die Scorpio nur noch einen. Trotzdem läuft (laut MS) auf Scorpio praktisch Alles ohne Patch (man mappt die Adressen des 32MB eSRAMs einfach in den GDDR5). Und genauso kann man das im Prinzip auch umgekehrt machen (einen Adressraum auf zwei Speicherpools aufteilen). Ist ein wenig schwieriger (vor allem wenn man hot page migration machen will [das will AMD mit dem HBCC] und nicht nur statisch aufteilt), aber gehen tut das schon. Ist halt ein Paging-Mechanismus zwischen Device- und Host-Speicher, der (vermutlich/wahrscheinlich) statt dem OS wie bei x86er-CPUs eine Hardware-Engine dafür nutzt.

Hübie
2017-06-07, 17:10:26
Mal so zum Verständnis: der HBCC selber schaufelt ja keine Daten, sondern lässt schaufeln und braucht entsprechend auch gar nicht viel Bandbreite sondern schnelle Datenpfade für die Befehle, oder?

vinacis_vivids
2017-06-07, 17:34:16
Die Daten kommen zuerst in L1 und dann in den den L2-Cache. Danach kommt HBCC.
Der HBCC hat HBC als eigenen exklusiven Cache.

Die Instruktionen werden aus dem L2 bearbeitet. Auf auf u.a.HBM2 gibs direkten Zugriff. Schnelle Pfade stimmen schon Mal.

Wahrscheinlich steckt auch ein Branch predictor drin.

Hübie
2017-06-07, 17:37:49
:| Branch predictor bei copy, move, read oder write?

Edit: Der sitzt normalerweise im Frontend um Sprungvorhersage zum fetchen der Instruktionen zu betreiben...

vinacis_vivids
2017-06-07, 17:51:19
Ich meine damit, dass HBCC bei sich wiederholenden Befehlen einfach den HBC nutzen kann. Das spart Bandbreite jedenfalls und gleichzeitig ist die Latenz gering.
Vllt. Ist der Ausdruck nicht ganz richtig, aber der HBCC nimmt eine recht zentrale Rolle ein.
Vega got a Soul?

Hübie
2017-06-07, 17:53:58
Das löst man idR über (hardware-)counter und code an sich.
Auf dem Schaubild waren Datenpfade zu externen Speichern eingezeichnet was mir noch nicht ganz einleuchten will. Möglicherweise ist das aber auch nur PCIE 3.0...

vinacis_vivids
2017-06-07, 18:02:16
Jeder Speicher ist extern außer L1/L2 und HBC.

Der L2 kann nur Vram bzw. Hier HBM2, der HBCC kann sowohl HBM2 als auch viel mehr als PCle 3.0...

Wenn der HBCC die versprochene Flexibilität bietet, muss Vega bei Speicherintensiven Anwendungen u.a. beim Mining richtig abgehen.

Hübie
2017-06-07, 18:13:29
Es ist doch offensichtlich dass es um offchip geht...

In konventionellen PCs wird man doch immer wieder das Nadelöhr PCIE 3.0 haben. Oder habe ich verpasst dass man IF heraus führt (ähnlich NVLINK). Frage ist dann was IF alles protokollseitig kann.

Ich muss übrigens zugeben dass ich mich sehr lange nicht mit AMD beschäftigt habe, weil da einfach das Angebot fehlt. Auch im professionellen Bereich wo es um Gesamtpakete geht leider nicht.

vinacis_vivids
2017-06-07, 18:28:56
Bei den APUs wird IF wahrscheinlich mit HBCC verbunden.
Bei AMD gibs ja synergistische Effekte wie >100% Skalierung mit Crossfire x2
Der HBCC kann vllt. Auch die frametimes synchronisieren. Die Fähigkeit, Daten auch Mal zurückzuhalten im Cache oder einfach durch mehr Parallelisierung.
Das erklärt die besseren min. FPS. im Vergleich zu HBCC Off. Rechenleistung ist zwar da, ist aber nicht der Flaschenhals bei den min fps Drops.

Hübie
2017-06-07, 18:45:26
Wobei wir nun wieder über die Sinnhaftigkeit von min fps reden müssten. ;) Min frametime percentile ist hier besser. Aber davon ab: mGPU soll besser aussterben. 100% Skalierung geht im Grunde gar nicht. Lasse mich da gerne belehren.

Gipsel
2017-06-07, 19:06:03
Mal so zum Verständnis: der HBCC selber schaufelt ja keine Daten, sondern lässt schaufeln und braucht entsprechend auch gar nicht viel Bandbreite sondern schnelle Datenpfade für die Befehle, oder?
Na ja, irgendwie schaufelt er schon die Daten bzw. initiiert dies. Ob man das zum HBCC dazurechnen will oder nicht ist eine reine Definitionsfrage und ändert eigentlich gar nichts.
Das ist aber erstmal gar nicht so das Problem. Greift die GPU auf Daten zu, die aktuell im System-RAM (Host-RAM) liegen, muß der HBCC die Entscheidung treffen, ob die betreffenden Speicherbereiche (Pages) in den lokalen VRAM umgelagert werden oder nicht (naiver Algo: bei jedem Zugriff in den lokalen RAM umlagern, falls nicht als non-pageable geflaggt [was der Treiber bei bestimmten Sachen als Optimierung per Spielprofil tun könnte, sowohl im System-RAM als auch im lokalen RAM, diese Bereiche sind dann von einer eventuellen Umlagerung ausgenommen]).
Wenn etwas umgelagert wird, kann es eben passieren, daß im lokalen RAM kein Platz mehr ist, also Alles gemappt ist. Dann muß man also Pages finden, die wenig genutzt werden und die mit den neuen Daten ausgetauscht werden können. Das ist gar nicht soo einfach. Immerhin hat man bei 8GB VRAM zwei Millionen 4kB Pages, die da verwaltet werden wollen. Die bei jedem Page Miss stur komplett nach der ältesten zu durchsuchen (angenommen bei einem Zugriff wird ein Timestamp in der Pagetable vermerkt), ist vielleicht nicht gerade die allerbeste Lösung. Da benötigt man also entsprechende Algorithmen, die einen guten Kompromiß zwischen Performance und Aufwand bieten (da muß man aber nicht das Rad neu erfinden sondern man kann Bekanntes adaptieren; jedes moderne Betriebssystem macht das ja auch [mit der normalen CPU, ohne spezielle Hardware]).

Als Aufwands-Optimierung für die Replacement-Strategie könnte man das vielleicht sogar tatsächlich wie einen Cache organisieren, also die Orte, an die eine Speicherstelle gemappt werden kann, etwas einschränken. Aber hier würde man vermutlich zu recht hohen Assoziativitäten (mindestens 64way assoziativ, eher deutlich mehr) gehen, da sonst doch ausreichend negative Einflüsse denkbar sind, die das sonst vermutlich nicht lohnenswert erscheinen lassen. Eine "klassische" Pagetable ist ja sozusagen voll assoziativ.


Optimalerweise versucht der HBCC immer etwas VRAM ungemappt zu lassen (also im Hintergrund schon mal prophylaktisch was in den System-RAM auszulagern bzw. es besser nur in den System-RAM zu kopieren, ohne es aus dem VRAM zu entfernen), so daß man einen Puffer hat und bei Bedarf nur aus dem System-RAM kopiert werden muß, ohne sofort nach alten Pages suchen zu müssen, die man nicht mehr benötigt (denn das dauert im Zweifelsfall länger als die paar MB Daten zu kopieren, die man jetzt mal gerade braucht).

Ich würde mal vermuten, der Paging-Algorithmus ist in der Firmware verankert (kann also z.B. per Treiberupdate modifiziert werden) und läuft auf irgendeinem embedded Prozessor, dem ein wenig dedizierte Hardware zur Verfügung steht, um das effizient laufen zu lassen. Die Command-Prozessoren im Frontend funktionieren ja ähnlich.
Die Paging-Engine im HBCC benötigt Speicherzugriff auf die Pagetables im VRAM (Teile davon in on-Chip Beschleunigungsstruktur für die Zugriffscounter/-timestamps in einem Ringbuffer gehalten?) und muß Transfers vom lokalen VRAM zum System-RAM und umgekehrt über PCIe initiieren können. Getriggert wird sie, wenn die Address-Translation der GPU bei einem Speicherzugriff eine Page Fault auslöst (Speicherstelle ist nicht im lokalen VRAM). Nach Transfer der benötigten Daten wird dann der Adress-Translation signalisiert, daß es jetzt verfügbar ist und die GPU macht einfach weiter.

Wenn gerade kein Page Fault bearbeitet wird, dürfte der HBCC im Hintergrund die Belegung des VRAMs überwachen und schon mal nach alten, ungenutzten Pages suchen, die dann in gewissem Umfang [5% des lokalen VRAMs als Zielgröße?] eventuell schon prophylaktisch in den System-RAM kopiert werden und bei einem Page Fault direkt genutzt werden können (falls etwas aus dem System-RAM geholt werden muß, kann man die einfach überschreiben [solange in der Zwischenzeit nicht modifiziert, was in der Pagetable über ein Bit vermerkt wird], falls die GPU das doch noch benötigt, ist es noch da).

Eventuell spendiert AMD dem HBCC sogar noch sowas wie ein (vermutlich recht vorsichtiges, konservatives) Prefetcher. Treten Page Faults in einem regulären Muster auf, kann man den Transfer von vorhergesagten Adressen ja schon mal anstoßen. Keine Ahnung, wie effektiv das wäre.

Hübie
2017-06-07, 19:18:36
Also braucht der HBCC einerseits Buffer (Bandbreite dürfte hier nicht so wichtig sein) und andererseits etwas an Logik und eben noch einen EPROM bzw. Flash für die Firmware. Meinst du nicht dass man so etwas auf einem (echten) die shot schon längst identifiziert hätte?

Die Verwaltung wird also ein Mix aus garbage collection mittels counter/timestamps und eben der page migration für den "import" von Daten aus dem DRAM, Flash, was auch immer. Das bedeutet man muss also seine Applikationen gar nicht darauf anpassen (könnte es ggf. für optimale Ergebnisse).
So richtig? Ich danke dir für die Ausführung.

Das die command processors eine firmware haben wusste ich gar nicht. Hat sich da denn überhaupt etwas getan oder wurden die mittels Treiber, je nach App, konfiguriert?

Digidi
2017-06-07, 19:25:36
Nein, es sind tatsächlich 4 Shader Engines, nur die NCU sind wie bei Polaris effektiv als 2 gespiegelte Blöcke pro Shader Engine am Die angeordnet. Wie bei Polaris sind zwischen den beiden 4-er Gruppen NCU die Restlichen Teile der Shader Engines zu finden - oben 2 blöcke von 2 Shader Engines, dann etwas anders, dann die restlichen 2 - genau wie bei Polaris.


Kannst du das mal anhand eines Polaris Die Shot erklären was du da mit gespiegelt meinst?

Gipsel
2017-06-07, 19:31:25
In konventionellen PCs wird man doch immer wieder das Nadelöhr PCIE 3.0 haben. Oder habe ich verpasst dass man IF heraus führt (ähnlich NVLINK). Frage ist dann was IF alles protokollseitig kann.IF wird immer wieder als aufgebohrtes Hypertransport-Protokoll beschrieben. Es ermöglicht die cache-kohärente Verbindung mehrerer Prozessoren.

Und ja, AMD will das Infinity Fabric auch rausführen bzw. tut das bei ihren Epyc-Server-CPUs auch bereits. Ob das schon bei Vega10 der Fall sein wird, wäre eine Frage. Aber für Vega20 war das mal auf einer Folie vermerkt. Dort soll das dann auch mit (mindestens) 16 GT/s funktionieren. Momentan sieht es so aus, als würde es bei Epyc auf 12,5 GT/s laufen (das sind laut Handbuch die Specs der verbauten Mehrzweck-PHYs, die nicht nur PCIe sondern unter Anderem auch xGMI [off-Package Infinity Fabric-Links, on-Package heißt es schlicht GMI] unterstützen).

Kurz: Es könnte theoretisch möglich sein, daß eine Vega-GPU über den PCIe-Slot eine xGMI-Verbindung aufbaut, wenn eine kompatible CPU (Epyc/Ryzen?) benutzt wird. Dann könnten nicht nur die Lanes schneller gefahren werden (wie gesagt maximal 12,5GT/s statt 8GT/s mit PCIe3), sondern das andere Protokoll ist vermutlich effizienter für eine kohärente Anbindung. Aber für übermäßig wahrscheinlich halte ich das für Vega10 noch nicht. Aber Vega20 sollte das können.

Hübie
2017-06-07, 19:48:49
Dann wäre es gut möglich *Achtung Spekulation ;)* dass Vega 20 ein HPC Chip aus eventuell zwei kleineren DIEs oder einem großen (V10) mit IF ist das auch nach außen geführt wird - also direkte Konkurrenz zu GV100. So hat man zwar Marktfragmentierung aber immerhin eine Wahl.
Sind die physischen Anforderungen an die Leitungen die gleichen wie bei PCIE (3.0)?

iuno
2017-06-08, 13:01:16
Na klar kannst Du da was machen.
Ich hatte es so verstanden, dass der vendor eben lokalen Speicher reservieren und ansonsten, falls es keinen gibt, einen Fehler melden muss, um konform zu bleiben. Der Fehler lag wohl in der Annahme, dass device memory VRAM sein muss, dabei muss der Speicher ja nur fuer die GPU "sichtbar" sein. Also wird dann, z.B. eine Karte mit 8 GiB HBM trotzdem z.B. 12 GiB verfuegbaren device memory melden und dann halt "sortieren".

Dann wäre es gut möglich *Achtung Spekulation ;)* dass Vega 20 ein HPC Chip aus eventuell zwei kleineren DIEs oder einem großen (V10) mit IF ist
Und V20 weiterhin ohne half rate fp64? Glaube ich nicht.

Gipsel
2017-06-08, 16:14:45
Und "Scalability" (was immer das dann genau heißen mag) stand ja erst für Navi auf der Roadmap.

BoMbY
2017-06-08, 16:27:30
Und "Scalability" (was immer das dann genau heißen mag) stand ja erst für Navi auf der Roadmap.

Ich würde darunter erwarten, dass man nur noch einen kleinen Chip bastelt, der dann als MCM mit anderen zusammen getackert wird (mittels Infinity Fabric über Interposer, oder ähnliches), ähnlich wie bei TR und Epyc.

Vielleicht ein Chip mit 16 CUs. Den könnte man dann in unterschiedlichsten Konfigurationen kombinieren. 16, 16+16, 16+16+16, 16+16+16+16, oder auch teildefekte 12, 12+12, 12+12+12, 12+12+12+12, ...

Damit könnte man eine komplette GPU-Generation mit nur einem Chip auf den Markt bringen.

Hübie
2017-06-08, 16:29:41
Und V20 weiterhin ohne half rate fp64? Glaube ich nicht.

Und warum glaubst du das nicht? Soviel mir noch bekannt ist wird FP64 zwar in vielen Anwendungen abgerufen, aber da nur zu einem geringen Anteil. Dem bemessen manche glaub ich mehr Aufmerksamkeit als eigentlich am Markt gefordert wird. Zumindest dedizierte FP64 halte ich imo für noch nicht im Bereich von 1:2 nötig. Aber zugegben habe ich keine belastbaren Beweise, dass dem immer noch so ist. :wink:

Digidi
2017-06-08, 23:54:55
Jetzt geht das wieder los Hübie! FP64 wird im Maschinenbau wie in der Wissenschaft immer gebraucht! Weil durch Ungenauigkeiten in der Kommastelle es zu signifikanten Abweichungen der Endergebnisse kommen kann ..... Z.B. Ein FEM netzt besteht aus mehreren Millionen Elementen, hinzu kommt das diese Millionen Elementen noch Millionen bis Billionenmal durch eine Itterationsschleife geschleust werden, mit jedem Rechenschritt wird der Fehler größer....

Back Topic. In den Folien von AMD war ausdrücklich von 4 Geometrie Engines die Rede, also klingen 8 Rasterizer für mich eher unwahrscheinlich. Aber wie kommen die mit der selben Geometrieschen auf den doppelten Polygoneoutput bei gleichem Takt?

vinacis_vivids
2017-06-09, 00:27:01
Aber wie kommen die mit der selben Geometrieschen auf den doppelten Polygoneoutput bei gleichem Takt?

*primitive shader* und *Intelligent Workgroup Distributor*

Der zweite sollte die Pipes gleichmäßig auslasten. Der erste ist eine Art schneller repeat Durchlauf.

Eldoran
2017-06-09, 00:30:28
Kannst du das mal anhand eines Polaris Die Shot erklären was du da mit gespiegelt meinst?
Nun, die Shader Engine ist nicht nur die (N)CUs - das sind auch noch andere Teile. Bezüglich der Nomenklatur:
https://www.3dcenter.org/dateien/abbildungen/AMD-Radeon-RX-480-Blockschaltbild.jpg.
Wobei AMD genau genommen von Geometry Engines sprach (siehe Vega Previewhttps://www.3dcenter.org/dateien/abbildungen/AMD-Vega-Architecture-Preview-Slide38.jpg). Allerdings beruht die Vermutung von 8 Engines auf der offensichtlich Gruppierung der Einheiten in 8 Blöcke (das war auch mein erster Gedanke), nur bestehen diese jeweils aus 8 identischen Blockanordnungen, so gesehen liefert die Grafik keinen Grund, warum diese nun 4,8 oder gar 64 engines sein sollten (Ryzen ist ja auch kein dualcore Pozessor). Da es sich um 8x8=64 Einheiten handelt und auch die vorhergehenden GCN Chips ähnlich aufgebaut sind, ist relativ klar, dass es sich dabei um die (N)CUs handeln muss.

Nun zu meiner eigentlichen Vermutung:
Ich echt kein Experte, aber so wie ich es verstehe, auch anhand der Vega Folien (https://www.3dcenter.org/artikel/amd-vega-architecture-preview), ist die Geometry Engine quasi Geometry Processor + Rasterizer. Ich such also etwas, das zumindest 2 Teile enthält und 4x (oder 8x) am Die vorhanden ist - das wäre der gelb umrahmte Block, rechts neben den NCU(rot). RB/ROP ist vermutlich grün und der intelligent workload distributor ist vermutlich der lila Block. Hellblau könnte L2 sein und weiß der HBCC.

Meine vermutete Geometry Engine besteht scheinbar aus 3 kleineren und 2 größeren Blöcken, das könnte bedeuten, es sind effektiv 2 Rasterizer und 3 Geometry Processors zusammengefasst. Das ganze wäre also möglicherweise quasi 3 bzw. 2 fach superskalar. Es wäre für mich soweit auch logisch - damit wäre die Relation ab Rasterizer wieder wie bei Hawaii. Nur wie kommt die Einschränkung der so vermuteten 12 Einheiten auf 11 Polygons zustande? Und irgendwie wäre das zu leistungsfägig - das müsste doch stärker gehyped werden, wenn Vega bei grob eine Leistungsverdopplung bei der IPC in Spielen hinlegt.
Oder hat das AMD vielleicht auch gemacht, wir dachten, es bezieht sich nur auf halfprecision?https://www.3dcenter.org/dateien/abbildungen/AMD-Vega-Architecture-Preview-Slide29.jpg

Hübie
2017-06-09, 01:34:11
Jetzt geht das wieder los Hübie! FP64 wird im Maschinenbau wie in der Wissenschaft immer gebraucht! Weil durch Ungenauigkeiten in der Kommastelle es zu signifikanten Abweichungen der Endergebnisse kommen kann ..... Z.B. Ein FEM netzt besteht aus mehreren Millionen Elementen, hinzu kommt das diese Millionen Elementen noch Millionen bis Billionenmal durch eine Itterationsschleife geschleust werden, mit jedem Rechenschritt wird der Fehler größer....

Back Topic. In den Folien von AMD war ausdrücklich von 4 Geometrie Engines die Rede, also klingen 8 Rasterizer für mich eher unwahrscheinlich. Aber wie kommen die mit der selben Geometrieschen auf den doppelten Polygoneoutput bei gleichem Takt?

Ach so ja und dass muss dann immer gleich 1:2 sein :rolleyes: Die Karte wird extra dafür gebaut.

(Kit)Kat(e)
2017-06-09, 09:49:02
Ach so ja und dass muss dann immer gleich 1:2 sein :rolleyes: Die Karte wird extra dafür gebaut.
Wäre das nicht ein Anwendungsfall für ein Multichipmodul und IF? Also nochmals ein Modul speziell für FP64 fürs Profisegment an einen Gamingchip "dranflanschen"? Oder stelle ich mir das (wiedereinmal) zu einfach vor? :biggrin:

LG Kat

basix
2017-06-09, 09:55:58
Ich denke das wäre die Paradedisziplin von IF. Irgendwie erwarte ich sowas aber erst für Navi.

Was für mich noch nicht ganz klar ist, ist das Thema Speicheranbindung. Kann man das Speicherinterface über IF zu einem zweiten Chip schlaufen, ohne dass der ein eigenes Interface besitzt? Oder muss jeder sein eigenes Interface haben? Irgendwie muss dann ja trotzdem noch der Datentransfer zwischen den Chips recht flott sein, wenn man einen gemeinsamen Speicherpool haben will. Wie klappt das bei Naples?

Eldoran
2017-06-09, 10:04:30
Ach so ja und dass muss dann immer gleich 1:2 sein :rolleyes: Die Karte wird extra dafür gebaut.
Die Frage ist aber auch: wie sicher kommt eine Vega 20 != Vega 10(refresh)? Welche Belege haben wir überhaupt dafür? Gibt es außer der sehr stümperhaft gephotoshopten Profesional Roadmap irgendetwas?
Unabhängig davon - soweit ich mich an Microprocessor Design erinnere, ist eine dual precision performance von 1:3 kaum aufwendiger, sofern man den Übertrag nutzt (ich kann aber derzeit nicht nachlesen). Abgesehen davon, ist je nach design multiplikation/division etc. langsamer wie addition etc.

Skysnake
2017-06-09, 11:07:01
Wäre das nicht ein Anwendungsfall für ein Multichipmodul und IF? Also nochmals ein Modul speziell für FP64 fürs Profisegment an einen Gamingchip "dranflanschen"? Oder stelle ich mir das (wiedereinmal) zu einfach vor? :biggrin:

LG Kat
Ja stellst du dir. Im Prinzip würde das schon gehen, wäre aber maximal Ineffizient. Da ist es um Welten besser einfach Multiprecision ALUs zu verbauen.

Bringt ja nichts, etwas zu bauen, dass dann so schlecht ist, das es kein Mensch kaufen will...

Die Frage ist aber auch: wie sicher kommt eine Vega 20 != Vega 10(refresh)? Welche Belege haben wir überhaupt dafür? Gibt es außer der sehr stümperhaft gephotoshopten Profesional Roadmap irgendetwas?
Unabhängig davon - soweit ich mich an Microprocessor Design erinnere, ist eine dual precision performance von 1:3 kaum aufwendiger, sofern man den Übertrag nutzt (ich kann aber derzeit nicht nachlesen). Abgesehen davon, ist je nach design multiplikation/division etc. langsamer wie addition etc.
Multiply und Division haben immer eine höhere Latenz, so lange man die Addition nicht "künstlich" verlangsamt aus welchen Gründen auch immer.

Addition schafft man in einem Takt. Multiplikation im Normalfall in 5 Takten, Intel ist mit Broadwell aber auf 4 Takte runter und Division ist irgendwo in den 20ern.

Die Transzendenten Funktionen wie cos, sin, Expo und SQRT schauen wir uns lieber mal nicht an. Die haben teilweise sehr sehr lange Latenzen, weshalb es sich auch bei denen richtig lohnen kann nicht die ganz strengen IEEE Spezifikationen zu fordern, sondern gewisse Dinge ausschließen zu können. das bringt echt richtig speed :up:

Hübie
2017-06-09, 11:26:29
Deshalb schrieb ich Speku. ;) Digidi ist offenbar nicht davon zu überzeugen, dass die Rechenleistung von FP64 wichtig ist, nicht ob 1:2, 1:3 oder gar 1:32. Wobei letzteres fast überall zu wenig sein dürfte, aber da kenne ich keine Zahlen. Auch nicht ob Catia das bspw. ständig abruft. Airbus / EADS arbeiten jedenfalls seit langem damit und ich weiß nicht ob man damals schon viel FP64 benötigte, aber vermutlich nicht wirklich. Andere können sich da bestimmt präziser drüber äußern.

Gipsel
2017-06-09, 11:39:22
Was für mich noch nicht ganz klar ist, ist das Thema Speicheranbindung. Kann man das Speicherinterface über IF zu einem zweiten Chip schlaufen, ohne dass der ein eigenes Interface besitzt?Ja.
Oder muss jeder sein eigenes Interface haben?Nein. Es kann ja auch bei Threadripper und Epyc passieren (und zwar recht häufig, wenn man keine NUMA-Nodes definiert), daß gerade benötigte Daten an dem Speichercontroller eines anderen Dies hängen. Das muß funktionieren. Wenn Du bei Threadripper z.B. nur zwei der vier Speicherkanäle bestückst (oder bei Epic weniger als 8), kannst Du ja im Prinzip auswählen, an welchem Die was hängt. ;)
Irgendwie muss dann ja trotzdem noch der Datentransfer zwischen den Chips recht flott sein, wenn man einen gemeinsamen Speicherpool haben will. Wie klappt das bei Naples?Epyc und Threadripper nutzen auf dem Package die GMI-Links zwischen den Dies, die angeblich jeweils mit voller Bandbreite des on-chip Infinity-Fabrics laufen (laut TheStilt, mal sehen ob das stimmt). Bandbreitentechnisch sollte es also kaum eine Rolle spielen, ob es nur über den on-chip-Fabric zum Speichercontroller geht oder zusätzlich noch über einen GMI-Link. Die Latenz dürfte etwas steigen. Aber ansonsten sollte sich nicht so viel tun, wenn das ordentlich dimensioniert wurde (und sich nicht gerade zwei Kerne/Dies das gegenseitig wegnehmen wollen und dann das Kohärenzprotokoll alles einbremst [passiert im Zweifel aber auch on-die]).
Zwischen den Sockeln bei Epyc laufen dann xGMI-Links, die vermutlich mit etwas anderer Datenrate laufen. Im Prinzip gibt es da 64 Lanes (jeweils up und down parallel, also gleichzeitige Übertragung in beide Richtungen ist mit voller Bandbreite möglich), die laut Doku bis zu 12,5GT/s unterstützen. Das wären dann (bis zu?) 100GB/s zwischen den Sockeln. Das ist nicht ganz das, was man mit 8 Kanälen@DDR4-2666 hinbekommt (~170GB/s), dürfte aber im Normalfall meist reichen. Etwas Latenz kostet das aber wie üblich natürlich auch, wenn es vom anderen Sockel kommen muß.

uweskw
2017-06-09, 12:21:21
Was mich auf alle Fälle optimistisch stimmt ist die Preisreaktion von NV.
1080Ti unter 600,00€ und die 1080GTX Custom unter 450,00€
Da bin ich schon mal froh gewartet zu haben. Hätte mir letzte Woche beinahe ne 1080Ti geholt... ist jetzt fast nen hunderter runtergegangen.
Aber anscheinend lohnt es sich doch auf Vega zu warten. Aber warum leaken die dann so garnichts???

greetz
US

dildo4u
2017-06-09, 12:23:14
Was mich auf alle Fälle optimistisch stimmt ist die Preisreaktion von NV.
1080Ti unter 600,00€ und die 1080GTX Custom unter 450,00€
Da bin ich schon mal froh gewartet zu haben. Hätte mir letzte Woche beinahe ne 1080Ti geholt... ist jetzt fast nen hunderter runtergegangen.
Aber anscheinend lohnt es sich doch auf Vega zu warten. Aber warum leaken die dann so garnichts???

greetz
US
Das hat nix mit Vega zu tun.

https://www.computerbase.de/2017-06/cpu-ryzen-7-ryzen-5-kaby-lake-preise-vergleich/

Man sollte jetzt eine 1080 Ti kaufen bevor die Miner sie abgreifen.

Eldoran
2017-06-09, 12:24:01
Zwischen den Sockeln bei Epyc laufen dann xGMI-Links, die vermutlich mit etwas anderer Datenrate laufen. Im Prinzip gibt es da 64 Lanes (jeweils up und down parallel, also gleichzeitige Übertragung in beide Richtungen ist mit voller Bandbreite möglich), die laut Doku bis zu 12,5GT/s unterstützen. Das wären dann (bis zu?) 100GB/s zwischen den Sockeln. Das ist nicht ganz das, was man mit 8 Kanälen@DDR4-2666 hinbekommt (~170GB/s), dürfte aber im Normalfall meist reichen. Etwas Latenz kostet das aber wie üblich natürlich auch, wenn es vom anderen Sockel kommen muß.
Bei Ryzen/Epyc ist IF zumindest innerhalb des Package extrem performant. Wie man aus diversen Ryzen Benchmarks kennt, ist IF (on Die) zwar langsamer wie innerhalb eines CCX, aber in den meisten Anwendungsszenairien nahe dran. Ungünstig sind natürlich Fälle, bei denen quasi jeder Zugriff auf Cache/RAM über das IF läuft (worst case), der dürfte aber vergleichbar mit dem Unterschied RAM an Northbridge oder an CPU liegen (grob 30% wenn ich mich recht erinnere). Bei intel scheint das mit multi socket weniger effektiv (http://semiaccurate.com/2017/05/17/amd-calls-naples-epyc-analyst-day/) zu funktionieren.
An sich ist aber gerade diese NUMA Problematik der zentrale Ansatzpunkt von IF - koährent (sonst gibt es Probleme) und mit niedriger Latenz (etwa bei PCIe ein problem, da ggf. gewartet werden muss, bis man übertragen darf). Definitiv fix ist bisher aber glaube ich hauptsächlich, dass IF in Vega verbaut ist, was genau damit aber gemacht werden kann, ist noch eher Spekulation.
Außerdem nicht jede Funktion, die im Silizium vorhanden ist, ist unbedingt in den ersten Karten auch tatsächlich nutzbar. Es gibt einige Beispiele für derartiges... Ich halte einen Defekt für eher unwahrscheinlich, aber ggf. muss das im Treiber/Firmware unterstützt werden und das ist dort noch nicht fehlerfrei. Nur so nebenbei die Änderungen bei Polaris 480 zu 580, neben dem etwas höheren Takt, waren auch nur Firmware.

Complicated
2017-06-09, 14:38:07
Man sollte jetzt eine 1080 Ti kaufen bevor die Miner sie abgreifen.
GDDR5X Speicher ist untauglich für Miner. Daher braucht man sich hier keinen Kopf zu machen.
https://forum.ethereum.org/discussion/9277/1080-specific-ethereum-mining-issues
6) Can the algos be rewritten to run much faster on GDDR5x verse GDDR5? (opinion, unlikely)

I suspect the answer is no. There may be Pascal optimizations, but these will raise both 1070 and 1080 boats.
The reason is ETHash works off random reads of 128 byte blocks of memory. The 1070/1080 memory controllers have a 4 byte memory channel. GDDR5 will burst 8 * 4 bytes = 32 bytes and GDDR5X will burst 16 * 4 bytes = 64 bytes. Both of which are smaller than 128 bytes needed by ETHash so GDDR5X doesn't appear to break anything fundamental (such as having a burst length greater then the needed data). It can likely be tuned better once GDDR5X and the Pascal memory coalescing is understood, but it's not obvious that refactoring the algo and creating a 1080 version will make a huge difference. So maybe the 1080 can move from 10% slower than the 1070 to 25% faster, but big gains (> 2x) seem unlikely.

whetstone
2017-06-09, 15:05:50
GDDR5X Speicher ist untauglich für Miner. Daher braucht man sich hier keinen Kopf zu machen.
https://forum.ethereum.org/discussion/9277/1080-specific-ethereum-mining-issues

Wenn alle ETH minen würden, was nicht der fall ist, müsste man sich keinen kopf machen.

dargo
2017-06-09, 15:06:19
Das hat nix mit Vega zu tun.

https://www.computerbase.de/2017-06/cpu-ryzen-7-ryzen-5-kaby-lake-preise-vergleich/

Man sollte jetzt eine 1080 Ti kaufen bevor die Miner sie abgreifen.
Nur taugt die GTX1080TI genauso wenig zum minen wie GTX1080 wegen GDDR5x. ;)

r3ptil3
2017-06-09, 15:14:05
Was für eine Durststrecke... ein fast 300 Seiten langer Thread und nicht mal ein offizieller Performancewert.

Mal gespannt wie der Launch der FE aussehen wird, wenn ja später noch eine etwas schnellere Vega kommen soll. Sehe da schon den nächsten Marketingpatzer.

Complicated
2017-06-09, 15:16:41
Wenn alle ETH minen würden, was nicht der fall ist, müsste man sich keinen kopf machen.
Da derzeit ausschließlich ETH für die Knappheit verantwortlich ist muss man sich tatsächlich keinen Kopf machen. Lediglich bei Altcoins gilt die 1080 als leidlich profitabel, aber nicht als beste Konfig.
Was für eine Durststrecke... ein fast 300 Seiten langer Thread und nicht mal ein offizieller Performancewert.
Was ja wohl erst mit Release der GPU möglich ist. Das ist ein Spekulations-Tread der mit erscheinen der GPU und offiziellen Performancewerten auch keinen Sinn mehr macht. Dann sind die Review-Threads federführend.

Hasenpfote
2017-06-09, 16:00:41
1080Ti unter 600,00€ und die 1080GTX Custom unter 450,00€Das war aber nur kurz. Die 1080 wieder über 450Euro, die 1080Ti deutlich über 600Euro (~650Euro bei Geizhals).

Ansonsten kann ich bardh nur zustimmen. Die letzten Wochen ohne wirklich Info nerven.

iuno
2017-06-09, 17:20:56
Nur taugt die GTX1080TI genauso wenig zum minen wie GTX1080 wegen GDDR5x. ;)
Vom Anschaffungspreis mal abgesehen, stimmt das nicht: https://www.phoronix.com/scan.php?page=article&item=ethminer-linux-gpus&num=2
ist etwas dazu bekannt, ob man da was an den MCs gemacht hat oder z.B. Micron bei den neueren 11 Gbps Chips die Timings besser hinbekommen hat?

Digidi
2017-06-09, 17:26:28
Meine vermutete Geometry Engine besteht scheinbar aus 3 kleineren und 2 größeren Blöcken, das könnte bedeuten, es sind effektiv 2 Rasterizer und 3 Geometry Processors zusammengefasst. Das ganze wäre also möglicherweise quasi 3 bzw. 2 fach superskalar. Es wäre für mich soweit auch logisch - damit wäre die Relation ab Rasterizer wieder wie bei Hawaii. Nur wie kommt die Einschränkung der so vermuteten 12 Einheiten auf 11 Polygons zustande? Und irgendwie wäre das zu leistungsfägig - das müsste doch stärker gehyped werden, wenn Vega bei grob eine Leistungsverdopplung bei der IPC in Spielen hinlegt.
Oder hat das AMD vielleicht auch gemacht, wir dachten, es bezieht sich nur auf halfprecision?https://www.3dcenter.org/dateien/abbildungen/AMD-Vega-Architecture-Preview-Slide29.jpg

Also das mit 4 Rasterizer haut nicht hin.

Noch mal zum nachdenken man hat 11 Polygonen pro Takt das heißt man braucht schon mal 11 Einheiten die die Polygonen bearbeiten. Was heißt eigentlich Output. Ist das wirklich nach dem Rasterizer?

Es könnte ja auch nur bedeuten das der Geometrieprozessor wegen Tessellation aus einem großen Polygon 3-4 kleine Macht. So hat man schnell aus 3-4 Polygonen von der CPU 10-12 Polygonen gemacht ob die dann von den Rasterizern bearbeitet werden können ist dann eine andere Frage.

Für mich macht das ganze ja nur sinn wenn am Ende der Rasterizer dann die 11 Polygonen bearbeitet hat und dann entsprechen viele Pixel kommen.

Wo sitzt eigentlich die Primitve Discard unit? Würde ja vermuten vor dem Geometrieprozessor. Logischer aufbau wäre ja:
- Alle Polygonen die unnötig sind verwerfen (Primitve Discharge unit)
- Auf die Restlichen Polygonen den Geometrieprozessor anwenden (Tessellation)
- Diese Polygonen dann im Rasterizer in Pixel verwandeln.

Der Rasterizer sowie die Primitive Discard unit ist es ja da wo es bei AMD wegen der Auslastung der Shader hapert. Zum ersten mal werden viel zu wenig Pixel an die Shader weiter gereicht wegen dem Rasterizer und dann sind da auch eine menge Pixel dabei die man dann gar nicht sieht.

iuno
2017-06-09, 17:31:19
Primitive Discard Accelerator heisst das Ding und kuemmert sich wohl einfach ums Clipping. Ich denke auch, dass irgendwie sowas miteinbezogen wird, sonst kommt man nicht auf 11. 8 Rasterizer waeren wohl die Brute Force Methode, aber daran glaube ich auch noch nicht...

dargo
2017-06-09, 17:38:43
Vom Anschaffungspreis mal abgesehen, stimmt das nicht: https://www.phoronix.com/scan.php?page=article&item=ethminer-linux-gpus&num=2
Der Anschaffungspreis spielt aber dabei eine nicht unerhebliche Rolle. ;)

iuno
2017-06-09, 17:42:36
Das steht ausser Frage, die Begruendung war aber falsch. Mich wuerde ausserdem interessieren, was da bei der 1080 falsch laeuft oder bei der Ti evtl. gemacht wurde. Ist aber natuerlich jetzt voellig OT

Digidi
2017-06-09, 17:44:33
Primitive Discard Accelerator heisst das Ding und kuemmert sich wohl einfach ums Clipping. Ich denke auch, dass irgendwie sowas miteinbezogen wird, sonst kommt man nicht auf 11. 8 Rasterizer waeren wohl die Brute Force Methode, aber daran glaube ich auch noch nicht...

Aber selbst dann müssen die 11 Polygonen ja vom Rasterizer verarbeitet werden. Der Discard Accelerator sollte ja noch vor der Geometrie Engine liegen.

Ist ja das selbe wie bei Nvidia. Siehe hierzu die Byond 3d Suite. Die 6 Rasterizer bei Titan X(P) kann man nur auslasten wenn man sie Culled. Ansonsten kommt man auf 2 Polygonen pro Takt anstat auf 6.

http://www.pcgameshardware.de/Titan-X-Grafikkarte-265165/Tests/Test-Benchmark-Tuning-Overclocking-vs-1080-1206879/

Mal eine Andere Logik. Von der CPU kommen 4 Polygonen, die werden auf die 4 Geometrieprozessoren aufgeteilt. Die 4 Geometrieprozessoren machen aus den 4 Polygonen mit Tessellation nun 8 Polygonen. Diese 8 Polygonen müssen dann nun von 8 Rasterizern bearbeitet werden. Das würde heißen man könnte sehr wohl 4 Geometrieprozessroen haben aber dann halt auch mehr Rasterizer. Vielleicht sogar 11 Rasterizer. Wie sonst kann mann dann 11 Polygonen ausgeben. Wobei das Wort (Thtrouput) im Englischen ja nicht Ausgeben sondern Durchsatz Heist.

Hübie
2017-06-09, 17:57:20
Mal doofe Frage, da Polygon ja einfach nur Vieleck bedeutet: Sind damit irgendwie geartete Dreiecke gemeint oder schon eine definierte Anzahl an zusammenhängenden Dreiecken? :|

Digidi
2017-06-09, 18:02:16
Mal doofe Frage, da Polygon ja einfach nur Vieleck bedeutet: Sind damit irgendwie geartete Dreiecke gemeint oder schon eine definierte Anzahl an zusammenhängenden Dreiecken? :|

Damit ist ein einzelnes Dreieck gemeint. Es heist auch sonst noch Tris oder Triangle.

iuno
2017-06-09, 18:08:15
Aber selbst dann müssen die 11 Polygonen ja vom Rasterizer verarbeitet werden. Der Discard Accelerator sollte ja noch vor der Geometrie Engine liegen.
Da zitiere ich dich mal selber:
Wobei das Wort (Thtrouput) im Englischen ja nicht Ausgeben sondern Durchsatz Heist.
Das kann imho alles moegliche bedeuten, von verworfenen bis tesselierten Dreiecken.

Mal eine Andere Logik. Von der CPU kommen 4 Polygonen, die werden auf die 4 Geometrieprozessoren aufgeteilt. Die 4 Geometrieprozessoren machen aus den 4 Polygonen mit Tessellation nun 8 Polygonen. Diese 8 Polygonen müssen dann nun von 8 Rasterizern bearbeitet werden. Das würde heißen man könnte sehr wohl 4 Geometrieprozessroen haben aber dann halt auch mehr Rasterizer. Vielleicht sogar 11 Rasterizer. Wie sonst kann mann dann 11 Polygonen ausgeben.
Theoretisch denkbar, dass eine SE einen GP und zwei Rasterizer hat. Aber sicher nicht mehr, man wird keine krumme Zahl oder ein Ungleichgewicht drin haben und wuerde sonst, etwa bei 4, direkt als Peak 16 angeben.

@Hübie: Am Ende sind es alles primitives = einzelne Dreiecke.

Digidi
2017-06-09, 18:09:12
Deshalb schrieb ich Speku. ;) Digidi ist offenbar nicht davon zu überzeugen, dass die Rechenleistung von FP64 wichtig ist, nicht ob 1:2, 1:3 oder gar 1:32. Wobei letzteres fast überall zu wenig sein dürfte, aber da kenne ich keine Zahlen. Auch nicht ob Catia das bspw. ständig abruft. Airbus / EADS arbeiten jedenfalls seit langem damit und ich weiß nicht ob man damals schon viel FP64 benötigte, aber vermutlich nicht wirklich. Andere können sich da bestimmt präziser drüber äußern. Hä? Ich sag doch die ganze Zeit das FP64 oft genutzt wird. Aber nicht in Catia sondern in so sachen wie ANSYS NASTRAN etc...
:freak:

@Iuno
Durchsatz vertsehe ich aber auch das alle Polygonen es auch bis ans Ende schaffen.

Hübie
2017-06-09, 18:21:48
Dann sind wir uns doch einig. ;) ANSYS oder NASTRAN kenne ich nicht und entsprechend auch nicht wie viel FP64 da gebraucht wird. Meiner Erfahrung nach braucht man FP64 nicht für hohe Performance sondern eher basic performance. Das es hier und Ausnahmen gibt, mag sein. Keine Frage. Nur auf Ausnahmen auf die Regel zu schließen, sprich das Produkt XY so nicht kommt, halte ich für eher vage.
Da lasse ich mich aber wirklich eines besseren belehren.

Unter Durchsatz verstehe ich dass es Polygone sind, die es zum rendern in die pipeline schaffen. Aber das ist wohl Definitionssache.

Gipsel
2017-06-09, 18:27:55
Primitive Discard Accelerator heisst das Ding und kuemmert sich wohl einfach ums Clipping.Mit Clipping hat der nicht so viel zu tun. Der Discard Accelerator verwirft Dreiecke bereits vor dem Rasterizer, wenn festssteht, daß diese in keinem Fall das Bild beeinflussen können (weil sie kein einziges Sample/Fragment bedecken). Dies ist z.B. bei (zur Linie oder zum Punkt) degenerierten/entarteten Dreiecken der Fall.
Aber selbst dann müssen die 11 Polygonen ja vom Rasterizer verarbeitet werden. Der Discard Accelerator sollte ja noch vor der Geometrie Engine liegen.Der gehört zur Geometry Engine.
Ist ja das selbe wie bei Nvidia. Siehe hierzu die Byond 3d Suite. Die 6 Rasterizer bei Titan X(P) kann man nur auslasten wenn man sie Culled. Ansonsten kommt man auf 2 Polygonen pro Takt anstat auf 6.
http://www.pcgameshardware.de/Titan-X-Grafikkarte-265165/Tests/Test-Benchmark-Tuning-Overclocking-vs-1080-1206879/
Culled Dreiecke sollten eigentlich gar nicht durch den Rasterizer gehen ;). Was man da mißt, ist wohl eher, wie effizient das Culling ist. Bei AMD limitiert die Setup-Rate viel früher (man kann nur 1 Dreieck pro Geometry Engine abarbeiten, bei nV skaliert es mit der Zahl der SMs), Culling bringt nicht so viel. Wenn die Rasterizer auch wirklich was tun müssen (0 Culling), arbeiten sie eigentlich mit grob vergleichbarerer Performance.

Digidi
2017-06-09, 18:37:27
Mit Clipping hat der nicht so viel zu tun. Der Discard Accelerator verwirft Dreiecke bereits vor dem Rasterizer, wenn festssteht, daß diese in keinem Fall das Bild beeinflussen können (weil sie kein einziges Sample/Fragment bedecken). Dies ist z.B. bei (zur Linie oder zum Punkt) degenerierten/entarteten Dreiecken der Fall.
Der gehört zur Geometry Engine.
Culled Dreiecke sollten eigentlich gar nicht durch den Rasterizer gehen ;). Was man da mißt, ist wohl eher, wie effizient das Culling ist. Bei AMD limitiert die Setup-Rate viel früher (man kann nur 1 Dreieck pro Geometry Engine abarbeiten, bei nV skaliert es mit der Zahl der SMs), Culling bringt nicht so viel. Wenn die Rasterizer auch wirklich was tun müssen (0 Culling), arbeiten sie eigentlich mit grob vergleichbarerer Performance.


Weis denn jemand wo man die Beyoned3d Suite runterladen bzw kaufen kann? Würde das ja gerne mal ausprobieren.

Interessant ist ja aber das man bei der Beyoned3d Suite bei AMD wie auch bei Nvidia von den Theoretischen Möglichkeiten zurück bleibt. AMD und Nvidia packen hier 2 Polygonen pro Takt. AMD müsste eigentlich 4 und Nvidia hier 6 erreichen wenn es wirklich ein reiner Polygonen Test ist.

iuno
2017-06-09, 23:13:51
Weis denn jemand wo man die Beyoned3d Suite runterladen bzw kaufen kann? Würde das ja gerne mal ausprobieren.

I'm writing software again. You might have seen The Tech Report run a new Beyond3D suite. That's currently being developed further, to support new kinds of tests and analyses, and I plan to release it to a wider audience when it's ready.
https://forum.beyond3d.com/threads/subscriptions-and-donations.57162/

Arbeitet mittlerweile bei AMD, aber du kannst ja mal eine Anfrage per Mail schicken

Complicated
2017-06-09, 23:41:22
Vom Anschaffungspreis mal abgesehen, stimmt das nicht: https://www.phoronix.com/scan.php?page=article&item=ethminer-linux-gpus&num=2
Das steht ausser Frage, die Begruendung war aber falsch.
Die Begründung ist nicht falsch, sondern die Quelle ist fehlerhaft.
The GTX 1080 Ti was managing 31.5 MH/s while the RX 580 was at 22.1 MH/s and the R9 Fury at 24.8 MH/s.... Das mag ja in seinem Selbstversuch stimmen, wie in so vielen anderen die meinen sie wollen das kurz mal checken, doch die RX 580 minen mit angepassten BIOS Versionen über 30 MH/s. Hier sind auch die Karten mit Hynix-Speicher schneller. Eine Aufschlussreiche Quelle dazu:
http://1stminingrig.com/best-bios-rom-for-sapphire-pulse-rx-580-8gb-oc-hynix-memory-30-mhs/
Da werden aus 22 MH/s bei 140 W dann 30 MH/s bei 120 W

Zumal es dann ins Dual-mining geht. Da werden zwei verschiedene Hashes gemined mit 130 W: Eth 30 MH/s und gleichzeitig z.B. Siacoin mit 540 MH/s

Somit taugt das mining auch keineswegs als Benchmark wie er dort bei Phoronix vermutet hat.

basix
2017-06-10, 11:14:17
Das ganze Mining Zeugs ist sowas von einer Blase...aber Mining ist vielleicht gar nicht mal so der falsche Ausdruck dafür (Goldgräber Run und so...).

Eldoran
2017-06-10, 11:36:52
Vega is designed to handle up to 11 polygons per clock with 4 geometry engines.Warum nicht 12? Es scheint ja alles sehr symmetrisch zu sein - demnach wäre anzunehmen, dass jede Geometry Engine 3 verarbeiten kann, es aber irgendwo einen Bottleneck gibt. Die logischte Erklärung die mir dazu einfällt ist eine Begrenzug von Cache/Register Ports - die sind idR. eine 2er Potenz.
Angenommen 16 Ports - 11 wäre 5, das könnte von Grpphics Command Processor sowie 4 ACE herrühren.

Andererseits hat irgendwer ein detaillierteres Wissen wie sich die Geometry Processors bei Fiji/Polaris bezüglich Tesselatin/Culling etc. per clock verhalten?
Bonusfrage und was limitert aktuell (wo würde mehr IPC etwas bringen) in der Praxis?

HOT
2017-06-10, 14:29:27
Das ganze Mining Zeugs ist sowas von einer Blase...aber Mining ist vielleicht gar nicht mal so der falsche Ausdruck dafür (Goldgräber Run und so...).
Das denke ich stimmt aber nur zum Teil. Natürlich bläst sich das auf und geht auch wieder zurück, einige werden auch ganz verschwinden. Aber der Kram ist jetzt in der Gründerphase, wird aber die nächsten Jahrzehnte die Finanzwelt bestimmen.

BoMbY
2017-06-10, 15:42:21
wird aber die nächsten Jahrzehnte die Finanzwelt bestimmen.

Oder verboten werden. Oder jemand findet einen fundamentalen Fehler und alles bricht zusammen.