Raven Ridge APU: Zen-Cores, Vega-GPU, DDR4, 65W, 2017

[y33H@]

Das Crosshair VI ist für Raven Ridge freilich witzlos, hat keine Display-Ausgänge. Ich würde das auch so interpretieren, dass die neuen Teiler nur für Pinnacle Ridge gelten, aber vll ja auch für Summit Ridge und Raven Ridge - nächste Woche mal testen.

[bbott]

aber vll ja auch für Summit Ridge und Raven Ridge - nächste Woche mal testen.

Habt ihr schon was zum testen :eek: Es war doch zuletzt (Anfang) März im Gespräch, nur technische Daten hatte ich für Februar erwartet.

Schade das die Leaks so selten geworden sind, wäre mal wieder Zeit :D

[Ravenhearth]

Mich würde interessieren, wie viel schneller der 2400G gegenüber dem wesentlich günstigeren 2200G in Spielen überhaupt sein wird. Auf dem Papier steht es 1,76 vs. 1,12 GFLOPs, aber ich könnte mir vorstellen, dass die Speicherbandbreite so sehr limitiert, dass der Unterschied in Spielen gar nicht mal so groß ausfällt. Die Benchmarks von AMD deuten sowas schon an, dort verliert die kleinere APU nur knapp 10% in Rocket League und Skyrim und nichts in Battlefield. Ich konnte allerdings keine Information zu den genauen Settings und zum eingesetzten RAM finden, hat die jemand? Bisher sieht es allerdings so aus, als wäre die kleinere APU kaum langsamer, und aus P/L-Sicht die damit attraktivere Wahl. Ebenfalls bedeuten könnte dies, dass GPU-OC auf dem 2400G in kaum höheren Bildraten resultiert. AMDs Benchmarks hierzu waren ja nur im 3D Mark...


https://pics.computerbase.de/8/1/2/3/9/3-1080.4004781072.png
https://pics.computerbase.de/8/1/2/3/9/4-1080.3026161587.png

[y33H@]

Ich kann mal die Backup-Slides angucken, vermute aber die Bandbreiten-Theorie ist zutreffend.

[deekey777]

Ich kann mal die Backup-Slides angucken, vermute aber die Bandbreiten-Theorie ist zutreffend.
Da wirst du viel Zeit in den nächsten Wochen verbringen und zwar mit verschiedenen Speichergeschwindigkeiten.

AMD deaktiviert nicht umsonst beim kleinen 2200G das Hyperthreading, sonst wäre die APU im Vergleich zu 2400G zu stark, um den Aufpreis zu rechtfertigen.

[Ravenhearth]

Ich kann mal die Backup-Slides angucken, vermute aber die Bandbreiten-Theorie ist zutreffend.
Danke. :)

Das könnte übrigens auch bedeuten, dass der Sprung gegenüber dem A12-9800 wahrscheinlich gar nicht mal so groß ausfällt wie es der Rohleistungszuwachs suggeriert. AMD vergleicht RR (in nur einem Benchmark!) ja mit der GT 1030, und schon der A12 war in einigen Spielen auf Augenhöhe mit der GT, in anderen dahinter. Ich halte es für möglich, dass selbst der 2400G grafikseitig im Mittel nur 20-30% auf den A12 drauflegt (bei bspw. DDDR4-3200), der 2200G entsprechend etwas weniger. Damit ist RR hauptsächlich das dringend benötigte Update hinsichtlich CPU-Leistung, Effizienz und Features und bei der Grafikleistung nur ein evolutionärer Sprung. (Und der 2200G bleibt wie gesagt das interessantere Modell.)

Damit stellt sich abermals die Frage, wie AMD in Zukunft die Leistung der iGPU steigern möchte, wenn die Speicherbandbreite so sehr limitiert. Ein 128 Bit-Speicherinterface mit DDR4 ist offensichtlich nicht mehr ausreichend, und etwas höhere Speichertaktraten wie DDR4-4000 sind auch keine wirkliche Lösung. Mehr als 128 Bit sind im Consumer-Bereich ebenfalls kaum vertretbar. HBM ist für aktuelle iGPUs wiederum ziemlicher Overkill und rechnet sich erst bei größeren GPUs, wie man an Kaby Lake G sieht. Wenn AMD die nächste iGPU allerdings auf bspw. 24 CUs aufpumpt wäre HBM zwar vertretbar, würde aber die Kosten vermutlich stark erhöhen. Nicht ideal für günstige APUs. Schwierige Frage...

[StefanV]

Damit stellt sich abermals die Frage, wie AMD in Zukunft die Leistung der iGPU steigern möchte
HBM Lite.
Da gibts doch diese Version mit nur 512bit...

[maguumo]

Bräuchte aber wohl immer noch Interposer oder EMIB, und ob AMD letzteres nutzen darf/ob außer Intel wer das momentan umsetzen kann weiß ich nicht. Und das packaging dürfte wohl in naher Zukunft der wichtigere Faktor sein, HBM wird immer billiger.

[Brillus]

Bräuchte aber wohl immer noch Interposer oder EMIB, und ob AMD letzteres nutzen darf/ob außer Intel wer das momentan umsetzen kann weiß ich nicht. Und das packaging dürfte wohl in naher Zukunft der wichtigere Faktor sein, HBM wird immer billiger.
Die Vega mobile hört sich von der höhe doch an wie EMIB.

[Knuddelbearli]

Y33H@ da wir beim Thema sind

wie groß ist den der Aufwand für einen Ordentlichen Ram Skalierung Test? Irgendwie habe ich bisher noch keinen gefunden der mich restlos überzeugt ...
1.) Nicht nur Shooter und Rennspiele die zumeist eher GPU Limitiert sind
2.) nicht nur 2 Geschwindigkeiten
3.) DR und SR
4.) Verschiedene Timings
5.) nicht nur FPS sondern auch 1%

Einzig Golem hat da ihmo einen halbwegs brauchbaren auf die Beine gestellt aber perfekt finde ich den auch nicht :-/

[maguumo]

Die Vega mobile hört sich von der höhe doch an wie EMIB.
Stimmt, könnte sein, hatte ich gar nicht dran gedacht. Wäre natürlich klasse wenn AMD das schon für eigene Produkte nutzen kann/darf.

[BoMbY]

Was ich mich frage ist, ob AMD irgendwann auch plant Treiber für Raven Ridge zu veröffentlichen? Bis jetzt gibt es für die Mobile-APUs jedenfalls keine offiziellen Treiber, sondern nur uralten, und unvollständigen, Kram von den OEMs.

[Screemer]

Bräuchte aber wohl immer noch Interposer oder EMIB, und ob AMD letzteres nutzen darf/ob außer Intel wer das momentan umsetzen kann weiß ich nicht. Und das packaging dürfte wohl in naher Zukunft der wichtigere Faktor sein, HBM wird immer billiger.
ist doch jetzt kein hexenwerk siliciumleitungen in nem organischenpackage einzubringen. man nennt das zeug anders bastelt ein bisschen andere produktionstechnik und fertig ist der lack. die frage ist nur ob man das überhaupt möchte.

[maguumo]

Nein, aber das Packaging dafür muss ja erstmal wer übernehmen, abgesehen davon weiß ich gar nicht ob das Patentrechtlich erlaubt wäre oder ob Intel da einen Riegel vorschiebt (vorschieben kann?).
Was meinst du mit ob man das überhaupt möchte? Macht doch das gleiche wie ein Interposer, nur billiger.

[y33H@]

Danke :)

Das könnte übrigens auch bedeuten, dass der Sprung gegenüber dem A12-9800 wahrscheinlich gar nicht mal so groß ausfällt wie es der Rohleistungszuwachs suggeriert. AMD vergleicht RR (in nur einem Benchmark!) ja mit der GT 1030, und schon der A12 war in einigen Spielen auf Augenhöhe mit der GT, in anderen dahinter. Ich halte es für möglich, dass selbst der 2400G grafikseitig im Mittel nur 20-30% auf den A12 drauflegt (bei bspw. DDDR4-3200), der 2200G entsprechend etwas weniger. Damit ist RR hauptsächlich das dringend benötigte Update hinsichtlich CPU-Leistung, Effizienz und Features und bei der Grafikleistung nur ein evolutionärer Sprung. (Und der 2200G bleibt wie gesagt das interessantere Modell)Also die Benches sind mit 2x 8 GByte DDR4-2667 entstanden, vermutlich Single-Rank. Die Latenzen nennt AMD üblicherweise nicht in den Fußnoten bzw Backup-Slides.

62393

Ich finde grade keine Folie mit der GT 1030, stimme dir aber grundsätzlich zu. Raven Ridge dürfte durch DDR4-2400-DR ziemlich begrenzt werden, AMD schickt nicht umsonst gleich DDR4-3200-CL14-SR mit. Auch zeigen die eigenen OC-Benches, dass vor allem die RAM-Geschwindigkeit limitiert und man die (Sub-)Latenzen tweaken kann/soll.

Y33H@ da wir beim Thema sind:
wie groß ist den der Aufwand für einen Ordentlichen Ram Skalierung Test? Irgendwie habe ich bisher noch keinen gefunden der mich restlos überzeugt ...

1) Nicht nur Shooter und Rennspiele die zumeist eher GPU Limitiert sind
2) nicht nur 2 Geschwindigkeiten
3) DR und SR
4) Verschiedene Timings
5) nicht nur FPS sondern auch 1%

Einzig Golem hat da ihmo einen halbwegs brauchbaren auf die Beine gestellt aber perfekt finde ich den auch nicht :-/Uff, zumindest würde ich sagen, der Aufwand ist angesichts der geschätzten Zielgruppe immer zu hoch ^^ auch für Raven Ridge war bisher für das initiale Review nur DDR4-2400-CL15-DR sowie DDR4-3200-CL14-SR angedacht. Weil neben RR kommt halt noch ein KBL samt eine Geforce GT 1030 als Vergleich rein und freilich der A12-9800. Alleine das ist schon recht viel Arbeit, selbst mit nur fünf Spielen und drei vier Anwendungen.

Du sprichst aber wohl ohnehin von einem RAM-Test für Summit/Pinnacle Ridge? der Test (https://www.glm.io/127262) wurde sehr oft verlinkt, aber überragend gelesen hat er sich nicht ... wobei ich sagen muss, angesichts von nur einer Seite sind die Abrufe doch recht hoch. Allerdings war die Basisarbeit ja schon gelegt und es sind nur Avg-Fps ... mit Frametimes und Perzentilen steigt der Auswertungsaufwand halt stark an.

Schlag doch mal einfach vor, was genau dir vorschwebt: Anwendungen, Spiele, RAM-Takt samt DR/SR und Latenz und welche CPU sowie Grafikkarte. Dann lässt sich das besser abschätzen.

Die Vega mobile hört sich von der höhe doch an wie EMIB.Dachte ich auch, aber Lisa Su meinte auf Nachfrage, es sei ein besonders tief im Package eingelassener Interposer.

[dildo4u]

62393

Ich finde grade keine Folie mit der GT 1030,

Kein Plan ob Timespy wenig Bandbreite braucht,schätze mal das ist mit 2666.

https://www.technopat.net/sosyal/konu/ryzen-5-2400g-vs-core-i5-8400-gt-1030.515509/

[mczak]

Damit stellt sich abermals die Frage, wie AMD in Zukunft die Leistung der iGPU steigern möchte, wenn die Speicherbandbreite so sehr limitiert. Ein 128 Bit-Speicherinterface mit DDR4 ist offensichtlich nicht mehr ausreichend, und etwas höhere Speichertaktraten wie DDR4-4000 sind auch keine wirkliche Lösung.
Ganz einfach, höhere Bandbreiteneffizienz. Es gibt ja Hinweise darauf dass der DSBR bei Raven mehr bringen soll als bei Vega 20, das wäre schon mal ein Schritt in die Richtung.
Da ist sicher noch nicht das Ende des technisch möglichen erreicht (der near-zero-bandwidth DDR3 940MX hat ja ganz anständige Geschwindigkeit erreicht, auch wenn der natürlich klar bandbreitenlimitiert war, aber der hat auch nicht mal die Hälfte der Bandbreite eines RR mit dual-channel ddr4-2400).
Eine Alternative wäre auch die Mitnutzung des CPU-L3 Cache (kann intel schon lange), glaube nicht dass RR das kann. Das ist kein wirklicher Ersatz für fehlende Speicherbandbreite aber so ein paar Prozent würde das wohl auch helfen (da wäre allerdings ein grösserer L3 als 4MB sicher auch ganz nützlich).
Ansonsten wie erwähnt HBM/EMIB, wenn sich denn die Kosten vertreten lassen.
Irgendwann gibt's dann auch noch ddr5, das fängt dann wohl so bei ddr5-4200 erst an... Allerdings wohl kaum vor 2020 masstentauglich...

[y33H@]

@ dildo4u

Ah, das war aus Jim Andersons Slides, nicht aus Ryzen Desktop Breakout. Tendenziell sind Spiele empfindlicher was Bandbreite angeht als jegliche 3DMarks.

Die Werte sind bei Raven Ridge laut AMD mit 2x 8 GByte DDR4-3200 entstanden ;D

EDIT

Raven Ridge kann offiziell übrigens DDR4-2933: https://www.computerbase.de/2018-01/raven-ridge-ddr4-2933/

http://products.amd.com/en-us/search/APU/AMD-Ryzen%E2%84%A2-Processors/AMD-Ryzen%E2%84%A2-5-Processor-with-Radeon%E2%84%A2-Vega-Graphics/AMD-Ryzen%E2%84%A2-5-2400G/243
http://products.amd.com/en-us/search/APU/AMD-Ryzen%E2%84%A2-Processors/AMD-Ryzen%E2%84%A2-3-Processor-with-Radeon%E2%84%A2-Vega-Graphics/AMD-Ryzen%E2%84%A2-3-2200G/244

[danarcho]

Eine Alternative wäre auch die Mitnutzung des CPU-L3 Cache (kann intel schon lange), glaube nicht dass RR das kann.
Da ich das zum ersten Mal höre: Hast du da zufällig irgendeine Quelle für? Würde das gerne mal nachlesen.

[basix]

L3 in allen Ehren, aber die 4MB auf RR werden die Bandbreiten-Not nicht beheben. Dann lieber Aufwand in eine Low-Cost HBM Lösung mit 64-128 GByte/s stecken, Speichermenge 2-4 GByte inkl. HBCC. Mit 16 GBit und 32 GBit pro Die und dem weglassen des Logic-Die (wie schon für LowCost HBM angekündigt) muss man nicht mal Die-Stacking benutzen, was eine sehr kostengünstige Lösung werden kann. HBM sollte ebenfalls einiges energieeffizienter sein, was pJ/Bit anbelangt und somit würde noch ein wenig Energiebudget frei. Info: HBM liegt bei ca. 6pJ/bit; DDR bei ca. 27pJ/bit und Infinity Fabric (die-to-die) bei 2pJ/bit. Nimmt man 2pJ/bit an, landet man bei 2W für 128 GByte/s.

2-4 GByte + HBCC @ 128 GByte/s bei den 7nm APUs mit Navi wäre die perfekte Low Power / Low Cost Lösung. Denn durch den HBM sinkt die sonstige Anforderung an die Speicherbandbreite und man kann günstigeren als auch stromsparenderen Speicher verwenden (z.B. LPDDR4 @ 1866 MHz). Insgesamt als Package also höhere Leistung UND vergleichbare oder gar tiefere Kosten.

[Eldoran]

Die Vega mobile hört sich von der höhe doch an wie EMIB.

Dachte ich auch, aber Lisa Su meinte auf Nachfrage, es sei ein besonders tief im Package eingelassener Interposer.
Wenn man sich das ganze einmal gründlich durchüberlegt, ist der Gewinn von EMIB gegenüber einem Interposer gering. Man erspart sich die Höhe der Lötpunkte zwischen Interposer und Package. Der Rest kommt im normalen Vergleich (in den intel Präsentationen) durch das Tieferlegen der EMIB in das Package hinein, nur warum sollte das bei dem Interposer nicht möglich sein? So wie es aussieht hat AMD eben genau das gemacht. Sonderlich hoch muss das Package nicht sein, da ja durch das Interposer die problematischen Datenleitungen zum Speicher wegfallen, was die notwendigen Metalllagen reduziert. Auch die Anforderungen an die Lötpunkte sind bezüglich der thermischen Belastungen geringer. Bei Vega ist ja ohnehin der Interposer sehr dünn, was ja auch bei der Fertigung Probleme gemacht hat.
Welches Gesamtsystem im besten Fall wirklich das Dünnste ist, ist derzeit nicht klar.

[danarcho]

L3 in allen Ehren, aber die 4MB auf RR werden die Bandbreiten-Not nicht beheben. Dann lieber Aufwand in eine Low-Cost HBM Lösung mit 64-128 GByte/s stecken, Speichermenge 2-4 GByte inkl. HBCC.
Beim L3 ging es mir nur um das Prinzip. HBM würde auf einer richtigen APU nur als L4 Sinn ergeben (gemeinsam für CPU und iGPU), ansonsten könnte man sich die Integration gleich schenken und es so wie Intel machen.

[basix]

Beim L3 ging es mir nur um das Prinzip. HBM würde auf einer richtigen APU nur als L4 Sinn ergeben (gemeinsam für CPU und iGPU), ansonsten könnte man sich die Integration gleich schenken und es so wie Intel machen.

Grundsätzlich ja, da gebe ich dir völlig recht. Aber umso höher die Packaging-Kosten, desto unwahrscheinlicher. Die APUs sind im Desktop die Butter und Brot Prozessoren, die dürfen gar nicht zu teuer werden. Zudem werden mit 7nm die Dinger so klein (4C CCX = ca. 20mm2), da lohnt sich ein einzelner Chip nicht oder ist gar nicht machbar (zu kleines Die um alle I/O's nach aussen zu führen).

So wie es Intel macht lohnt sich meiner Meinung nur, wenn man den Platz dafür hat. CPU + GPU + HBM unter einem Heatspreader der Grösse von Ryzen schafft man nicht. APU + HBM schon eher. Ausnahme wäre sowas in der Art wie Intel Stratix 10 und zigfach EMIB, wenn die CPU dann max. 100mm2 misst und in etwa quadratisch ist.

Zudem ist noch eine Frage offen als L4: Wie hoch sind die Latenzen von HBM? Sie müssten tiefer sein als die von DDR, was ich aufgrund der unterschiedlichen Verwendung bezweifle. CPUs sind auf Latenz orientiert, GPU auf Bandbreite.

[deekey777]

@ dildo4u

Ah, das war aus Jim Andersons Slides, nicht aus Ryzen Desktop Breakout. Tendenziell sind Spiele empfindlicher was Bandbreite angeht als jegliche 3DMarks.

Die Werte sind bei Raven Ridge laut AMD mit 2x 8 GByte DDR4-3200 entstanden ;D

EDIT

Raven Ridge kann offiziell übrigens DDR4-2933: https://www.computerbase.de/2018-01/raven-ridge-ddr4-2933/

http://products.amd.com/en-us/search/APU/AMD-Ryzen%E2%84%A2-Processors/AMD-Ryzen%E2%84%A2-5-Processor-with-Radeon%E2%84%A2-Vega-Graphics/AMD-Ryzen%E2%84%A2-5-2400G/243
http://products.amd.com/en-us/search/APU/AMD-Ryzen%E2%84%A2-Processors/AMD-Ryzen%E2%84%A2-3-Processor-with-Radeon%E2%84%A2-Vega-Graphics/AMD-Ryzen%E2%84%A2-3-2200G/244
Bestimmt werden die OEMs mindestens DDR4-2933 nutzen, mindestens. ;(

[Complicated]

Eine Alternative wäre auch die Mitnutzung des CPU-L3 Cache (kann intel schon lange), glaube nicht dass RR das kann. Das ist kein wirklicher Ersatz für fehlende Speicherbandbreite aber so ein paar Prozent würde das wohl auch helfen (da wäre allerdings ein grösserer L3 als 4MB sicher auch ganz nützlich).
Das ist eine etwas merkwürdige Aussage. Zum einen hatten APUs von AMD bisher allesamt keinen L3 Cache. Raven Ridge ist die erste APU mit L3. Und zum anderen ist die gemeinsame Speichernutzung und Cache Kohärenz bei APUs überhaupt nicht möglich ohne dass CPU und GPU auf Cache gemeinsam zugreifen.

Die Cache-Kohärenz bei AMDs APUs und der gemeinsame Speicherzugriff wird durch zusätzliche Datenleitungen ermöglicht, die immer wieder vergessen werden zur eigentlichen Bandbreite des DDR-RAMs hinzu zu zählen. Hier wäre einmal der FCL (Fusion Control Link, früher mal mit dem Codenamen "Onion" bezeichnet) und zum anderen der RMB (Radeon Memory Bus, früher einmal mit dem Codenamen "Garlic" bezeichnet)
The first APU, Llano, had a 128-bit Fusion Compute Link that allowed the GPU to access CPU-owned memory in certain cases. This link was an add-on created specifically for mixed-mode computing, since the integrated Radeon had a 512-bit bus of its own. Trinity expanded the FCL to 256 bits wide and changed its path, routing it through an IOMMU and into a unified north bridge between the CPU and graphics cores. Kaveri retains the 512-bit Radeon bus and the 256-bit FCL, and it adds a third 256-bit link from the GPU to the north bridge.
https://techreport.com/r.x/a8-7600/hsa-bus.gif

This new link is notable because it provides coherent access to memory. That is, the GPU can read and modify memory locations over this link without worrying about whether the same data is being held or modified in the CPU caches. Much like in a multi-socket server, Kaveri's hardware ensures that its CPU and GPU cores are properly synchronized and working on correct, up-to-date data.
Das ist bei Kaveri der Stand der Dinge gewesen und ist dem weit voraus wie Intel im L3 Cache die CPU und GPU Synchronisiert. Die Cachegröße hat bei AMD zudem ganz andere Bedeutung, da sie auch einen anderen Ansatz beim Cache wählen als dies Intel implementiert. Auch wenn AMD bei APUs eher weniger informiert, so ist der von AMD gewählte Ansatz schön erklärt und begründet in dieser Ausarbeitung von Dresdenboy bei der Analyse im Vorfeld des Ryzen-Launches:
http://www.planet3dnow.de/cms/26077-details-und-analyse-der-zen-architektur-nach-der-hot-chips-konferenz/subpage-speichersubsystem-im-detail/
Entgegen anderslautender Gerüchte setzt AMD beim Cache-Aufbau weiterhin auf exklusive L3-Caches nach der „Victim Strategy”. Das heißt, dass Daten in der Regel entweder direkt in den L1- oder in den L2-Cache geladen werden: Fallen Daten aus dem L2 heraus, landen diese „Opfer” (victims) im L3. Bei Intel-Designs liegen L2-Daten dagegen automatisch immer als Kopie auch im L3, was einerseits die effektive L3-Cachegröße und damit indirekt auch die L2-Größe begrenzt, andererseits die Kern-zu-Kern-Kommunikation vereinfacht.
Cache-Organisation und -Aufbau gehen somit Hand in Hand. Weil AMD kein inklusives Cachedesign wählte, ein Datenaustausch über den L3 also ohehin fast unmöglich ist, benötigt man auch keinen einzelnen gemeinsamen L3-Cache, sondern kann sich mit simplen 8-MiB-Modulen begnügen. Insbesondere bei Serverchips mit vielen Kernen und noch mehr Cache, wird die Cacheorganisation zum Problem. AMD setzt bei den Serverchips aber auch auf einen bewährten MCM-Ansatz, mit dem von vorne herein keine gemeinsamen L3-Caches möglich wären. Somit ist die Designentscheidung insgesamt nachvollziehbar und schlüssig. Als Speichermodell findet die bewährte und schon von K8/K10 bekannte MOESI-Strategie Anwendung.


Man darf davon ausgehen, dass dieses Cache-Modell auch bei Raven Ridge zur Anwendung kommt. Schaut man kurz nach was ein MOESI-Modell ist kommt man auch schnell dahinter warum das mit dem L3-Cache nicht ganz so einfach ist wenn man AMD und Intel vergleicht:
https://de.wikipedia.org/wiki/MOESI
MOESI bietet keinen wesentlichen Vorteil gegenüber MESI, wenn das Verbindungsnetzwerk zwischen Prozessoren und Speichercontroller ein Bus (https://de.wikipedia.org/wiki/Bus_(Datenverarbeitung)) ist. Es ist hingegen bei direkten Netzwerken von Vorteil, wie zum Beispiel bei AMD-Opteron-Systemen. Das Vermeiden des Zurückschreibens von modifizierten Cache-Lines sorgt hier für die Entlastung von Verbindungsnetzwerk und Speichercontroller. Außerdem kann die Kommunikation zwischen zwei oder mehreren CPUs bzgl. Latenz und Übertragungsrate signifikant besser sein als zwischen CPU und Hauptspeicher. Bei Multicore-CPUs (https://de.wikipedia.org/wiki/Multicore-Prozessor) mit jeweils eigenen Caches pro Core ist dies meist der Fall.
Da Intel erst mit aktuellen CPUs auf den Ringbus verzichtet und seine CPU-Kerne anfängt mit Mesh zu verbinden, könnte hier eher bei Intel eine Änderung in Richtung AMDs Lösung zu beobachten sein.

Intel Skylake-SP: Mesh statt Ringbus (https://www.heise.de/newsticker/meldung/Intel-Skylake-SP-Mesh-statt-Ringbus-3742898.html)

[Knuddelbearli]

Uff, zumindest würde ich sagen, der Aufwand ist angesichts der geschätzten Zielgruppe immer zu hoch ^^ auch für Raven Ridge war bisher für das initiale Review nur DDR4-2400-CL15-DR sowie DDR4-3200-CL14-SR angedacht. Weil neben RR kommt halt noch ein KBL samt eine Geforce GT 1030 als Vergleich rein und freilich der A12-9800. Alleine das ist schon recht viel Arbeit, selbst mit nur fünf Spielen und drei vier Anwendungen.

Du sprichst aber wohl ohnehin von einem RAM-Test für Summit/Pinnacle Ridge? der Test (https://www.glm.io/127262) wurde sehr oft verlinkt, aber überragend gelesen hat er sich nicht ... wobei ich sagen muss, angesichts von nur einer Seite sind die Abrufe doch recht hoch. Allerdings war die Basisarbeit ja schon gelegt und es sind nur Avg-Fps ... mit Frametimes und Perzentilen steigt der Auswertungsaufwand halt stark an.

Schlag doch mal einfach vor, was genau dir vorschwebt: Anwendungen, Spiele, RAM-Takt samt DR/SR und Latenz und welche CPU sowie Grafikkarte. Dann lässt sich das besser abschätzen.


Vergleich wäre mir da weniger wichtig zu anderen Architekturen mich interessiert da eigentlich vor allem die Skalierung um dann den besten Ram zu kaufen.
Ja den Test von Golem habe ich da auch selber gemeint, verlinke den recht oft und schau da immer wieder rein, vor allem recht gute Spieleauswahl.
Wenns an der Zeit für Anwendungen fehlt die lässt sich auslagern an andere, aber andere haben eben keinen Zugriff auf eine ordentliche RAM Palette ^^
Interessant wäre natürlich Raven und Pinnacle, aber eines von beiden würde erstmal schon reichen ^^

CPU Top Modell und eventuell den beschnittenen Raven um zu sehen ob es da deutliche Unterschiede in Skalierung gibt.
Spiele wäre genial wenn man da statt Shooter usw wo man auf 720p zurückgehen muss welche benutzt die von sich aus CPU Limitiert sind. Wird dann halt eine noch stärkere Nische ... Ein Paradoxtitel wäre zB mal genial und ein 4X Spiel. ( Stellaris wäre beides )
Takt: 2400 ( da oft von OEMS verbaut ) 2933 ( da offizielles maximum ) 3200 ( da oft verkauft und es danach schnell deutlich teurer wird ) 3600 ( oder halt maximum das geht)
mindestens 2 mit SR und DR




Würde ja selber gerne benchen, eventuell mache ich es ja beim Ryzen refresh sogar der soll ja meinen 2600K beerben. Aber da ich gerade am Haus umbauen bin müsste ich halt gucken was ich mir Ram technisch leisten kann ...
Und diese ganzen Standard 08/15 Shooter besitze ich halt eh nicht ...
Aber da wäre meine 1070 wohl eh zu langsam

[danarcho]

Das ist eine etwas merkwürdige Aussage. Zum einen hatten APUs von AMD bisher allesamt keinen L3 Cache. Raven Ridge ist die erste APU mit L3. Und zum anderen ist die gemeinsame Speichernutzung und Cache Kohärenz bei APUs überhaupt nicht möglich ohne dass CPU und GPU auf Cache gemeinsam zugreifen.
Ein gemeinsamer cache ist nicht notwendig für cache coherence, sondern in der Regel hinreichend. Soweit ich weiß hatten aber alle iGPUs bisher ihren eigenen cache (den man ja, wie du schreibst, über ein cache coherence protokoll synchronisieren kann).
Für mich immer noch unbeantwortet ist also die Frage, ob Intel tatsächlich den L3 für die iGPU mitbenutzt. Dann dürfte sich aber eine aktivierte iGPU negativ auf die Performance auswirken, und das hab ich auch noch nie gehört.

[deekey777]

Hat AMD endlich Infos zu VCN rausgerückt?

[mczak]

Da ich das zum ersten Mal höre: Hast du da zufällig irgendeine Quelle für? Würde das gerne mal nachlesen.
Du meinst dafür dass die GPU den L3 nutzen kann bei intel oder eben bei amd nicht?
Für ersteres z.B. hier (für Sandy Bridge):
https://www.realworldtech.com/sandy-bridge-gpu/9/

Für mich immer noch unbeantwortet ist also die Frage, ob Intel tatsächlich den L3 für die iGPU mitbenutzt. Dann dürfte sich aber eine aktivierte iGPU negativ auf die Performance auswirken, und das hab ich auch noch nie gehört.
Glaube nicht dass das so tragisch ist. In dem Artikel steht ja noch dass die GPU den gesamten Cache nutzen kann, das muss aber auch nicht sein (das zu beschränken ist bei assoziativen Caches geradezu trivial).
Ausserdem wird z.B. eine Speicheranfrage für den Display-Controller sicher markiert sein damit die nicht im L3 landet (das machen IIRC GPUs auch intern so, der DC operiert nicht über den L2). Damit wird die CPU auch nur dann allenfalls langsamer wenn die GPU tatsächlich was tut, was ja völlig ok ist.

[aufkrawall]

Hat AMD endlich Infos zu VCN rausgerückt?
Sieht stark nach VP9 8/10 bit nativ aus:
http://forum.doom9.org/showpost.php?p=1831322&postcount=2220

[YfOrU]

Für mich immer noch unbeantwortet ist also die Frage, ob Intel tatsächlich den L3 für die iGPU mitbenutzt. Dann dürfte sich aber eine aktivierte iGPU negativ auf die Performance auswirken, und das hab ich auch noch nie gehört.

Intel Gen9:
https://www.pcper.com/reviews/Graphics-Cards/Intel-Skylake-Gen9-Graphics-Architecture

https://www.pcper.com/files/imagecache/article_max_width/review/2015-08-17/skylakegen9-4.2.jpg
The bus between the GTI and the LLC is adjustable based on performance needs and power concerns. As in Gen8 designs, a processor can utilize 64 byte per cycle reads and writes for the best performance or a product design could implement a 32 byte per cycle write limit to improve power efficiency at a cost of performance.


https://www.pcper.com/files/imagecache/article_max_width/review/2015-08-17/skylakegen9-17.jpg

From the memory angle, Gen9 graphics have several things to take note of. Write performance on coherent SVM (shared virtual memory) is increased thanks to new policies using the last level cache (LLC) while L3 cache capacity has been bumped up to 768 KB per “slice”. Request queue sizes for L3 and LLC have been increased to enhance latency hiding in many cases and texture samplers now support the NV12 YUV format that improves surface sharing capability for compute APIs. The most dramatic change is that move of the eDRAM memory controller to the system agent to allow for display refresh and to act as a memory side cache for the entire chip.

Und: https://software.intel.com/sites/default/files/managed/c5/9a/The-Compute-Architecture-of-Intel-Processor-Graphics-Gen9-v1d0.pdf
Some SoC products include a shared Last Level Cache (LLC) that is also connected to the ring. In such SoCs, each on-die core is allocated a slice of cache, and that cache slice is connected as a unique agent on the ring. However, all of the slices work together as a single cache, albeit a shared and distributed cache. An address hashing scheme routes data requests to the cache slice assigned to its address. This distributed LLC is also shared with Intel processor graphics. For both CPU cores and for Intel processor graphics, LLC seeks to reduce apparent latency to system DRAM and to provide higher effective bandwidth.



Das ist bei Kaveri der Stand der Dinge gewesen und ist dem weit voraus wie Intel im L3 Cache die CPU und GPU Synchronisiert.

Der LLC von Kaveri ist praktisch DRAM. Damit alles andere als flott und würde ich daher nicht als "weit voraus" bezeichnen.

Mit Blick auf die Integration des L3 Caches in die CCX (Zen) und die Verbindung via IF dürfte es bei Raven Ridge effektiv ähnlich sein. Es gibt keinen "system wide" shared LLC abseits DRAM.

[deekey777]

Sieht stark nach VP9 8/10 bit nativ aus:
http://forum.doom9.org/showpost.php?p=1831322&postcount=2220
Und in die andere Richtung? Sprich Encoding?

Auf die schnelle finde ich nicht die Diskussion mit dem Mikhail von AMD, die war in etwa so:

Gibt es ein Whitepaper zu Raven Ridge und dessen VCN?

Wir veröffentlichen keine Whitepapers zu unveröffentlichen Produkten.

Raven Ridge Mobile ist Ende Oktober veröffentlicht worden.

Stimmt, es werden einzelne Produkte verkauft. Ich leite das weiter.


Es gibt weiterhin keinen offiziellen Treiber, auf der AMD-Seite nur Spezifikationen und paar Bildchen, wie toll die mobilen APUs sind.

Gefunden:
https://github.com/GPUOpen-LibrariesAndSDKs/AMF/issues/110

Traurig.

[Loeschzwerg]

https://www.golem.de/news/mi-notebook-air-xiaomi-baut-quadcore-und-nvidia-grafik-ein-1801-132284.html

Und wo bleiben jetzt die kleinen Notebooks mit RR?

Edit:
Ah, da gibt es doch schon ein 13" Notebook gelistet:
https://geizhals.de/lenovo-ideapad-720s-13arr-grau-81br000wge-a1751839.html?hloc=at&hloc=de

[danarcho]

Glaube nicht dass das so tragisch ist. In dem Artikel steht ja noch dass die GPU den gesamten Cache nutzen kann, das muss aber auch nicht sein (das zu beschränken ist bei assoziativen Caches geradezu trivial).
Danke! Erschreckend, dass Intel trotzdem bis Broadwell gebraucht hat für OpenCL 2.0 und SVM.



Der LLC von Kaveri ist praktisch DRAM. Damit alles andere als flott und würde ich daher nicht als "weit voraus" bezeichnen.

Mit Blick auf die Integration des L3 Caches in die CCX (Zen) und die Verbindung via IF dürfte es bei Raven Ridge effektiv ähnlich sein. Es gibt keinen "system wide" shared LLC abseits DRAM.
Ebenfalls danke! Ganz so schlimm ist es zum Glück auch nicht. Über den Interconnect können sich die caches gegenseitig antworten ohne Umweg über den RAM. Die iGPU ist aber auch nicht so auf Latenz angewiesen wie die 2 CCX. Bei Grafik spielt das eh keine Rolle und bei compute sind die Anwendungen noch gar nicht so weit, dass sie GPU und CPU auf den gleichen Daten gleichzeitig operieren lassen.

[Relic]

https://www.golem.de/news/mi-notebook-air-xiaomi-baut-quadcore-und-nvidia-grafik-ein-1801-132284.html

Und wo bleiben jetzt die kleinen Notebooks mit RR?

Edit:
Ah, da gibt es doch schon ein 13" Notebook gelistet:
https://geizhals.de/lenovo-ideapad-720s-13arr-grau-81br000wge-a1751839.html?hloc=at&hloc=de

Das hat Single Channel Ram und auch noch verlötet und nicht aufrüstbar.

[Ravenhearth]

Das hat Single Channel Ram und auch noch verlötet und nicht aufrüstbar.
Der RAM ist laut dieser Seite nicht verlötet (http://laptopmedia.com/highlights/inside-lenovo-ideapad-720s-disassembly-internal-photos-and-upgrade-options/), sondern sehrwohl aufrüstbar. Ändert nur leider nix an Single-Channel, was die APU total verkrüppelt :usad:

[deekey777]

Der RAM ist laut dieser Seite nicht verlötet (http://laptopmedia.com/highlights/inside-lenovo-ideapad-720s-disassembly-internal-photos-and-upgrade-options/), sondern sehrwohl aufrüstbar. Ändert nur leider nix an Single-Channel, was die APU total verkrüppelt :usad:
Die wissen selbst nicht, wie das mit dem Arbeitsspeicher aussieht, https://www3.lenovo.com/de/de/laptops/ideapad/700-series/Ideapad-720S-13-Intel/p/88IP70S0893
Auf der US-Seite steht aber einfach "onboard".
https://www3.lenovo.com/us/en/laptops/ideapad/ideapad-700-series/Ideapad-720S-13-Intel/p/88IP70S0893

Hier das Lenovo Ideapad 720S mit R5 2500U und 512 GB (das ist wohl das teuerste Modell, siehe Notebooksbilliger), https://www3.lenovo.com/us/en/consumer-notebook/ideapad/700s-series/Ideapad-720S-13-AMD/p/88IP70S0929

Los gehen die Preise bei 799, https://www.notebooksbilliger.de/lenovo+720s+13arr+81br000vge/eqsqid/78822b85-b2d5-4cf6-8d36-cd5a82910938 (128 GB Speicher...).

[y33H@]

Zumindest die Intel-Variante des Ideapad 720S (13) hat verlöteten DDR4: http://psref.lenovo.com/Product/Lenovo_Laptops/ideapad_720S_13

[Complicated]

Der LLC von Kaveri ist praktisch DRAM. Damit alles andere als flott und würde ich daher nicht als "weit voraus" bezeichnen.

Ganz so schlimm ist es zum Glück auch nicht. Über den Interconnect können sich die caches gegenseitig antworten ohne Umweg über den RAM.
Eben. Etwas wie LLC gibt es bei AMD gar nicht. Der L3 ist Victim und nicht inklusive. Der Cache hat bei AMD nicht die Aufgabe Daten zu synchronisieren für die heterogenen Recheneinheiten. Das macht nur Intel auf diesem Wege.
In diesem Sinne ist das AMD Design deutlich voraus. Intel hat nach wie vor kein Unified Memory bei heterogenen Zugriffen. Was Speicheranbindung angeht hat AMD die Nase derzeit sowohl bei APUs vorne, als auch bei dGPU mit HBCC und ebenfalls bei der Anbindung in MCMs oder bei Mulit-CPUs mit Infinity Fabric, basierend auf CCIX und Gen-Z. Führt hier aber zu weit. eine interessante Quelle kann man hier lesen: https://www.nextplatform.com/2017/07/12/heart-amds-epyc-comeback-infinity-fabric/

Es hat seinen Grund warum Intel bei Kaby Lake G eine Radeon mit HBCC nutzen will.

[Locuza]

Das macht Intel auf diesem Weg und hat das hat seit Sandy-Bridge entsprechende Vorteile.
Der LCC hilft dabei DRAM-Anfragen von der CPU- und GPU-Seite zu verringern und dank dem Ring-Interconnect und inklusiven Cache-Design ist Data-Sharing effizient und simpel zu bewerkstelligen.

Und was soll kein Unified Memory bei heterogenen Zugriffen bedeuten?
Es gibt seit mindestens Haswell Zero-Copy-Funktionalität und shared virtual memory + globale Cache-Kohärenz ab Broadwell.

Bei Intel ist das Grunddesign seit vielen Generationen in mehreren Aspekten eleganter gelöst, als bei AMD, entsprechend kann ich dem pauschalen Urteil auch gar nicht zustimmen, dass AMDs Design weit voraus wäre.

[BoMbY]

Ja, das Intel-Design ist sehr elegant, bis zum nächsten Meltdown ...

[Complicated]

Und was soll kein Unified Memory bei heterogenen Zugriffen bedeuten?
hUMA ist doch klar definiert:

https://cdn.arstechnica.net/wp-content/uploads/2013/04/huma-diagram.jpg


Es gibt seit mindestens Haswell Zero-Copy-Funktionalität und shared virtual memory + globale Cache-Kohärenz ab Broadwell.Aber nicht bi-direktional GPU<->CPU.
https://software.intel.com/en-us/articles/getting-the-most-from-opencl-12-how-to-increase-performance-by-minimizing-buffer-copies-on-intel-processor-graphics
Damit Speicher gemeinsam genutzt werden kann muss bei Intel ein Adresspool für gemeinsame Nutzung reserviert werden. Es bleiben weiterhin große Teile des Speichers exklusiv CPU und exklusiv GPU und es gibt zusätzlich "buffers" die gemeinsam genutzt werden.

Bei AMD wird der gesamte adressierbare Speicher sowohl CPU und GPU zur Verfügung gestellt und beide nutzen die selben Adressen, wobei hier jeder Recheneinheit auch die Möglichkeit gegeben wird Speicherbereiche für sich exklusiv zu reservieren. Es werden keine gesonderten "gemeinsame buffers" erstellt.

http://www.bjorn3d.com/wp-content/uploads/2013/04/AMD-HSA-hUMA_Page_13.jpg

https://scr3.golem.de/screenshots/1304/AMD-HUMA/thumb620/AMD-HUMA-15.jpg

https://images.anandtech.com/doci/7677/03%20-%20HSA%20Features.jpg

Alles aber schon lange bekannt - wieso muss man das alle 6 Monate wieder in Erinnerung rufen wenn Intels oder Nvidias Marketing mal wieder irgendein virtuelles Memory neu erfindet?

[Hübie]

Ja, das Intel-Design ist sehr elegant, bis zum nächsten Meltdown ...

Bei Milliarden CPUs seit 2011 hat es einige Jahre gedauert bis dieses Problem bekannt wurde. Was macht dich jetzt so sicher, dass AMDs Design nicht auch eine fundamentale Sicherheitslücke hat?
Intel muss offensichtlich auch nichts davon gewusst haben, denn ich kann mir schwer vorstellen, dass man für wenige Prozent bereit ist solch gravierende Lücken wissentlich weiter zu übernehmen bzw. kontinuierlich zu verheimlichen, statt zu fixen.
Ich finde übrigens beide Designs elegant, auf ihre herangehensweisen der Skalierbarkeit bezogen.

[fondness]

hUMA ist doch klar definiert:

https://cdn.arstechnica.net/wp-content/uploads/2013/04/huma-diagram.jpg


Aber nicht bi-direktional GPU<->CPU.
https://software.intel.com/en-us/articles/getting-the-most-from-opencl-12-how-to-increase-performance-by-minimizing-buffer-copies-on-intel-processor-graphics
Damit Speicher gemeinsam genutzt werden kann muss bei Intel ein Adresspool für gemeinsame Nutzung reserviert werden. Es bleiben weiterhin große Teile des Speichers exklusiv CPU und exklusiv GPU und es gibt zusätzlich "buffers" die gemeinsam genutzt werden.

Bei AMD wird der gesamte adressierbare Speicher sowohl CPU und GPU zur Verfügung gestellt und beide nutzen die selben Adressen, wobei hier jeder Recheneinheit auch die Möglichkeit gegeben wird Speicherbereiche für sich exklusiv zu reservieren. Es werden keine gesonderten "gemeinsame buffers" erstellt.

http://www.bjorn3d.com/wp-content/uploads/2013/04/AMD-HSA-hUMA_Page_13.jpg

https://scr3.golem.de/screenshots/1304/AMD-HUMA/thumb620/AMD-HUMA-15.jpg

https://images.anandtech.com/doci/7677/03%20-%20HSA%20Features.jpg

Alles aber schon lange bekannt - wieso muss man das alle 6 Monate wieder in Erinnerung rufen wenn Intels oder Nvidias Marketing mal wieder irgendein virtuelles Memory neu erfindet?

Leider ist man hier der Entwicklung im software Bereich viel zu weit voraus, sodass es nach wie vor keine praktischen Anwendungsfälle für diese moderne Architektur gibt. AMD hat hier viel zu sehr auf diese Verschmelzung CPU/GPU gesetzt und damit womöglich aufs falsche Pferd. Auch GCN ist viel zu stark darauf ausgerichtet als Co Prozessor zu fungieren, während man Grafik vernachlässigt hat. Das Ergebnis ist, dass Nvidia bei Grafik davon gezogen ist und den Rest erledigen sie mit Cuda. Die extrem hohe Flexibilität von GCN kommt kaum zu tragen, mit low level APIs hat man versucht zumindest etwas davon zu profitieren, aber das ist letztlich auch nur schadensbegrenzung.

[Complicated]

Was macht dich jetzt so sicher, dass AMDs Design nicht auch eine fundamentale Sicherheitslücke hat?
Intel muss offensichtlich auch nichts davon gewusst haben, denn ich kann mir schwer vorstellen, dass man für wenige Prozent bereit ist solch gravierende Lücken wissentlich weiter zu übernehmen bzw. kontinuierlich zu verheimlichen, statt zu fixen.
Die Tatsache, dass AMD in der Sprungvorhersage komplette Speicher-Adressen verwendet und Intel nicht. Das ergibt Performancevorteile zu Lasten der Sicherheit bei Intel. Diese Performancevorteile fallen nun Software-Patches zum Opfer, aufgrund des mangelhaften Designs im Bezug auf Sicherheit.

Damit solltest du das im Meltdown/Spectre-Thread weiter vertiefen.

Leider ist man hier der Entwicklung im software Bereich viel zu weit voraus, sodass es nach wie vor keine praktischen Anwendungsfälle für diese moderne Architektur gibt. AMD hat hier viel zu sehr auf diese Verschmelzung CPU/GPU gesetzt und damit womöglich aufs falsche Pferd.
Hier hat sich die letzten Jahre sehr viel getan und ich denke dies hat keine Gültigkeit mehr:
https://gpuopen.com/compute-product/atmi/
Asynchronous Task and Memory Interface, or ATMI, is a runtime framework and programming model for heterogeneous CPU-GPU systems. It provides a consistent API to create task graphs on CPUs and GPUs (integrated and discrete). ATMI is a declarative programming model, where high-level tasks can be simply described by using a few predefined C-style structures. The task description includes specifying its granularity, dependencies to other tasks, data requirements and so on. The ATMI runtime, based on the task graph, will perform task scheduling and memory management that is optimal for the underlying platform.
https://gpuopen.com/whats-new-hip-hcc-rocm-1-6/
HIP now easier-to-use

We’ve made it even easier to port CUDA code to HIP:
The hipLaunchParm extra kernel argument is no longer necessary, and HIP does not modify the function signature for __global__ functions. This removes one of last manual steps in the porting process. Just use “hipLaunchKernelGGL” instead of hipLaunchKernel
HIP_KERNEL_NAME wrapper is only needed if the kernel name include commas. Typically, this only occurs in a template with multiple parameters.
HIP now provides two flavors of the hipify translation tools:
hipify-perl : Does a simple text-based conversion for the CUDA code into HIP. Easy to use and useful for quick scans and conversions, but can be fooled by macros or complex code paths.
hipify-clang: Parses the CUDA code using clang and performs a translation of the symbols. Requires some setup to configure the correct source paths and defines, but provides most robust translation. Useful if you are familiar with the source code and make infrastructure.

https://www.heise.de/developer/artikel/House-of-ROC-AMDs-Alternative-zu-CUDA-3755863.html?seite=all
Hier ein paar Projekte die schon von CUDA mittels HIP portiert wurden:
https://instinct.radeon.com/en/6-deep-learning-projects-amd-radeon-instinct/

[BoMbY]

Bei Milliarden CPUs seit 2011 hat es einige Jahre gedauert bis dieses Problem bekannt wurde. Was macht dich jetzt so sicher, dass AMDs Design nicht auch eine fundamentale Sicherheitslücke hat?
Intel muss offensichtlich auch nichts davon gewusst haben, denn ich kann mir schwer vorstellen, dass man für wenige Prozent bereit ist solch gravierende Lücken wissentlich weiter zu übernehmen bzw. kontinuierlich zu verheimlichen, statt zu fixen.
Ich finde übrigens beide Designs elegant, auf ihre herangehensweisen der Skalierbarkeit bezogen.

Intel hat das Problem vermutlich Jahre lang gekannt, und immer gehofft niemand würde es wirklich merken: https://twitter.com/TheSimha/status/949361495468642304

Und die behaupten immer noch auf ihrer Seite es wäre kein Bug, sondern ein Feature: No. This is not a bug or a flaw in Intel® products. (https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html)

[danarcho]

Damit Speicher gemeinsam genutzt werden kann muss bei Intel ein Adresspool für gemeinsame Nutzung reserviert werden. Es bleiben weiterhin große Teile des Speichers exklusiv CPU und exklusiv GPU und es gibt zusätzlich "buffers" die gemeinsam genutzt werden.
...
Alles aber schon lange bekannt - wieso muss man das alle 6 Monate wieder in Erinnerung rufen wenn Intels oder Nvidias Marketing mal wieder irgendein virtuelles Memory neu erfindet?
Das hat nichts mit Marketing zu tun. Die OpenCL Antwort auf hUMA / HSA war SVM und in der fine-grained system SVM Variante bietet sie ebenfall cache coherence mit relaxed consistency für den kompletten System RAM.
Intel hat das ganze über seinen LLC realisiert. Ob das eleganter ist oder nicht: Es ist das gleiche Ergebnis. Du kannst cache coherence entweder mit mehreren caches über ein Protokoll erreichen oder du nimmst einfach einen shared cache, fertig. Ich würde sogar so weit gehen zu sagen, dass Intel Gen 8+ HSA-fähig wäre, bin mir aber in den Details der Spezifikationen nicht 100% sicher.

[Complicated]

Das hat nichts mit Marketing zu tun. Die OpenCL Antwort auf hUMA / HSA war SVM und in der fine-grained system SVM Variante bietet sie ebenfall cache coherence mit relaxed consistency für den kompletten System RAM.
Intel hat das ganze über seinen LLC realisiert. Ob das eleganter ist oder nicht: Es ist das gleiche Ergebnis. Du kannst cache coherence entweder mit mehreren caches über ein Protokoll erreichen oder du nimmst einfach einen shared cache, fertig. Ich würde sogar so weit gehen zu sagen, dass Intel Gen 8+ HSA-fähig wäre, bin mir aber in den Details der Spezifikationen nicht 100% sicher.
Es ist immer noch ein virtueller Speicher der initialisiert wird über Software - keine Hardware-Implementierung.
https://software.intel.com/en-us/node/695941
Shared Virtual Memory (SVM) is a programming model that allows sharing virtual address space between the CPU and the processor graphics.
Während AMD mit dem HBCC und Infinity Fabric mittlerweile auf reinen Hardware-Lösungen angekommen ist und memory read/write atomics selbst in angebundenem Netzwerkspeicher ermöglicht (basierend auf CCIX und GenZ), zieht Intel mit SVM gerade mal zu HSA nach, wo eben Software angepasst werden muss für die Nutzung des gemeinsamen Speichers.
Das hier fasst es gut zusammen:
https://lists.linuxfoundation.org/pipermail/iommu/2017-June/022394.html

Diesen Schritt kannst du nicht gehen mit Intels Implementierung, da diskrete GPUs den L3 der CPU nicht nutzen können. Das ist auch der Grund warum Intel nun AMD Hardware mit HBCC implementiert auf seinen Packages.

[Hübie]

Intel hat das Problem vermutlich Jahre lang gekannt, und immer gehofft niemand würde es wirklich merken: https://twitter.com/TheSimha/status/949361495468642304

Und die behaupten immer noch auf ihrer Seite es wäre kein Bug, sondern ein Feature: No. This is not a bug or a flaw in Intel® products. (https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html)

Bei einem großen Konzern ist es schwer die richtigen Entscheider zu treffen. Ich will das nicht verharmlosen, aber lass uns doch mal eben definieren wer alles Intel ist und wer das alles wusste. Wahrscheinlich wurde es auf mittlerer Management-Ebene totgeschwiegen, weil Intel noch viele alte Strukturen und latente Hierarchien hat in denen konkurriert wird und in denen Machtkämpfe mit Angst ausgefochten werden.

Übrigens meinte ich nicht explizit Fehler in Sprungvorhersage, denn Angriffsvektoren gibt es sicher genug (auch bei GPUs ist das nicht ohne).

[Complicated]

Also ich weiss, dass bisher in Raven Ridge APUs keine solchen Angriffsvektoren gefunden wurden.
Verbreitest du gerade einfach nur FUD oder gibt es auch etwas substantielles zu diesem selbst erdachten Thema, das auch Raven Ridge betrifft?

[danarcho]

Es ist immer noch ein virtueller Speicher der initialisiert wird über Software - keine Hardware-Implementierung.
https://software.intel.com/en-us/node/695941

Während AMD mit dem HBCC und Infinity Fabric mittlerweile auf reinen Hardware-Lösungen angekommen ist und memory read/write atomics selbst in angebundenem Netzwerkspeicher ermöglicht (basierend auf CCIX und GenZ), zieht Intel mit SVM gerade mal zu HSA nach, wo eben Software angepasst werden muss für die Nutzung des gemeinsamen Speichers.
Das hier fasst es gut zusammen:
https://lists.linuxfoundation.org/pipermail/iommu/2017-June/022394.html

Diesen Schritt kannst du nicht gehen mit Intels Implementierung, da diskrete GPUs den L3 der CPU nicht nutzen können. Das ist auch der Grund warum Intel nun AMD Hardware mit HBCC implementiert auf seinen Packages.
Du missverstehst da einiges und widersprichst dir auch noch.
1. SVM ist keine Software-Lösung, sondern muss in Hardware unterstützt werden. (zum Beispiel über einen shared LLC (wtf zum 3. mal?!)). Fine-grained system SVM hat als Voraussetzung cache coherence, relaxed consistency und flat addressing, also genau das gleiche wie HSA. HSA hat zusätzlich noch preemption. Der ganze Rest (z.B device-side enqueueing von CPU threads) ist dann tatsächlich Software bzw Runtime.
Btw. ist SVM auch kein Programmiermodell, egal was Intel da behauptet. Aber mittlerweile wird ja fast alles als Programmiermodell bezeichnet...
2. Der mailinglist-Post bezieht sich genau auf system shared memory (siehe nächster post), also darauf, auf Host-Speicher coherent zuzugreifen. Die erwähnten Software-Anpassungen meinen genau nicht die Anwendungen, sondern den Kernel, weil dort das paging vorgenommen wird. Die Anwendungen dürfen danach Speicher einfach über malloc() alloziieren. Ich weiß aber bis jetzt nur von der HSA-Runtime in Verbindung mit Bristol Ridge, dass das wirklich geht. Hardware-mäßig könnten das aber auch Intel Gen8/9, ARM Bifrost, die neuen Qualcomm und schließlich natürlich Raven Ridge.
3. Das besondere am HBCC ist es, coherente Speicherzugriffe (caches eingeschlossen) auf diskrete Geräte auszudehnen. Das geht natürlich nur sehr langsam über PCIe, aber immerhin geht es mal. Intel hat überhaupt keine diskreten GPUs, also wo sollen sie das vermissen?

[Locuza]

hUMA ist doch klar definiert:

Aber nicht bi-direktional GPU<->CPU.
https://software.intel.com/en-us/articles/getting-the-most-from-opencl-12-how-to-increase-performance-by-minimizing-buffer-copies-on-intel-processor-graphics
Damit Speicher gemeinsam genutzt werden kann muss bei Intel ein Adresspool für gemeinsame Nutzung reserviert werden. Es bleiben weiterhin große Teile des Speichers exklusiv CPU und exklusiv GPU und es gibt zusätzlich "buffers" die gemeinsam genutzt werden.

Bei AMD wird der gesamte adressierbare Speicher sowohl CPU und GPU zur Verfügung gestellt und beide nutzen die selben Adressen, wobei hier jeder Recheneinheit auch die Möglichkeit gegeben wird Speicherbereiche für sich exklusiv zu reservieren. Es werden keine gesonderten "gemeinsame buffers" erstellt.
[BILDER]

Alles aber schon lange bekannt - wieso muss man das alle 6 Monate wieder in Erinnerung rufen wenn Intels oder Nvidias Marketing mal wieder irgendein virtuelles Memory neu erfindet?
Kein Stichwort bei hUMA wird nicht von den neusten Intel SoCs umgesetzt.
Und die Cache-Coherence funktioniert bi-direktional.

OpenCL legt als Standard Funktionen und Programmiermethoden fest und entsprechend gibt es aus der Sicht des Entwicklers keinen Unterschied zwischen den Prozessoren, solange die genutzten Funktionen unterstützt werden.
Ganz analog zu DX/Vulkan.

Shared-Buffer waren ein Konzept, welches unter OCL1.x verwendet werden konnte und von AMD seit Llano und spätestens von Intel ab Haswell unterstützt wurde.
Shared Virtual Memory von OCL2.x geht viel weiter und wird entsprechend ab Kaveri und Broadwell unterstützt.

Aus Intels Gen8/9 Dokumentation:

[B]5.7.1 Unified Memory Architecture
Intel processor graphics architecture has long pioneered sharing DRAM physical memory with the CPU.
This unified memory architecture offers a number of system design, power efficiency, and programmability advantages over PCI Express-hosted discrete memory systems.
The obvious advantage is that shared physical memory enables zero copy buffer transfers between CPUs and gen9 compute architecture.
By zero copy, we mean that no buffer copy is necessary since the physical memory is shared.
Moreover, the architecture further augments the performance of such memory sharing with a shared LLC cache.

The net effect of this architecture benefits performance, conserves memory footprint, and indirectly conserves system power not spent needlessly copying data.
Shared physical memoryand zero copy buffer transfers are programmable through the buffer allocation mechanisms in APIs such as OpenCL 1.0+ and DirectX11.2+.

5.7.2 Shared Memory Coherency
Gen9 compute architecture supports global memory coherency between Intel processor Graphics and the CPU cores.
SoC products with Intel processor graphics gen9 integrate new hardware components to support the recently updated Intel® Virtualization Technology(Intel® VT) for Directed I/O (Intel® VT-d) specification.
This specification extends IntelVT, which generally addresses virtual machine to physical machine usage modelsand enables virtual machine monitor implementation.
In particular, the recent Intel VT-d specification extensions define newpage table entry formats, cache protocols, and hardware snooping mechanisms for shared memory between CPU cores and devices such as Intel processor graphics.

These new mechanisms can be used to maintain memory coherency and consistency for fine grained sharing throughout the memory hierarchy between CPU cores and devices.
Moreover, the same virtual addresses can be shared seamlessly across devices.
Such memory sharing is application-programmable through emerging heterogeneous compute APIs such as the shared virtual memory (SVM) features specified in OpenCL 2.0.
The net effect is that pointer-rich data-structures can be shared directly between application code running on CPU cores with application code running on Intel processor graphics, without programmer data structure marshalling or cumbersome software translation techniques.
Within Intel processor graphics, the dataport unit, L3 data cache, and GTI have all been upgraded to support a new globally coherent memory type.

Reads and writes originating from Intel processor graphics to memory typed as globally coherent and drive Intel VT-d-specified snooping protocols to ensure data integrity with any CPU core cached versions of that memory.
Conversely, the same is true for GPU cached memory and reads and writes that originate from the CPU cores.
https://software.intel.com/sites/default/files/Compute%20Architecture%20of%20Intel%20Processor%20Graphics%20Gen8.pdf

Oder als simples Marketing-Bild:
https://abload.de/img/intelsocyyol6.jpg
(Seite 16)
http://www.highperformancegraphics.org/wp-content/uploads/2015/Hot3D2/Compute_Architecture_of_Intel_Processor_Graphics_Gen8_HPGHot3D2015.pdf

[Complicated]

Nochmal für dich zitiert
Es ist immer noch ein virtueller Speicher der initialisiert wird über Software - keine Hardware-Implementierung.
https://software.intel.com/en-us/node/695941

Während AMD mit dem HBCC und Infinity Fabric mittlerweile auf reinen Hardware-Lösungen angekommen ist und memory read/write atomics selbst in angebundenem Netzwerkspeicher ermöglicht (basierend auf CCIX und GenZ), zieht Intel mit SVM gerade mal zu HSA nach, wo eben Software angepasst werden muss für die Nutzung des gemeinsamen Speichers.
Das hier fasst es gut zusammen:
https://lists.linuxfoundation.org/pipermail/iommu/2017-June/022394.html

Diesen Schritt kannst du nicht gehen mit Intels Implementierung, da diskrete GPUs den L3 der CPU nicht nutzen können. Das ist auch der Grund warum Intel nun AMD Hardware mit HBCC implementiert auf seinen Packages.

Intel hat seine GPU-Abteilung praktisch geschlossen wegen Erfolglosigkeit und Entwicklung in eine Sackgasse und quasi rebootet mit Raja Koduri.
Intel verbaut Radeon GPUs auf Intel Packages um den Anschluß nicht zu verlieren.
Wie kann man unter diesen Tatsachen leugnen, dass Intel weit zurück liegt in der Entwicklung von GPU-Technologie und damit verbunden auch beim Speichermanagement in heterogenen Umgebungen?

[Locuza]

Dann verweise ich auf den schön geschriebenen Beitrag von danarcho oben, welcher ebenso auf deinen Beitrag eingeht und mehr Punkte von dir aufgreift.

[gravitationsfeld]

Intels GPUs hinken AMDs in vor allem in Sachen Effizienz hinterher. Fehlendes HBCC ist definitiv nicht das Problem.

[Complicated]

Aber gerne Locuza - den hatte ich gar nicht gelesen, da übersehen
Du missverstehst da einiges und widersprichst dir auch noch.
1. SVM ist keine Software-Lösung, sondern muss in Hardware unterstützt werden.
SVM ist auch keine Hardware-Lösung, sondern muss in Software unterstützt werden, wie ja der Link zeigt den ich dir dazu gab.

2. Der mailinglist-Post bezieht sich genau auf system shared memory (siehe nächster post), also darauf, auf Host-Speicher coherent zuzugreifen.Er beschreibt die drei unterschiedlichen Stufen.
1. Reine Hardware-Impletation (CCIX, GenZ - und dazu gehört auch HBCC von AMD, aber es gibt keine Intel Lösung die dort rein gehört
2. HSA und SVM von Intel (Hardware+Sotware kombination nötig)
3. Reine Software Lösungen

3. Das besondere am HBCC ist es, coherente Speicherzugriffe (caches eingeschlossen) auf diskrete Geräte auszudehnen. Das geht natürlich nur sehr langsam über PCIe, aber immerhin geht es mal. Intel hat überhaupt keine diskreten GPUs, also wo sollen sie das vermissen?
HBCC ist nicht langsam. Das wäre ungefähr so als ob du L1 Cache für langsam halten würdest, weil das letzte Glied in der Kette zum Speicherzugriff die Geschwindigkeit des DDR4 RAMs ist.

Intel muss keine diskreten GPUs haben, um ein heterogenes Speichermanagement mit seinen Stratix FPGAs herzustellen. Heterogenes Computing und Speichermanagement ist essentiell für den Server-Space geworden, da reine CPU-Umgebungen im HPC nach und nach aussterben.
Intels GPUs hinken AMDs in vor allem in Sachen Effizienz hinterher. Fehlendes HBCC ist definitiv nicht das Problem.
Das mag richtig sein, doch mein Thema war heterogenes Speichermanagement und der AMD Vorsprung auf diesem Feld. Nicht die GPUs von Intel, die sowieso hinterher hinken. Und da gehört nun mal HBCC als letzte Ausbaustufe sehr wohl dazu.

[Locuza]

SVM ist ein Softwarestandard unter OCL2.0 und stellt spezifische Anforderungen an die Hardware, um unterstützt zu werden.
Ohne passende Hardware, kein SVM-Support oder viel allgemeiner, ohne die entsprechende Hardwarefähigkeiten kein OCL2.0 Support.
Intels Hardware hat alle nötigen Fähigkeiten in der Hardware implementiert, um diesen Standard zu unterstützen und genauso hat AMD alles nötige in der Hardware implementiert, um OCL2.0 und Features wie SVM zu unterstützen.
http://www.planet3dnow.de/cms/wp-content/gallery/amd-catalyst-omega/45-AMD-Catalyst-Omega.jpg
http://www.planet3dnow.de/cms/13545-amd-catalyst-omega-14-12-spezialedition-treiber/subpage-opencl-2-0-entwickler-tools/

Die zugrundelegende Hardware muss man schließlich irgendwie ausnutzen und ansprechen können, automagisch ohne irgendeinen Funktionsaufruf wird die Hardware solche Aufgaben nicht erledigen, wenn gar kein passender Software-Stack existiert.
Entsprechend ist die Darstellung das es bei AMD eine reine Hardware-Lösung darstellt, während bei Intel eine SW+HW-Lösung gar nicht korrekt.

[YfOrU]

Intel hat seine GPU-Abteilung praktisch geschlossen wegen Erfolglosigkeit und Entwicklung in eine Sackgasse und quasi rebootet mit Raja Koduri.

Ich würde eher sagen das Intels GPU Abteilung welche in erster Linie IGPs entwickelt in den letzten ~7 Jahren durchaus erfolgreich war. Die Verbreitung von Low End/Entry dGPUs ist deshalb sowohl am Desktop als auch Mobile sehr deutlich zurück gegangen. Das Feature Set ist heute absolut vorzeigbar und mit Iris (+eDRAM) hat man sich bei Intel auch endlich mal weiter nach oben bewegt und Ambitionen gezeigt. Hinzufügen muss man das Intels GPU Architektur von ULP (wenige mW) ausgehend skaliert. Das von einem Unternehmen wie Intel mehr wünschenswert ist - keine Frage.


Intel verbaut Radeon GPUs auf Intel Packages um den Anschluß nicht zu verlieren.

In diesem Segment war Intel bisher überhaupt nicht vertreten. Selbst GT4e lag noch deutlich darunter.

Genaugenommen profitiert AMD von Kaby Lake-G mehr als Intel. Über diesen "Umweg" bekommt AMD wieder größeren Zugang zum Markt ohne direkt mit Nvidia in Konkurrenz treten zu müssen. Bezogen auf mobile dGPUs ist AMD seit Jahren nicht mehr richtig konkurrenzfähig (Performance/Watt sowie benötigte Speicherbandbreite) und entsprechend sehen die Marktanteile aus.

Das AMD Intels Gen9 mit Raven Ridge (Vega) deklassiert ist keine so große Leistung. Mit 8 - 11 CUs wurde eine vergleichsweise sehr fette IGP integriert (DIE Size, Kosten) und Gen9 ist schon recht alt. Die vielen Verzögerungen (Fertigung) auf Intels Roadmap tragen ihren Teil dazu bei. Aktuell ist AMD hier gegenüber Intel richtig gut aufgestellt. Mittelfristig sehe ich auf AMD aber Probleme zukommen wenn die GPU Sparte nicht bald wieder auf einen grünen Zweig kommt. Intel wird nicht auf Ewigkeiten dGPUs von AMD beziehen und darüber hat man mit Nvidia einen ganz harten Konkurrenten.

[basix]

Vega Mobile scheint ähnlich so gute Perf/W zu haben wie Nvidia Pascal. So schlecht finde ich das nicht ;) Nvidia war aber einfach 1.5 Jahre früher da.

[maguumo]

Dank HBM, niedrigerem Takt und riesigem Die. Viel Aufwand um GP108 zu schlagen.

[YfOrU]

Bei KBL-G wird die TDP dynamisch verteilt (bei GPU Last von Vorteil) und via HBM kann AMD den hohen Bedarf an Bandbreite "verstecken" ohne das es sich negativ auf die Verlustleistung auswirkt. Gleichzeitig sollte der Energiebedarf grundsätzlich ein Stück unter 128Bit GDDR5 liegen.

Deshalb auch meine Aussage das KBL-G für AMD in der aktuellen Situation (mobile dGPUs) fast schon ein Geschenk ist. Auf regulärem Weg ist es kaum möglich Nvidia größere Marktanteile in diesem lukrativen Bereich abzunehmen. Dafür fehlt leider auch ein aktuelles Portfolio an mobilen dGPUs über alle Performance Segmente. Man ist vor allen von Apple abhängig und das ist auf längere Sicht für viele Zulieferer nicht so gut gelaufen.

[Pirx]

dafür gibts doch Raven Ridge, um den es rein zufällig auch hier geht;)

[YfOrU]

Raven Ridge ist für 15 - 25W Mobile ein super Produkt. Teure mobile dGPUs (mit sehr hoher Marge, siehe Nvidia) wird man darüber aber eher nicht im großen Stil absetzen können. Das ist das Segment von CFL (6C/12T) mit dGPU.

[Pirx]

und dafür gibts jetzt den total irregulären Kaby-G und irgendwann Vega mobile. Was sich darüber noch Mobilgrafik schimpft, dürfte AMD derzeit weniger interessieren.

[mboeller]

Dank HBM, niedrigerem Takt und riesigem Die. Viel Aufwand um GP108 zu schlagen.

so groß ist das Die vom VEGA-M auch nicht. Ich komme auf ca. 210-215mm², wenn die Schemas unten in dem Link stimmen. Ein GTX1060 Die (GP106) ist auch ca. 200mm² groß.

Und so niedrig ist der Takt auch nicht. Max. 1190MHz, fast der Standard-Takt einer RX580.

https://en.wikichip.org/wiki/intel/microarchitectures/kaby_lake


Der Vergleich mit dem GP108 ist wohl ein wenig :freak:

[mboeller]

Raven Ridge ist für 15 - 25W Mobile ein super Produkt. Teure mobile dGPUs (mit sehr hoher Marge, siehe Nvidia) wird man darüber aber eher nicht im großen Stil absetzen können. Das ist das Segment von CFL (6C/12T) mit dGPU.

Kaby-Lake G ist doch schon "Highend" 4C/8T + eGPU mit zusammen 65W oder gar 100W.

[fondness]

Intel hat seine GPU-Abteilung praktisch geschlossen wegen Erfolglosigkeit und Entwicklung in eine Sackgasse und quasi rebootet mit Raja Koduri.

Wenn es nur die GPU Entwicklung wäre. Skylake ist von 2015. Sowohl CPU als auch GPU seitig kommt von Intel seit 2015 nichts neues mehr. Sie haben das enorme Glück, dass sie ein Monopol haben und kaum mehr ein Konkurrent vorhanden ist. Jedes andere Unternehmen, dass im Wettbewerb steht, hätte nach einem solchen track record wohl ein ernsthaftes Problem.

[fondness]

so groß ist das Die vom VEGA-M auch nicht. Ich komme auf ca. 210-215mm², wenn die Schemas unten in dem Link stimmen. Ein GTX1060 Die (GP106) ist auch ca. 200mm² groß.

Und so niedrig ist der Takt auch nicht. Max. 1190MHz, fast der Standard-Takt einer RX580.

https://en.wikichip.org/wiki/intel/microarchitectures/kaby_lake


Der Vergleich mit dem GP108 ist wohl ein wenig :freak:

Richtig, das zeigt, wie auch schon robbitop angemerkt hatte, dass die Vega Architektur sehr viel konkurrenzfähiger ist, als es Vega10 zu zeigen vermag. Vega10 hat leider die Probleme von Fiji geerbt, nämlich ein viel zu kleines front und backend für das riesige shader array. Fiji war ja im Grunde nicht mehr wie ein aufgeblasener Hawaii. Das zeigt, wie nötig Navi ist, der hoffentlich wirklich die versprochene bessere Skalierbarkeit nach oben mitbringt.

[deekey777]

Raven Ridge ist für 15 - 25W Mobile ein super Produkt. Teure mobile dGPUs (mit sehr hoher Marge, siehe Nvidia) wird man darüber aber eher nicht im großen Stil absetzen können. Das ist das Segment von CFL (6C/12T) mit dGPU.
Was sind denn teure dGPUs?

Mit den RR-APUs greift AMD nicht nur Intel an, sondern in das Segment, in dem fragwürdige Grafikkarten verbaut werden, aber auch die MX150: "Seht her, liebe OEMs, ihr braucht gar nicht Kombos aus CPU wie KBL/KBL-R und einer dedizierten Grafikkarte wie 920-950MX mit deren zusätzlichem Speicher, es reicht, wenn ihr unsere APUs verbaut. Und wenn ihr keine zusätzlichen Grafikkarten verbaut, könnt ihr mit unserer Grafikleistung werben."

Der Wahnsinn ist, dass Dell für seine RR-Notebooks auch eine R530 anbieten wird.

Ob AMD in den Bereich "darüber" schafft, wird sich zeigen müssen. Mit KBL-G hat sich AMD den Weg einserseits versperrt, auf der anderen Seite hat man mit Intel einen Abnehmer eigener GPUs. KBL-R werden weiterhin mit zusätzlichen Grafikkarten kombiniert, da hat AMD nichts zu melden. Bisher gibt es nur eine Ankündigung von Asus, wo eine APU mit einer RX 560 kombiniert wird. Sprich: Hier werden Kombos aus KBL-R/-H und einer Nvidia-Grafikkarte dominieren, Laptops mit RR-APU und einer starken dedizierten Grafikkarte (egal ob Polaris oder Pascal) werden wohl Ausnahmen bleiben.

[Loeschzwerg]

Erste Listung mit Ryzen 3 2200U:
https://geizhals.de/acer-aspire-3-a315-41-r3az-nx-gy9ev-004-a1758240.html


Der Wahnsinn ist, dass Dell für seine RR-Notebooks auch eine R530 anbieten wird.


Wo du es gerade ansprichst :freak: https://geizhals.de/acer-aspire-3-a315-41g-r40x-nx-gy9ev-001-a1758214.html

[Pirx]

... KBL-R werden weiterhin mit zusätzlichen Grafikkarten kombiniert, da hat AMD nichts zu melden. ...
Doch, mit Vega Mobile, wenn der denn irgendwann mal rauskommt.

[danarcho]

Ich weiß echt nicht, wozu ich etwas erkläre; du scheinst dir ja mit deinem Halbwissen ganz gut zu gefallen. ;(
Er beschreibt die drei unterschiedlichen Stufen.
1. Reine Hardware-Impletation (CCIX, GenZ - und dazu gehört auch HBCC von AMD, aber es gibt keine Intel Lösung die dort rein gehört
2. HSA und SVM von Intel (Hardware+Sotware kombination nötig)
3. Reine Software Lösungen

Das Problem ist, dass es zwar bei allen Dingen um den Zugriff auf Host-Speicher geht, aber es sich um unterschiedliche Architekturen handelt. 1 und 2 in deiner Liste sind völlig verschiedene Paar Schuhe.
Diskrete Geräte sind immer NUMA-Architekturen. Der Speicher ist physikalisch getrennt. CCIX und HBCC erlauben zwar dem Hersteller, das Speichermanagement (vom Treiber) direkt im Userspace zu implementieren (Das OS sieht nur einen erweiterten physikalischen Addressraum). Aber um einigermaßen vernünftige Performance zu haben, kommst du um Anpassungen der Anwendungssoftware nicht herum.

APUs sind UMA-Architekturen. Der Speicher ist physikalisch der selbe! Das erlaubt performante zero-copy Speicherzugriffe. Als Entwickler musst du dir keine Gedanken darum machen, wo welcher Speicher alloziiert wird, weil GPU und CPU gleich schnell auf alles zugreifen können. Dinge wie CCIX oder HBCC sind nicht notwendig.

Die beiden Dinge sind keine unterschiedlichen Entwicklungsstufen, sondern Lösungen für verschiedene Architekturen. Und keines ist dem anderen überlegen. Die APUs sind deutlich eleganter zu programmieren und erlauben z.B. schöne producer-consumer Sachen mit hohem Anteil seriellen Code. Die diskreten GPUs haben halt die höhere Performance, benötigen aber explizites Speichermanagement und haben hohe Latenzen. (HBCC im cache-modus ist ungefähr in der Mitte.)


HBCC ist nicht langsam. Das wäre ungefähr so als ob du L1 Cache für langsam halten würdest, weil das letzte Glied in der Kette zum Speicherzugriff die Geschwindigkeit des DDR4 RAMs ist.
Lies halt nochmal, was ich wirklich gesagt habe.

[Complicated]

Entsprechend ist die Darstellung das es bei AMD eine reine Hardware-Lösung darstellt, während bei Intel eine SW+HW-Lösung gar nicht korrekt.
Und welche Software Anpassungen sind nun nötig für den HBCC? Keine.
Hat Intel eine vergleichbare Lösung beim Speichermanagement? Keine
Was ist hier falsch dargestellt?
HSA und SVM sind gleichwertig und HBCC ist die auf HSA basierende Weiterentwicklung beim heterogenen Speichermanagement, welche Intel dringend benötigt für das Serverumfeld. Da ist Intel weit zurück.

@danarcho
Das mag daran liegen, dass du am Thema vorbei erklärst. APUs sind weder UMA noch NUMA Architekturen. Es sind hUMA Architekturen. Ein heterogenes Umfeld ist etwas anderes als wenn 4 CPU-Dies die Speicherzugriffe optimieren sollen wie es z.B. in Epyc passiert. Vor allem wenn man bei AMD in der Lage ist zwischen UMA und NUMA hin und her zu switchen je nach Bedarf in den modernen MCM-Produkten. (Threadripper und EPYC)

Diskrete GPUs der Vega Serie sind keine ausschließlichen NUMA-Devices mehr dank Infinity Fabric, welche CCIX und Genz Technik nutzen.

http://i.imgur.com/aYDcW0N.jpg

https://www.ccixconsortium.com/single-post/2017/06/28/Welcome-to-the-new-CCIX-Blog
What is CCIX?

CCIX (pronounced “See-6”) defines a cache-coherent multichip interconnect that brings a new class of performance and efficiency to evolving and emerging acceleration use cases within cloud, data center, and networking systems. CCIX is the industry’s first interconnect technology specification dedicated to ensuring that processors using different instruction set architectures (ISA) can coherently share data with accelerators and enable efficient heterogeneous computing over low-latency PCIe interfaces operating up to 25Gb/s per lane with a future examining 56GT/s and beyond.

CCIX expands upon PCI Express to allow interconnected components to access and share cache-coherent data similar to a processor core. The CCIX interconnect operates at up to 25Gb/s per lane, providing 3X speed up over present industry standard PCIe Gen3 interfaces running at 8Gb/s, and 56% faster than upcoming PCIe Gen4 interfaces operating at 16Gb/s. CCIX is backward compatible with PCIe 3.0 and 4.0, leveraging existing server ecosystems and form factors while lowering software barriers.

[deekey777]

Erste Listung mit Ryzen 3 2200U:
https://geizhals.de/acer-aspire-3-a315-41-r3az-nx-gy9ev-004-a1758240.html
Der Preis wird bestimmt noch nach unten gehen.



Wo du es gerade ansprichst :freak: https://geizhals.de/acer-aspire-3-a315-41g-r40x-nx-gy9ev-001-a1758214.html
Was ist jetzt eine Radeon 530X? 6 CUs? Wenigstens hat das Teil GDDR5, aber so ein Schwachsinnsteil. Vielleicht mit 2xMSAA wird sie schneller sein. :ulol:

Doch, mit Vega Mobile, wenn der denn irgendwann mal rauskommt.
Wenn sie mal rauskommt. Sie wird langsamer sein als RX570/RX580 und damit vielleicht alles darunter abdecken, aber spätestens bei der 1060 ist Schluss, während Nvidia noch mobile 1070/1080 anbietet.

[danarcho]

Und welche Software Anpassungen sind nun nötig für den HBCC? Keine.
Hat Intel eine vergleichbare Lösung beim Speichermanagement? Keine
Was ist hier falsch dargestellt?
HSA und SVM sind gleichwertig und HBCC ist die auf HSA basierende Weiterentwicklung beim heterogenen Speichermanagement, welche Intel dringend benötigt für das Serverumfeld. Da ist Intel weit zurück.
HBCC ist eben keine Weiterentwicklung von HSA, sondern der Versuch das HSA-Konzept auf diskrete GPUs zu übertragen. Schreib mal eine Zeile OpenCL und dann reden wir nochmal über Software-Anpassungen.

@danarcho
Das mag daran liegen, dass du am Thema vorbei erklärst. APUs sind weder UMA noch NUMA Architekturen. Es sind hUMA Architekturen. Ein heterogenes Umfeld ist etwas anderes als wenn 4 CPU-Dies die Speicherzugriffe optimieren sollen wie es z.B. in Epyc passiert. Vor allem wenn man bei AMD in der Lage ist zwischen UMA und NUMA hin und her zu switchen je nach Bedarf in den modernen MCM-Produkten. (Threadripper und EPYC)
hUMA ist ein Marketing-Begriff und der Rest ist einfach falsch.

Diskrete GPUs der Vega Serie sind keine ausschließlichen NUMA-Devices mehr dank Infinity Fabric, welche CCIX und Genz Technik nutzen.

Das ist auch falsch. VEGA wird erst dank HBCC zu einer NUMA-Architektur.

[robbitop]

Vega M GH soll laut Intel die 1060 max q knapp schlagen können. Wenn ich mir die Taktraten und die resultierende Rohleistung anschaue, kommen beide auf vergleichbare Rohleistung raus. ~3,5 tflops.
Das wäre für Vega eine grandiose Leistung.

Warum das so sein kann:

1. Vega M GH hat relativ viele ROPs für relativ wenige CUs (64 rops auf 24 cus) - (19,2 gpix/tflop statt nur 7,8 der V64)
2. Vega M GH hat relativ viel Bandbreite für Die kleine Rechenleistung. 56 gb/tflop (vega64 hat nur 38,7gb/tflop
3. GCN skaliert relativ mäßig mit den CUs da nicht wie bei NV mit den GPCs alles mitskaliert wird. Cape Verde (640 alus) war pro tflop die schnellste gcn 1.x gpu. Je mehr ALUs je schlimmer wurde es. Pitcairn (1280), Tahitii (2048), Hawaii (2816) und Fijii (4096). -> V64 ist hier pro tflop auch nicht schneller als fijii

Obiges betrifft Spieleleistung.

Wahrscheinlich meint „better scalability“ in amds roadmap genau das für Navi.

[dildo4u]

Diese Games haben alle ein DX12 Modus wurde vermutlich nicht umsonst gewählt.

http://abload.de/img/intel-8th-generation-far7x.png

[fondness]

Vega M GH soll laut Intel die 1060 max q knapp schlagen können. Wenn ich mir die Taktraten und die resultierende Rohleistung anschaue, kommen beide auf vergleichbare Rohleistung raus. ~3,5 tflops.
Das wäre für Vega eine grandiose Leistung.

Warum das so sein kann:

1. Vega M GH hat relativ viele ROPs für relativ wenige CUs (64 rops auf 24 cus) - (19,2 gpix/tflop statt nur 7,8 der V64)
2. Vega M GH hat relativ viel Bandbreite für Die kleine Rechenleistung. 56 gb/tflop (vega64 hat nur 38,7gb/tflop
3. GCN skaliert relativ mähig mit den CUs da nicht wie bei NV mit den GPCs alles mitskaliert wird. Cape Verde (640 alus) war pro tflop die schnellste gcn 1.x gpu. Je mehr ALUs je schlimmer wurde es. Pitcairn (1280), Tahitii (2048), Hawaii (2816) und Fijii (4096). -> V64 ist hier pro tflop auch nicht schneller als fijii

Obiges betrifft Spieleleistung.

Wahrscheinlich meint „better scalability“ in amds roadmap genau das für Navi.

Man kann es auch auf den Punkt bringen: Vega M scheint dasselbe Frontend zu haben wie Vega10 (Quad Geometrie Engine) dasselbe Backend (64 ROPs) und das Halbe SI (1024 bit HBM2). Den selben Aufbau hatten im übrigen auch schon Hawaii und Fiji. Spätestens mit Fiji war das massiv unterdimensioniert. Vega10 hat daran nicht wirklich was geändert.

[maguumo]

so groß ist das Die vom VEGA-M auch nicht. Ich komme auf ca. 210-215mm², wenn die Schemas unten in dem Link stimmen. Ein GTX1060 Die (GP106) ist auch ca. 200mm² groß.

Und so niedrig ist der Takt auch nicht. Max. 1190MHz, fast der Standard-Takt einer RX580.

https://en.wikichip.org/wiki/intel/microarchitectures/kaby_lake


Der Vergleich mit dem GP108 ist wohl ein wenig :freak:
Ich meinte GP106, der Vergleich zu 108 macht natürlich keinen Sinn.

[DrumDub]

Erste Listung mit Ryzen 3 2200U:
https://geizhals.de/acer-aspire-3-a315-41-r3az-nx-gy9ev-004-a1758240.html nice. das teil gefällt mir.

[Pirx]

Ist eigentlich bei den RR-Notebooks noch ein zusätzlicher Chip(satz) ala B320 verbaut oder nur der SOC?

[dildo4u]

nice. das teil gefällt mir.
Nur ein Ram Modul ist ne ganz schlechte idee mit Ryzen.

[mboeller]

Nur ein Ram Modul ist ne ganz schlechte idee mit Ryzen.

Warum? Sind ja nur 3 CU beim 2200u. Damit kannst du sowieso nicht spielen.

https://www.amd.com/en/products/apu/amd-ryzen-3-2200u

[dildo4u]

Ryzen hängt massiv am Ram so viel das es mit einem Modul wie kaputt wirkt.

https://www.forum-3dcenter.org/vbulletin/showthread.php?t=586302&highlight=threadripper

[maguumo]

Nicht wirklich mit TR zu vergleichen,da ist das Problem doch die Inter Chip Kommunikation. Wenn man das Quad Channel Interface da mit zwei DIMMs so bestückt das jeder Die einen abbekommt sollte das kein Problem sein (abgesehen von der verschenkten Bandbreite).
Ist eigentlich bei den RR-Notebooks noch ein zusätzlicher Chip(satz) ala B320 verbaut oder nur der SOC?
Gute Frage. Hat RR die gleiche Southbridge wie Summit Ridge oder wurde das noch breiter aufgebohrt? Die kann schon 4x USB 3.0 + 4x PCIe 3.0/2xPCIe 3.0+2x S-ATA 3.

[deekey777]

Wie würde denn ein zusätzlicher Chipsatz aussehen?
Hier sind paar Bilder von Acer Swift 3: https://www.notebookcheck.com/Test-Acer-Swift-3-SF315-Ryzen-5-2500U-Vega-8-256-GB-FHD-Laptop.275900.0.html#toc-geh-use

[Loeschzwerg]

Würdest du im Falle des Swift 3 sofort erkennen, siehe das HP Willow Board (https://support.hp.com/doc-images/803/c05254641.jpg) (rechts neben dem Speicher). Scheinbar hat das Swift aber einen Platz für einen dGPU vorgesehen... gleiches Baseboard wie beim Aspire?


Was ist jetzt eine Radeon 530X? 6 CUs? Wenigstens hat das Teil GDDR5, aber so ein Schwachsinnsteil. Vielleicht mit 2xMSAA wird sie schneller sein. :ulol:


Jup und auch richtig alt, dürfte GCN2.0 basiert sein.

nice. das teil gefällt mir.

Warte mal noch auf die Alternative von Dell, Lenovo usw.. und vor allem auf Tests. Aus eigener Erfahrung sind Acer Notebooks viel zu oft einfach nur schlecht.

[Pirx]

Wie würde denn ein zusätzlicher Chipsatz aussehen?
Hier sind paar Bilder von Acer Swift 3: https://www.notebookcheck.com/Test-Acer-Swift-3-SF315-Ryzen-5-2500U-Vega-8-256-GB-FHD-Laptop.275900.0.html#toc-geh-use
laut CPU-Z Screen auf der Seite:
Chipset: Ryzen Soc
Soutbridge: Carrizo FCH (:upara: - wie bei einem A320-Mainboard oder Carrizo-Notebooks lt. Google-Bildersuche (https://www.google.de/search?q=%22Carrizo+FCH%22&tbm=isch&source=iu&ictx=1&fir=E7hzEgQMCdNsdM%253A%252CJaIeFOxq5LoyZM%252C_&usg=__IZTmbSM4rXgLS9_ecIv25AwymXA%3D&sa=X&ved=0ahUKEwjA0KqcsO7YAhUPLlAKHakqDG0Q9QEISzAD#imgrc=_))

[mczak]

Was ist jetzt eine Radeon 530X? 6 CUs? Wenigstens hat das Teil GDDR5, aber so ein Schwachsinnsteil. Vielleicht mit 2xMSAA wird sie schneller sein. :ulol:
Wo steht da was von gddr5?

[Loeschzwerg]

Steht zwar wirklich nirgends, aber das Teil mit DDR3 zu kombinieren wäre mal so richtig für'n Arsch :D

[mczak]

laut CPU-Z Screen auf der Seite:
Chipset: Ryzen Soc
Soutbridge: Carrizo FCH
Dabei handelt es sich dann wohl um den A300 oder X300 Chipsatz.
Der erste Chipless-Chipsatz der Welt :biggrin:

[mczak]

Steht zwar wirklich nirgends, aber das Teil mit DDR3 zu kombinieren wäre mal so richtig für'n Arsch :D
Da hast du natürlich recht, das heisst aber keinesfalls dass die OEMs das nicht machen könnten :mad:
Häufig ist es so, steht da nichts explizit und gibt es die gpu sowohl als ddr3 wie auch gddr5 Variante, ist es eben ddr3.

[Pirx]

Dabei handelt es sich dann wohl um den A300 oder X300 Chipsatz.
Der erste Chipless-Chipsatz der Welt :biggrin:
:D so, wie es sein soll und hoffentlich auch ist (aber man weiß ja bei Produkten mit AMD nie...)

[deekey777]

Wo steht da was von gddr5?
Hier: https://www.cyberport.de/?DEEP=1C26-AL8&APID=14

Wenn das Ding wirklich 384 SPs hat, dann könnte es wirklich mindestens auf dem Niveau der integrierten mobilen Vega 8 sein, wenn die genügend hoch takten darf.


Jup und auch richtig alt, dürfte GCN2.0 basiert sein.
AMD sagt dazu:
https://www.amd.com/de/products/graphics/radeon-530
Unterstützte Technologien
Radeon™ Software
GCN-Architektur
3rd Gen GCN Architecture
Ob das wirklich so ist? Denn die Grafikkarte soll keine 4K-Dekodierung beherrschen, was für UVD eines Bonaires spricht (und älter), https://www.x.org/wiki/RadeonFeature/#index8h2

[Loeschzwerg]

Von den ganzen Kenndaten her dürfte es ein Oland sein und damit GCN1 ^^ Das Ding wird schon seit Ewigkeiten wiederverwertet.

[BoMbY]

Es dürfte sich bei der 530 um Topaz handeln.

[Loeschzwerg]

Stimmt, den gab es ja auch noch. Hast recht, sollte passen.

[mczak]

Hier: https://www.cyberport.de/?DEEP=1C26-AL8&APID=14
Ok. Ich hoffe bloss es stimmt wirklich :-).
Bei den detaillierten Spezifikationen bei AMD, https://www.amd.com/de/products/graphics/radeon-530 steht ddr3/gddr5. Klar in der fetten Uebersicht wird dann nur gddr5 erwähnt...
Edit: kann sich natürlich auch um einen Fehler handeln. Beim 520 steht interessanterweise nichts von ddr3. Und ein 520 mit gddr5 wäre auf jeden Fall schneller als ein 530 mit ddr3, das wäre ziemlich unlogisch wobei sowas bei den ultra-low-end chips durchaus vorkommen kann.
Bei den Features steht im Uebriegen 3rd gen GCN (im Gegensatz zur 520), es müsste sich also um Iceland/Topaz handeln.
Mit gddr5 ist der nicht allzu uebel, aber wirklich sinnvoll scheint mir der auch nicht gerade in einem RR-Notebook...

[BoMbY]

Was ich mich gerade Frage: Warum baut man nicht mal Mobile-APUs mit z.B. optionalem GDDR5(X/6)-Controller, wenn schon kein HBM? Der Speicher wäre doch ehh für die aktuellen super flachen Geräte besser ehh direkt verlötet, und für die Performance wäre es sicher auch genial.

[Brillus]

Ok. Ich hoffe bloss es stimmt wirklich :-).
Bei den detaillierten Spezifikationen bei AMD, https://www.amd.com/de/products/graphics/radeon-530 steht ddr3/gddr5. Klar in der fetten Uebersicht wird dann nur gddr5 erwähnt...
Edit: kann sich natürlich auch um einen Fehler handeln. Beim 520 steht interessanterweise nichts von ddr3. Und ein 520 mit gddr5 wäre auf jeden Fall schneller als ein 530 mit ddr3, das wäre ziemlich unlogisch wobei sowas bei den ultra-low-end chips durchaus vorkommen kann.
Bei den Features steht im Uebriegen 3rd gen GCN (im Gegensatz zur 520), es müsste sich also um Iceland/Topaz handeln.
Mit gddr5 ist der nicht allzu uebel, aber wirklich sinnvoll scheint mir der auch nicht gerade in einem RR-Notebook...

Funfact, Grafikkarte ohne Anschlüsse, lustig für Desktop.

[Screemer]

Funfact, Grafikkarte ohne Anschlüsse, lustig für Desktop.
sind ja nicht für desktop

https://s31.postimg.org/xpb3rzjbv/clevo.png

sind also keine grafikkarten? ;)

[reaperrr]

Ob das wirklich so ist? Denn die Grafikkarte soll keine 4K-Dekodierung beherrschen, was für UVD eines Bonaires spricht (und älter), https://www.x.org/wiki/RadeonFeature/#index8h2
Iceland :wink:

Ist laut IP-Level der älteste GCN3-Chip, und hat noch den GCN2-Decoder.

[mczak]

Iceland :wink:

Ist laut IP-Level der älteste GCN3-Chip, und hat noch den GCN2-Decoder.
Topaz/Iceland hat weder DCE noch UVD oder VCE Block, der kann rein gar nichts dekodieren (es sei denn mit Hilfe der Shader...).
Für Videodecodierung benutzt man sowieso den Videoblock der CPU (alles andere wäre eh viel zu ineffizient).

[deekey777]

Ok. Ich hoffe bloss es stimmt wirklich :-).
Bei den detaillierten Spezifikationen bei AMD, https://www.amd.com/de/products/graphics/radeon-530 steht ddr3/gddr5. Klar in der fetten Uebersicht wird dann nur gddr5 erwähnt...
Edit: kann sich natürlich auch um einen Fehler handeln. Beim 520 steht interessanterweise nichts von ddr3. Und ein 520 mit gddr5 wäre auf jeden Fall schneller als ein 530 mit ddr3, das wäre ziemlich unlogisch wobei sowas bei den ultra-low-end chips durchaus vorkommen kann.
Bei den Features steht im Uebriegen 3rd gen GCN (im Gegensatz zur 520), es müsste sich also um Iceland/Topaz handeln.
Mit gddr5 ist der nicht allzu uebel, aber wirklich sinnvoll scheint mir der auch nicht gerade in einem RR-Notebook...

Wenn das Ding wirklich 6 CUs hat und GDDR5 mit ganzen 40 GB/s, so kann man damit einiges anstellen, nicht unbedingt das neuste, aber ein älteres Spielchen mit angepassten Einstellungen dürfte laufen. Trotzdem ist sie eine Verschwendung.

Was nicht vergessen werden darf, ist, dass sie noch in 28 nm gefertigt ist.

[deekey777]

Was ich mich gerade Frage: Warum baut man nicht mal Mobile-APUs mit z.B. optionalem GDDR5(X/6)-Controller, wenn schon kein HBM? Der Speicher wäre doch ehh für die aktuellen super flachen Geräte besser ehh direkt verlötet, und für die Performance wäre es sicher auch genial.

Weil vielleicht dies Verschwendung von Resourcen ist. Kaveri hatte Quadchannel-MC und nirgendwo wurde diese Option benutzt. GDDR5-Unterstützung wäre dann schnell zu einem Papierfeature, das toll klingt, aber nicht umgesetzt wird.

Was ich mich frage:
Wie wird eigentlich ein "Ryzen 7 2700G" aussehen? Nur ein schnellerer R5 2400G?

[Brillus]

sind ja nicht für desktop

https://s31.postimg.org/xpb3rzjbv/clevo.png

sind also keine grafikkarten? ;)
Doch auf der Übersicht wo gelinkt wurde steht desktop und mobile und bei Anschlüsse alles nein.

[Loeschzwerg]

Was ich mich frage:
Wie wird eigentlich ein "Ryzen 7 2700G" aussehen? Nur ein schnellerer R5 2400G?

Ich würde einfach mal auf eine cTDP von bis zu 95Watt tippen und damit wesentlich mehr Budget beim Takt. Hoffentlich sind die Dinger unlocked oder man kann irgendwie den max. Multiplikator festnageln (OC Board sei Dank).

[Pirx]

können sie egtl. nicht so machen, da viel zu wenige Kerne, wäre irreführend

[Loeschzwerg]

Wie? Du meinst von der Bezeichnung?

[y33H@]

Beide G-SKUs sind unlocked.

[Pirx]

Wie? Du meinst von der Bezeichnung?
jupp genau 2700<>2700G

[Loeschzwerg]

Beide G-SKUs sind unlocked.

Nice :cool:

jupp genau 2700<>2700G

Aber genau dafür gibt es doch das Suffix. Ist wesentlich übersichtlicher als was Intel so abliefert :D Vielleicht gibt es aber auch gar keinen Raven Ridge "Ryzen 7"

[Pirx]

ja, daran würde sich der kleine RR imho etwas verheben;)

[deekey777]

Ich würde einfach mal auf eine cTDP von bis zu 95Watt tippen und damit wesentlich mehr Budget beim Takt. Hoffentlich sind die Dinger unlocked oder man kann irgendwie den max. Multiplikator festnageln (OC Board sei Dank).
Das wäre doch langweilig, selbst wenn die GPU mit 2,0 GHz läuft. Vielleicht hast du Recht, dass es keinen Ryzen 7 mit der (aktuellen) RR-APU geben wird.

Auf der anderen Seite gab es neues Personal bei der RTG und recht gravierende Neuerungen in der RTG selbst:
https://www.anandtech.com/show/12363/amd-reassembles-rtg-hires-new-leadership
. Meanwhile, AMD is citing the fact that graphics is a core part of semi-custom designs as the rationale for putting it under the RTG. AMD still believes that the semi-custom business is more than just providing processors to the game console industry, but I do think that after a few years of pursuing this route, that this is the realization that game consoles are going to remain the predominant semi-custom customer. So in this respect it’s a bit of a return to status quo: game consoles are now once again part of the graphics business. And in the meantime semi-custom has certainly become a lower priority for AMD, as it’s a very regular in volume but relatively low in gross margin business for the company compared to their increasing CPU fortunes.

Irgendwie muss ich an die mysteriöse Zen-APU mit 16 CUs denken.

[Nightspider]

Mal eine blöde Frage: Kann AMD nicht die APU trotzdem noch mit GDDR Speicher koppeln?

So das die CPU Seite zum Hauptspeicher angebunden ist und die GPU in der APU auf GDDR5 oder bald GDDR6 zugreift?

So wie ich das sehe werden die APUs wieder massiv durch zu langsamen Hauptspeicher ausgebremst.

Ich frage mich eh ob es so viel teurer wäre in Konsolen gleich wie in den Konsolen 8GB GDDR5 zu verbauen als Hauptspeicher. Ich mein, wie viel teurer kann der GDDR5 sein? 30%?

[dildo4u]

AMD muss auch vom Preis her konkurrieren können,Intel ist hier im Vorteil da sie nur eine winzige GPU verbauen AMD kann es sich da nicht leisten das ganze noch komplexer zu machen.
Und Viele nutzen den IGP gar nicht,die APU ersetzt ja die Quad Cores 1400 und 1500X.Die vermutlich oft mit GTX 1050 und 1060 genutzt werden.

[ndrs]

Mischbestückung sollte ausgeschlossen sein, da alle Speichercontroller in einer Taktdomäne laufen. Eine Aufspaltung der Speicherpools entspricht auch nicht wirklich dem HSA-Gedanken. GDDR-Controller sollten deutlich mehr Die-Fläche belegen, da sie die viel höheren Taktraten abkönnen müssen. Kaveri (oder war es sein Nachfolge) sollte angeblich mit GDDR5 umgehen können, ich kann mich aber an kein Produkt damit erinnern und welchn Takt er da geschafft hätte ist auch nicht bekannt.

[deekey777]

Mal eine blöde Frage: Kann AMD nicht die APU trotzdem noch mit GDDR Speicher koppeln?

So das die CPU Seite zum Hauptspeicher angebunden ist und die GPU in der APU auf GDDR5 oder bald GDDR6 zugreift?

So wie ich das sehe werden die APUs wieder massiv durch zu langsamen Hauptspeicher ausgebremst.

Ich frage mich eh ob es so viel teurer wäre in Konsolen gleich wie in den Konsolen 8GB GDDR5 zu verbauen als Hauptspeicher. Ich mein, wie viel teurer kann der GDDR5 sein? 30%?

Eine Art Hypermemory?

Irgendwo stand, dass der Speichercontroller nur DDR3/DDR4 beherrscht, hinzu kommt, dass dies gerade nicht gewollt ist (gemeinsamer Speicher).

[Brillus]

Mal eine blöde Frage: Kann AMD nicht die APU trotzdem noch mit GDDR Speicher koppeln?

So das die CPU Seite zum Hauptspeicher angebunden ist und die GPU in der APU auf GDDR5 oder bald GDDR6 zugreift?

So wie ich das sehe werden die APUs wieder massiv durch zu langsamen Hauptspeicher ausgebremst.

Ich frage mich eh ob es so viel teurer wäre in Konsolen gleich wie in den Konsolen 8GB GDDR5 zu verbauen als Hauptspeicher. Ich mein, wie viel teurer kann der GDDR5 sein? 30%?

Sowas zu bauen ginge wohl( ware aber neuer chip da) aber verkaufen bezweifelt ich, Am4 passt gar nicht und für Laptop gäbe das richtig blödes Boarddesign. Wenn dann was mit hbm, weiß jetzt nicht wieviel Platz auf dem package ist bei AM4 evtl. könnte man das sogar hinbekommen.

[DrumDub]

Warte mal noch auf die Alternative von Dell, Lenovo usw.. und vor allem auf Tests. Aus eigener Erfahrung sind Acer Notebooks viel zu oft einfach nur schlecht. mach ich. ausserdem wär das teil eh für meine mutter. ;) deren alter acer extensa 5635z gibt langsam den geist auf. aufrüsten auf 4GB und 256 GB SSD vor einiger zeit hat noch was gebracht, aber das display hat mittlerweile nen schwarzen fleck und das auszutauschen lohnt sich dann doch nicht mehr so recht. genug OT.

[Complicated]

HBCC ist eben keine Weiterentwicklung von HSA, sondern der Versuch das HSA-Konzept auf diskrete GPUs zu übertragen. Abgesehen davon, dass du überhaupt kein Argument einbringst und nur widersprichst, sagst du dass der Versuch (nebenbei erfolgreich) HSA auf diskreten GPUs einzuführen keine Weiterentwicklung von HSA ist? Noch etwas mehr Unsinn im peto?
Das ganze auch noch von langer Hand geplant und auf Roadmaps von AMD zu sehen:

http://www.extremetech.com/wp-content/uploads/2012/02/HSA2.jpg


hUMA ist ein Marketing-Begriff und der Rest ist einfach falsch.
hUMA ist ein eigenständiger Begriff für eine erstmals von AMD entwickelte und eingeführte Technologie. Das ändert sich auch nicht wenn AMD damit berechtigterweise Marketing macht. Wo ist das Argument in deinem Satz? Und wofür bitte?

Das ist auch falsch. VEGA wird erst dank HBCC zu einer NUMA-Architektur.Und weil es dank HBCC zu NUMA wird verliert es alle anderen Eigenschaften? Zumal Nutzung von HBCC überhaupt keine NUMA (NON-Uniform-Memory-Access) sondern eine UMA-(Uniform-Access-Architecture) Nutzung ermöglicht. Das ganze auch heterogen was zu hUMA macht. Und das lustigste ist, dass AMD als einzige eine dGPU haben die sowohl im UMA, NUMA und im hUMA Modus arbeiten kann bei Bedarf - was genau das ist, was ich die ganze Zeit schreibe und als Vorsprung bei der Speicher-Technologie für AMD verbuche. Sie sind die einzigen die das derzeit bewerkstelligen.

Etwas schwach begründet und fachliche völlig daneben deine Meinung zu HSA und die von AMD jahrelang vorangetriebene Entwicklung. Du solltest dich nicht für einen Experten halten bei dem Thema, denn das bist du nicht. Das belegen Quellen wie du sehen kannst. Du solltest also nur noch mit Quellen zu diesem Thema antworten, denn aus deinem hohlen Bauch ist kaum etwas ernst zu nehmen derzeit was du zu diesem Thema äußerst.

[danarcho]

Abgesehen davon, dass du überhaupt kein Argument einbringst und nur widersprichst, sagst du dass der Versuch (nebenbei erfolgreich) HSA auf diskreten GPUs einzuführen keine Weiterentwicklung von HSA ist? Noch etwas mehr Unsinn im peto?
Das ganze auch noch von langer Hand geplant und auf Roadmaps von AMD zu sehen:
HSA ist eine Spezifikation, die eine API, Runtime und Hardware-Voraussetzungen beschreibt. Die ROCr Runtime ist meines Wissens nach die einzige, die sie erfüllt. Hardware-mäßig ist AMD mit den APUs seit Carizzo dabei und dank HBCC erfüllt wohl auch Vega die Spezifikation. (Ich glaube, das base profile wird ab Hawaii unterstützt.)

hUMA ist ein eigenständiger Begriff für eine erstmals von AMD entwickelte und eingeführte Technologie. Das ändert sich auch nicht wenn AMD damit berechtigterweise Marketing macht. Wo ist das Argument in deinem Satz? Und wofür bitte?
Normalerweise werden Fachbegriffe durch Paper eingeführt, aber von mir aus: hUMA für eine CPU-GPU-UMA Architektur (Sprich: APU).
Der letzte Punkt ist wichtig, da bei (h)UMA:
1. nur ein Hauptspeicher existiert
2. es gleiche Zugriffszeiten für alle Prozessoren (CPU+GPU) gibt


Und weil es dank HBCC zu NUMA wird verliert es alle anderen Eigenschaften? Zumal Nutzung von HBCC überhaupt keine NUMA (NON-Uniform-Memory-Access) sondern eine UMA-(Uniform-Access-Architecture) Nutzung ermöglicht. Das ganze auch heterogen was zu hUMA macht. Und das lustigste ist, dass AMD als einzige eine dGPU haben die sowohl im UMA, NUMA und im hUMA Modus arbeiten kann bei Bedarf - was genau das ist, was ich die ganze Zeit schreibe und als Vorsprung bei der Speicher-Technologie für AMD verbuche. Sie sind die einzigen die das derzeit bewerkstelligen.
Aus meinem Punkt oben sollte klar sein, dass eine diskrete GPU niemals eine (h)UMA-Architektur sein kann, da der Speicher physikalisch getrennt ist und die Zugriffszeiten sehr unterschiedlich sind.
Der Fortschritt im HBCC besteht eher darin, dass es überhaupt eine (cc-)NUMA-Architektur wird! Vorher gabs nämlich überhaupt keinen "memory access", weder uniform noch non-uniform.

Etwas schwach begründet und fachliche völlig daneben deine Meinung zu HSA und die von AMD jahrelang vorangetriebene Entwicklung. Du solltest dich nicht für einen Experten halten bei dem Thema, denn das bist du nicht. Das belegen Quellen wie du sehen kannst. Du solltest also nur noch mit Quellen zu diesem Thema antworten, denn aus deinem hohlen Bauch ist kaum etwas ernst zu nehmen derzeit was du zu diesem Thema äußerst.
Quellen:
The requirement on shared virtual memory is relaxed in the base profile to only apply to buffers allocated through the HSA runtime memory allocator. (http://www.hsafoundation.com/html_spec111/HSA_Library.htm#SysArch/Topics/02_Details/req_shared_virtual_memory.htm)
Stehst ja auf Bilder, also hier:
http://images.hardwarecanucks.com/image//skymtl/CPU/HUMA/HUMA-3.png
In the near future, CC-NUMA GPU-CPU systems will appear where software page migration is an optional choice and hardware cache-coherence can also support the GPU accessing CPU memory directly. (http://ieeexplore.ieee.org/abstract/document/7056046/)

Was die Begriffe UMA und NUMA angeht, würde ich einfach ein Vorlesungsvideo über multiprocessors bzw multicore systems empfehlen.

Bei der mittleren Zeile im Bild gehen die offenbar davon aus, dass CPU und GPU gegenseitig auf den Speicher zugreifen können, nur langsamer. Das erscheint mir nicht logisch. Ich würde sagen, dass ohne cache coherence und flat addressing die GPU (egal ob iGPU oder dGPU) gar nicht am Speichermodell der CPU teilnimmt und daher auch nicht klassifiziert werden kann.

[basix]

Wieso ist das bei NUMA so komisch? Das ist doch genau der Sinn, wenn man den erweiterten Adressbereich hat. Siehe auch NVLINK. Soweit ich verstehe wird es zu N-UMA bei unterschiedlichen Latenzen und Banbreiten. Diese Charakteristik wäre ja erfüllt. Bei Threadripper ist es ja ähnlich.

Ist nun nicht der HBCC genau das richtige dafü? Oder ist das Problem, wie die CPU auf den Speicher der GPU zugreift?

[danarcho]

Ich versteh deine Frage nicht ganz...
Prinzipiell ist der HBCC ein tolles Stück Technik und macht auch genau, was er soll. Er hat nur für APUs keine Bedeutung, und um die ging es ja hier mal ursprünglich.

[basix]

HBCC hätte eine Bedeutung für APUs, wenn die integrierte GPU einen exklusiven HBM-Stack zur Seite gestellt bekommt. Und auch, wenn man eine APU à la Radeon SSG umsetzen will.

Wieso exklusiver HBM für die GPU: Ich nehme an, die Latenzen bei HBM sind nicht optimal für CPUs da zu hoch. Dann lieber normalen DDR für die CPU und HBM für die GPU. Per HBCC kann man aber weniger HBM verbauen und macht schlussendlich das Gesamtpaket günstiger.

Falls die Latenz zum HBM allerdings gleichwertig zu DDR sein sollte, kann man sich das mit dem HBCC natürlich sparen.

[Complicated]

Normalerweise werden Fachbegriffe durch Paper eingeführt, aber von mir aus: hUMA für eine CPU-GPU-UMA Architektur (Sprich: APU).
Der letzte Punkt ist wichtig, da bei (h)UMA:
1. nur ein Hauptspeicher gemeinsam adressierbarer Speicher existiert
2. es gleiche Zugriffszeiten für alle Prozessoren (CPU+GPU) gibt
Beides sind keine Kriterien für hUMA und du hast diese selber erfunden.

Aus meinem Punkt oben sollte klar sein, dass eine diskrete GPU niemals eine (h)UMA-Architektur sein kann, da der Speicher physikalisch getrennt ist und die Zugriffszeiten sehr unterschiedlich sind.Deshalb habe ich dich gebeten für deine Behauptungen Quellen zu bemühen, da du für diese Behauptungen keine finden wirst.


Quellen:
The requirement on shared virtual memory is relaxed in the base profile to only apply to buffers allocated through the HSA runtime memory allocator. (http://www.hsafoundation.com/html_spec111/HSA_Library.htm#SysArch/Topics/02_Details/req_shared_virtual_memory.htm)
Stehst ja auf Bilder, also hier:
http://images.hardwarecanucks.com/image//skymtl/CPU/HUMA/HUMA-3.png
In the near future, CC-NUMA GPU-CPU systems will appear where software page migration is an optional choice and hardware cache-coherence can also support the GPU accessing CPU memory directly. (http://ieeexplore.ieee.org/abstract/document/7056046/)

Ich würde dich doch mal bitten wo das was du beahuptest in den von dir verlinkten Quellen zu lesen sein soll.
Edit: ccNuMA ist etwas anderes als NUMA übrigens.
Was die Begriffe UMA und NUMA angeht, würde ich einfach ein Vorlesungsvideo über multiprocessors bzw multicore systems empfehlen.Ach? Seltsam, da du derjenige bist der behauptet, dass dGPUs vor HBCC keine NUMA-Eigenschaften hatten in Multi-Prozessor-Systemen. Gegenbeweis (war nur der erste Google-Treffer)
http://impact.crhc.illinois.edu/shared/Papers/gpusm_gpgpu8.pdf
In this paper we present GPU-SM, a set of guidelines to program multi-GPU systems like NUMA shared memory systems with minimal performance overheads. Basiert auf Nvidia GPUs ganz ohne HBCC.

Ich bin nicht derjenige der auf Bildchen steht, doch offensichtlich liest du deine Quellen nicht und schon gar nicht die, welche ich zur Untermauerung meiner Argumente verlinke. Daher:

https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=62435&stc=1&d=1516888265

Ich denke das sollte so offensichtlich sein, dass du dich hier verrannt hast, dass wir das nun unterlassen können im Interesse des Threads.

[deekey777]

Ich versteh deine Frage nicht ganz...
Prinzipiell ist der HBCC ein tolles Stück Technik und macht auch genau, was er soll. Er hat nur für APUs keine Bedeutung, und um die ging es ja hier mal ursprünglich.
HBCC hätte eine Bedeutung für APUs, wenn die integrierte GPU einen exklusiven HBM-Stack zur Seite gestellt bekommt. Und auch, wenn man eine APU à la Radeon SSG umsetzen will.

Wieso exklusiver HBM für die GPU: Ich nehme an, die Latenzen bei HBM sind nicht optimal für CPUs da zu hoch. Dann lieber normalen DDR für die CPU und HBM für die GPU. Per HBCC kann man aber weniger HBM verbauen und macht schlussendlich das Gesamtpaket günstiger.

Falls die Latenz zum HBM allerdings gleichwertig zu DDR sein sollte, kann man sich das mit dem HBCC natürlich sparen.

Wie löst das Intel bei Prozessoren mit Iris-Grafik und EDRAM, dort kann die CPU den EDRAM mitnutzen, oder?

[y33H@]

Ja, als L4.

[deekey777]

Ja, als L4.
Wäre das nicht auch eine Lösung, oder ist das für das hsa intransparent?

[Gipsel]

Wieso exklusiver HBM für die GPU: Ich nehme an, die Latenzen bei HBM sind nicht optimal für CPUs da zu hoch. Dann lieber normalen DDR für die CPU und HBM für die GPU. Per HBCC kann man aber weniger HBM verbauen und macht schlussendlich das Gesamtpaket günstiger.

Falls die Latenz zum HBM allerdings gleichwertig zu DDR sein sollte, kann man sich das mit dem HBCC natürlich sparen.Das wird wohl noch hundertmal wiederholt werden müssen:
Jeglicher DRAM hat bei identischem Produktionsverfahren auch praktisch identische Latenzen. Das Interface ist dafür praktisch irrelevant.

[danarcho]

Das wird wohl noch hundertmal wiederholt werden müssen:
Jeglicher DRAM hat bei identischem Produktionsverfahren auch praktisch identische Latenzen. Das Interface ist dafür praktisch irrelevant.
Da stimme ich zu. "HBM als Cache" würde aber trotzdem eine zusätzliche Stufe einbauen und der DRAM-Zugriff würde erst nach einem Miss angestoßen werden. Da der HBM aber ziemlich groß ist, wären das aber vermutlich hauptsächlich compulsory / cold misses. Könnte sich vielleicht trotzdem lohnen, wenn man den HBM auf eine niedrigere Latenz als den DRAM drücken kann (ist ja on-package). Fänd ich als Lösung ziemlich reizend, da es niedrige Latenz mit hoher Bandbreite vereinen könnte.

So, und jetzt der nervige Teil:
Beides sind keine Kriterien für hUMA und du hast diese selber erfunden.

Deshalb habe ich dich gebeten für deine Behauptungen Quellen zu bemühen, da du für diese Behauptungen keine finden wirst.
Kannst du mir denn eine Quelle nennen, die hUMA im Zusammenhang mit dGPUs erwähnt? Alles, was ich finde sagt, dass hUMA die Bezeichnung ist für APUs mit cache coherent uniform memory access für CPU+GPU. Und UMA hat halt die Kriterien, die ich aufgeschrieben habe.
Ich würde dich doch mal bitten wo das was du beahuptest in den von dir verlinkten Quellen zu lesen sein soll.
Edit: ccNuMA ist etwas anderes als NUMA übrigens.
cc steht für cache-coherent. Habs halt etwas präzisiert.
Hab doch die Sätze rauskopiert? Das Paper war auch nur als Hinweis, dass man 2015 schon dGPUs mit cc-NUMA erwartet hat.
Ach? Seltsam, da du derjenige bist der behauptet, dass dGPUs vor HBCC keine NUMA-Eigenschaften hatten in Multi-Prozessor-Systemen. Gegenbeweis (war nur der erste Google-Treffer)
http://impact.crhc.illinois.edu/shared/Papers/gpusm_gpgpu8.pdf
Basiert auf Nvidia GPUs ganz ohne HBCC.
So, dann zitieren wir mal aus dem Paper:
We propose changing the perspective of how a multi-GPU
system is programmed by looking at the GPUs and their
memories as if they were a shared memory NUMA system
(Figure 10b), which we call GPU-SM.
Das Paper sagt halt nirgends, dass es sich um eine NUMA-Architektur handelt, sondern, dass sie sie so programmieren als ob.
Ich gebe aber zu, dass die Übergänge etwas fließend sind und offenbar schon ältere GPUs einen unified address space haben, wenn auch nicht cache coherent und ohne page migrations.
Ich denke das sollte so offensichtlich sein, dass du dich hier verrannt hast, dass wir das nun unterlassen können im Interesse des Threads.
denied :ass2:

[basix]

Das wird wohl noch hundertmal wiederholt werden müssen:
Jeglicher DRAM hat bei identischem Produktionsverfahren auch praktisch identische Latenzen. Das Interface ist dafür praktisch irrelevant.

Bei HBM-Latenz meine ich DRAM + Speichercontroller. Und das letztere ist nunmal anders als bei DDR4. Schlussendlich zählt die Gesamtlatenz, bis man die Daten bei den ALUs / AGUs hat. Siehe zum Beispiel Quad vs. Dual Channel. Durchgehend höhere Latenz bei Quad. Einfach weil der Controller ein anderer ist. DRAM an sich bringt man bei beiden Controllern auf 8-10ns.

Ist es zudem nicht so, dass für maximalen Throughput (also Bandbreite) oft Latenz geopfert wird? Da HBM vor allem bandbreitenorientiert ist, habe ich eben die Annahme, dass die Latenz höher ist. Und dies vor allem durch den Speichercontroller und nicht den DRAM an sich. Muss nicht stimmen und ich würde mich gerne vom Gegenteil überzeugen lassen, da dann die Lösung einfacher ausfällt und zudem die CPU von der zusätzlichen Bandbreite profitieren könnte.

[Locuza]

Und welche Software Anpassungen sind nun nötig für den HBCC? Keine.
Hat Intel eine vergleichbare Lösung beim Speichermanagement? Keine
Was ist hier falsch dargestellt?
HSA und SVM sind gleichwertig und HBCC ist die auf HSA basierende Weiterentwicklung beim heterogenen Speichermanagement, welche Intel dringend benötigt für das Serverumfeld. Da ist Intel weit zurück.

@danarcho
Das mag daran liegen, dass du am Thema vorbei erklärst. APUs sind weder UMA noch NUMA Architekturen. Es sind hUMA Architekturen. Ein heterogenes Umfeld ist etwas anderes als wenn 4 CPU-Dies die Speicherzugriffe optimieren sollen wie es z.B. in Epyc passiert. Vor allem wenn man bei AMD in der Lage ist zwischen UMA und NUMA hin und her zu switchen je nach Bedarf in den modernen MCM-Produkten. (Threadripper und EPYC)

Diskrete GPUs der Vega Serie sind keine ausschließlichen NUMA-Devices mehr dank Infinity Fabric, welche CCIX und Genz Technik nutzen.

http://i.imgur.com/aYDcW0N.jpg

https://www.ccixconsortium.com/single-post/2017/06/28/Welcome-to-the-new-CCIX-Blog
Der Ursprungskontext fing eig. damit an, ob bei RR der L3$ von der GPU mitbenutzt werden kann, worauf du einen Beitrag geschrieben hast, der aber auch alles pro AMD ausgelegt hat, sei es Cache-Strategie, Kohärenz-Methode oder das Fabric.
Dabei soll das heterogene Design bei/ab Kaveri angeblich dem vom Intel weit voraus sein.

Ich habe mich hauptsächlich auf das APU-Design bezogen, aber es wurden dann noch zusätzlich HBCC und CCIX/Gen-Z als Stichwörter eingeworfen und das ganze driftet weiter ab, wo die anderen Punkte ebenfalls noch einmal krude interpretiert und ausgelegt werden.

Externe Beschleuniger mal ausgeklammert, war bezüglich der Systemintegration AMD der Konkurrenz insgesamt gar nicht weit voraus.

Früher wie Heute gab es dGPUs und im Chipsatz integrierte GPUs.
Mit der Übernahme von ATI hat AMD die entsprechende GPU-IP und einen Spezialisten übernommen.
Ein Ziel von der Übernahme war das Fusion-Konzept, welches schon 2006 vorgestellt wurde:
https://www.heise.de/newsticker/meldung/AMD-entwickelt-integrierten-CPU-GPU-Chip-118827.html

Es hat dann aber bis Januar 2011 gedauert, bis AMD mit Zacate/Ontario (2 Bobcat-Kerne + VLIW5 GPU) eine entsprechende APU auf den Markt gebracht hat.
Grob ein halbes Jahr später Ende Juni 2011 erschien mit Llano eine stärkere APU mit 4 Star-Kernen und stärkerer VLIW5 GPU.
Die Integration ist simpel, es gibt einen gemeinsamen Systemspeicher mit getrennten Adressräumen für CPU und GPU und einen zusätzlichen 128-Bit Bus für unterschiedliche Datenzugriffe zwischen CPU und GPU, insgesamt aber langsam und mit geringem Durchsatz (Seite 13).
https://developer.amd.com/wordpress/media/2013/06/1004_final.pdf

Die Verwaltung von der Arbeitslast und Stromzufuhr fällt ebenso simpel aus.
Es gibt einen grob granulären Turbo für die CPU-Kerne, welche auch höher Takten können, falls die GPU sich im idle-modus befindet, aber andersherum hat funktioniert das nicht:
https://www.anandtech.com/show/4444/amd-llano-notebook-review-a-series-fusion-apu-a8-3500m/4

Trinity erschien zuerst im Mai 2012 für mobile Plattformen und erst im Oktober für Desktop-Systeme.
AMD hat viele Stellen evolutionär verbessert.
Neben dem Upgrade von CPU, GPU und dem Media-Block wurde bezüglich der Systemintegration der FLC auf 256-Bit aufgepumpt, der effektive Datenzugriff auf die unterschiedlichen Adressräume sicherlich verbessert.
Das Power-Management arbeitet feiner und nun bidirektional, CPU und GPU takten unterschiedlich je nach anliegender Last und beeinflussen sich gegenseitig.

Nach Trinity gab es Richland als Refresh im Juni 2013, immerhin mit mehr Power-States für die GPU.
Aufregender war Kabini im gleichem Zeitraum mit Jaguar-Kernen und GCN Gen 2 GPU.
Die Southbridge wurde nun integriert, ansonsten fiel die Systemintegration scheinbar gleich aus.
Später gab es mit Beema ein Refresh.

Kaveri debütierte Mitte Januar 2014 mit vielen Milestones, welche seit mehreren Jahren als Ziel festgelegt worden sind.
Einen gemeinsamen virtuellen Adressraum für CPU und GPU und mögliche Cache-Kohärenz wird durch einen zusätzlichen 256-Bit Bus (FLC+) ermöglicht.
Ansonsten hat AMD rundum die Komponenten erneuert und verfeinert, neue CPU-Kerne, GPU, Media und feineres Power-Management.

Carrizo erfolgte im Juni 2015, aber praktisch ein Jahr exklusiv für mobile Plattformen.
AMD hat sich offenbar unterschiedlicher Buse entledigt und die Cache-Koharänz wird immer mit voller DRAM-Bandbreite sichergestellt:
https://www.notebookcheck.com/fileadmin/_processed_/csm_carrizo_hsa_features_d6eff11ebd.jpg

Compute-Preemption wurde auf einem Niveau implementiert, welches nun die HSA 1.0 spec glücklich macht.
Ein Gutes hat die Delta-Color-Compression, um die effektive Bandbreite zu erhöhen.
Und AMD hat nun für die größeren APUs auch Teile von der Southbridge integriert.

Später gab es Bristol-Ridge für OEMs als Refresh im Jahr 2016 und noch einmal ein halbes Jahr später Mitte 2017 für den Einzelhandel.

Ende 2017 ist praktisch Raven-Ridge für Mobile gelaunched und wir wissen das die Systemintegration bezüglich des Power-Managements weiter verfeinert wurde.
Der IF besitzt wahrscheinlich bessere Latenzen und Features, als der Fabric bei Carrizo.
Zum ersten mal besitzt die CPU-Seite einen 4MB großen L3$, welcher die Bandbreitenanforderungen und den Streit um den DRAM-Zugang entschärft.
Die GPU hat relativ einen größeren L2$ mit 1MB gegenüber den 512KB bei Kaveri/Carrizo und zusätzlich hilft der DSBR und das L2$ kohärente Pixel-Backend die Bandbreitenanforderungen zu senken.
Die GPU unterstützt nun auch vier unterschiedliche Page-Levels, was bei Virtual-Memory helfen sollte.

--------------------------

Und jetzt mal die Entwicklung bei Intel im Vergleich.
Neben ebenfalls integrierten GPUs im Chipsatz und paar Sonderlösungen, fange ich bei Westmere an.
Als Dual-Core Ausführung gab es zusätzlich eine 45nm GPU auf dem Package im Januar 2010.

Ein rundes Jahr danach, Anfang 2011, erschien Sandy-Bridge mit Gen6-Architektur auf einem die.
Damit war Intel zeitlich bei der physischen Integration nicht später dran als AMD.
Der Ring-Interconnect und der inklusive LLC ist dabei ein grundlegendes Design, welches Intel bis Heute als Vorteil verbuchen kann, auf Seiten der CPU-Kerne und der heterogenen Integration.
Der Ring läuft @ CPU-Core-Clock und bietet entsprechend eine hohe Bandbreite, geringe Latenzen und einfaches Data-Sharing an, deutlich ausgefallener, als AMDs simpler Design-Ansatz bei den ersten APU-Generationen.
Bei RealWorldTech kann man sich entsprechende Artikel durchlesen, ein Auszug:
The Sandy Bridge CPU cores can access data and synchronize with the GPU’s portion of the L3 cache. For example, the CPU can write graphics commands into the GPU’s L3 cache, which the GPU then reads. The GPU can also explicitly flush data back to the L3 cache for the CPU to access with very high performance (e.g. for offloading from the GPU to CPU). Passing data between the GPU and CPU through the cache (instead of memory) is one area where Intel’s GPU integration is substantially ahead of AMD. In many respects, the communication model is much more bi-directional rather than the traditional one-way flow in a graphics pipeline.
https://www.realworldtech.com/fusion-llano/3/

Das Energiemanagement war auch schon ab Sandy-Bridge bidirektional.

Ein paar Designeinschränkungen bezüglich der Leistung und Effizienz gibt es allerdings aufgrund der Tatsache, dass der LLC zusammen mit der CPU an einer Clock-Domain hängt.
Ändert die CPU ihren Takt und senkt den Power-State herab, sinkt auch der LLC-Durchsatz und damit werden GPU-Anfragen an den Ring negativ beeinflusst.
Die GPU stellt dabei allgemein ein schwaches Glied dar, wenig programmierbar, ohne DX11 oder OpenCL-Support, dass bot immerhin schon Llano an.

Interessant ist die Integration von der Media-Engine, welche sehr verzahnt mit der GPU ausfällt.

Ivy-Bridge erschien im April 2012, ein paar Feinheiten wurden geboten.
Ein L3$ für die GPU wurde implementiert, DX11.0 und OpenCL1.1 werden nun unterstützt.

Im Juni 2013 erschien Haswell für Desktop-Systeme und Intel hat mehrere Dinge stärker angepackt.
Zum einem für mobile Plattformen gab es die Southbridge auf einem gemeinsamen Package, zum anderem hat Intel nun die GPUs in drei Stufen gegliedert und deutlich die Rohleistung am oberen Ende erhöht.
Die Integration und Zusammenarbeit der Prozessoren wurde verbessert:
First, Haswell’s Last Level Cache (LLC) has been enhanced for performance. Each slice of the LLC contains two tag arrays, one for data accesses and one for prefetching and coherency requests. The data bandwidth is still 32B/cycle, since the ring bus has not widened. The memory controller also has a larger re-ordering window, yielding better throughput for write data.

Second, the ring and LLC are on a separate frequency domain from the CPU cores. This enables the ring and LLC to run at high performance for the GPU, while keeping the CPUs in a low power state. This was not possible with Sandy Bridge, since the cores, ring and LLC shared a PLL, and wasted power on some graphics heavy workloads.

Virtualization has improved for Haswell, with a particular emphasis on eliminating VM exits. The extended page tables incorporate accessed and dirty bits, which reduce VM transitions and the new VMFUNC instruction enables VMs to use hypervisor functions without an exit. The round-trip latency for VM transitions is now below 500 cycles, and the I/O virtualization page tables are a full 4-level structure.
https://www.realworldtech.com/haswell-cpu/6/

Eine weitere Neuheit ist die Integration von einem eDRAM-Speicher als L4$ für CPU und GPU, damit hat Intel es dann auch geschafft AMD bei der GPU-Leistung zu schlagen.

Broadwell erschien dank 14nm Probleme deutlich später, es folgte 2014 ein Haswell Refresh und der Launch von Broadwell-Y Ende 2014, bis erst 2015 Broadwell-U/H für die restlichen Segmente erschien.
Mit Broadwell für den Desktop gab es zwei interessante Modelle erstmals und zuletzt mit eDRAM für den Sockel.
Damit hat Intel erneut geschafft, AMD bei der GPU-Leistung zu schlagen.
https://www.computerbase.de/2015-06/intel-core-i7-5775c-test/2/

Zeitlich war man ungefähr ein Jahr später dran, aber man hat dann auch einen gemeinsamen Adressraum umgesetzt, Cache-Kohärenz und erfüllt Shared Virtual Memory von der OpenCL2.0 mit fine-grained buffers mit/ohne atomics.
Genauso wie AMD seit Kaveri.

Wenig später erschien Skylake im August 2015 für den Desktop.
Den eDRAM hat Intel als Side-Cache umgestaltet, nun vier unterschiedliche Ausbaustufen bei der GPU, mit über 1TF-Rohleistung für GT4.
Eine Delta-Color-Compression wurde umgesetzt, neben der Tatsache das man als erster praktisch die ganze DX12-Spec umgesetzt hat.
Leider sind scheinbar seitdem Punkt einige Dinge chaotisch abgelaufen.
Die CPU-Architektur begleitet uns bis zum heutigen Coffee-Lake, Gen9 ebenso und Cannon Lake kommt vielleicht gar nicht mit Gen10 auf den Markt?
Intels Ambitionen was Gaming und GT3/4-Lösungen anging wurden schnell sehr halbherzig und wahrscheinlich auch gecancelt.

Aber Intel hat bis Skylake ein gutes Tempo hingelegt, was die Weiterentwicklung ihrer GPU-IP anging und der Systemintegration, entgegen dem jahrelangen HSA-Mantra für AMD und der angeblich unerreichbaren GPU-Performance, hat Intel mehrere Designvorteile für sich verbuchen können, war zeitlich früher, gleich oder etwas später dran und hat auch bei der absoluten Leistung mehrmals die Krone gehabt.
"Weit voraus" gilt indem Fall überhaupt nicht allgemein und nur isoliert betrachtet.

Wenn Intel wieder bei der Entwicklung anpackt, kommt ohne Frage starke Konkurrenz.
AMD hat jetzt schon arge Schwierigkeiten mit Nvidia und muss deutlich aufholen und Intel will ihre GPU-Pläne wieder stärker umsetzen, heißt AMD muss auch bei den APUs Vollgas geben, wenn sie nicht in 2 Jahren wieder den Kuchen verlieren wollen, welchen Raven-Ridge gerade erschließen kann.

---------------------------------------------

HBCC und dedizierte Beschleuniger sind ein extra Thema.
Intel liegt hier auf den Markt bezogen vermutlich ein paar Jahre im Verzug, nachdem sie den Nachfolger von Knights Landing begraben haben und die Zeit überbrücken müssen.
Aber prinzipiell wird es für Intel keine Hürde darstellen ähnliche Funktionalität in naher Zukunft anzubieten.
Sie haben alle nötigen IPs und viel Know-How.

Der IF hat mit hUMA bei dGPUs aktuell nichts zu tun (späterer Beitrag von dir) und wieso CCIX und Gen-Z erwähnt werden, mitsamt Durchsatzangaben vom CCIX-Standard ergibt für mich wenig Sinn.
Für hUMAs Stichwörter braucht es laut AMD Cache-Koharänz und über PCIe lässt sich das nicht realisieren.
xGMI erscheint erst mit Vega20 Ende 2018/Anfang 2019, um entsprechende Features umsetzen zu können.
CCIX und Gen-Z werden von AMD nicht direkt verwendet, IF ist ein proprietärer Standard von AMD und stellt eine starke Weiterentwicklung von ihren damaligen HyperTransport-Entwicklungen dar.
Das Konzepte und Ideen sich bei vielen Standards überschneiden ist sicherlich keine Überraschung und das AMD im CCIX, Gen-Z oder Rapid-IO-Konsortium sitzt hat bis Heute keine direkte Marktrelevanz, da AMD keine entsprechend ausgestattete Produkte und Möglichkeiten anbietet.

[fondness]

Eine weitere Neuheit ist die Integration von einem eDRAM-Speicher als L4$ für CPU und GPU, damit hat Intel es dann auch geschafft AMD bei der GPU-Leistung zu schlagen.

Broadwell erschien dank 14nm Probleme deutlich später, es folgte 2014 ein Haswell Refresh und der Launch von Broadwell-Y Ende 2014, bis erst 2015 Broadwell-U/H für die restlichen Segmente erschien.
Mit Broadwell für den Desktop gab es zwei interessante Modelle erstmals und zuletzt mit eDRAM für den Sockel.
Damit hat Intel erneut geschafft, AMD bei der GPU-Leistung zu schlagen.
https://www.computerbase.de/2015-06/intel-core-i7-5775c-test/2/


Schöne Zusammenfassung. Hier kann man aber schon noch erwähnen, dass Intel dafür günstige Umstände und die Brechstange benötigt hat. Nicht nur, dass das eDRAM-Die nicht gerade klein war sprechen wir hier von 14nm FinFET vs. 28nm bulk Fertigungsprozess und einem an der Bandbreite verhungernden 7870K. Rein von der Architektur war Intel stets meilenweit abgeschlagen. Mittlerweile schafft es AMD mit RR auch das zu schlagen und zwar mit einem 200mm² Die und einem simplen DDR4-Interface. Ganz davon abgesehen, dass man sogar bei der CPU Perf/Watt offenbar auf Augenhöhe agiert (was die eigentliche Sensation ist).


Aber Intel hat bis Skylake ein gutes Tempo hingelegt, [...]

Das stimmt, aber dafür kommt seit 2015 gar nichts mehr. Und zwar sowohl CPU- als auch GPU-seitig.

[Locuza]

Man kann das natürlich betonen, es ändert aber am Ende nichts an den Tatsachen.
Und dank der Dynamik gibt es auf beiden Seiten keine feste Regel.

AMD hat nach einer halben Dekade eine konkurrenzfähige CPU-IP und der Fertigungsnachteil ist massiv geschrumpft.
Bei Intel dagegen hat man nicht mehr eine GPU-IP, welche vom Feature-Set eine oder gar mehrere Generationen hinterherhinkt, sondern teilweise sogar führend war.
Sie haben auch die Skalierung der Rechenleistung immer weiter verfeinert und werden in Zukunft noch einmal massiv drauflegen.
Intel hat noch viele Möglichkeiten die Effizienz ihrer GPU-IP zu verbessern, welche AMD teilweise auch hat, aber dank geringem R&D-Budget ist bei AMD seit GCN leider auch relativ wenig passiert.

Und letztendlich zählen nur effektive Vorteile und keine auf dem Papier bzw. welche den Markt für das entsprechende Zeitfenster nicht tangieren.
Gerade AMD hat seit vielen Jahren das grundlegende Problem, wenn sie Vorteile haben, diese auch effektiv auszunutzen.

Für mich persönlich ist Raven-Ridge nach über 10 Jahren Fusion- bzw. über 5 Jahren HSA-"Gelaber" mal endlich das, was man sich von Anfang an versprochen hat.
Ein attraktives Gesamtpaket, welches der Konkurrenz den Schneid abläuft.
Aber zeitlich hatte man sich das sicher deutlich früher vorgestellt und auch mit Raven-Ridge ist man leider nicht so überaus deutlich in der Führung, dass die Konkurrenz nicht nachziehen könnte.

[fondness]

Für mich persönlich ist Raven-Ridge nach über 10 Jahren Fusion- bzw. über 5 Jahren HSA-"Gelaber" mal endlich das, was man sich von Anfang an versprochen hat.
Ein attraktives Gesamtpaket, welches der Konkurrenz den Schneid abläuft.
Aber zeitlich hatte man sich das sicher deutlich früher vorgestellt und auch mit Raven-Ridge ist man leider nicht so überaus deutlich in der Führung, dass die Konkurrenz nicht nachziehen könnte.

Na wenn das schon ein Problem ist, dass man nicht so weit vorne ist, dass die Konkurrenz nicht nachziehen kann. Wir reden hier immer noch von AMD, ein Zwerg im Vergleich zu Intel. Dass man hier einen SoC raus haut, der Intel in praktisch jeder Hinsicht überlegen ist (Performance, Perf/Watt, Perf/mm², Chipsatz on Die, etc.) und das in einen noch immer sicher unterlegenen Fertigungsprozess ist doch viel mehr als man angesichts der Ausgangslage erwarten könnte.

[robbitop]

Sehe ich auch so. Intel hat 2-3 Größenordnungen mehr Ressourcen. Was AMD mit Summit Ridge und RR abgeliefert hat ist vor diesem Hintergrund einfach erstaunlich.

[dargo]

Na wenn das schon ein Problem ist, dass man nicht so weit vorne ist, dass die Konkurrenz nicht nachziehen kann. Wir reden hier immer noch von AMD, ein Zwerg im Vergleich zu Intel. Dass man hier einen SoC raus haut, der Intel in praktisch jeder Hinsicht überlegen ist (Performance, Perf/Watt, Perf/mm², Chipsatz on Die, etc.) und das in einen noch immer sicher unterlegenen Fertigungsprozess ist doch viel mehr als man angesichts der Ausgangslage erwarten könnte.
Absolut!

Würde AMD in Geld schwimmen wie Intel bin ich mir ziemlich sicher wir hätten sowas viel früher gesehen.

http://static2.businessinsider.com/image/5a5394cac32ae6291a8b4cf9/the-new-chips-made-by-the-intel-and-amd-partnership-bring-us-one-step-closer-to-ultra-thin-laptops-that-can-do-everything.jpg

Und zwar zur Fiji Zeit, dann natürlich mit einem CPU-Part von AMD. Man wäre zwar auf nur 1GB beschränkt. Sofern 2 Stacks realisierbar wären dann eben auf 2GB. Aber ohne die finanziellen Mittel lässt sich sowas eben nicht realisieren. Jetzt teilt man sich eben das "Risiko" mit Intel. Was eh schon eine Sensation für sich ist, damit hatte ja keiner im Leben gerechnet.

[Locuza]

Das wird wohl noch hundertmal wiederholt werden müssen:
Jeglicher DRAM hat bei identischem Produktionsverfahren auch praktisch identische Latenzen. Das Interface ist dafür praktisch irrelevant.
Wie ist eig. die Daten-Granularität in diesem Aspekt zu bewerten?
Bei DDR4 wollte man 32 Bytes vermeiden, sodass bei einer 16-Bit Anbindung maximal 16 Bytes verwendet werden.
Ansonsten sind es 4/8-Bytes?
Bei GDDR5 sind es 32 Bytes und GDDR6 und HBM2 haben extra darauf geachtet das man bei 32-Bytes bleibt, jeweils mit dem Dual-Channel Konzept bei GDDR6 und Pseudo-Channels bei HBM2.


@ fondness

Ausgangslage ist wohl ein gutes Stichwort, welche bei AMD sehr zweischneidig ausgefallen ist.
Man hat immens viel Potential mit dem Aufkauf von ATI gehabt, aber das ganze mit einem Schuldenberg und schlechtem Management praktisch parallel abgewürgt.

[fondness]

@ fondness

Ausgangslage ist wohl ein gutes Stichwort, welche bei AMD sehr zweischneidig ausgefallen ist.
Man hat immens viel Potential mit dem Aufkauf von ATI gehabt, aber das ganze mit einem Schuldenberg und schlechtem Management praktisch parallel abgewürgt.

Ich kann die Aussage vom schlechten Management bei AMD ehrlich gesagt nicht mehr hören. Ich glaube sogar, dass AMD mittlerweile ein sehr gutes Management hat. Ja, man hat mit Bulldozer einmal daneben gegriffen, aber das hat auch Intel nicht besser gemacht mit Netburst. Der Aufkauf von ATI war richtig, aber der Zeitpunkt unglücklich. Zum einen war der Preis für AMDs finanzielle Ressourcen eigentlich grenzwertig, zum anderen kamen erschwerende Umstände hinzu wie R600 (wofür AMD sicher nichts konnte) und die Monopolverletzungen von Intel. Das man eine Mitarbeitermäßig fast gleich große Firma nicht so leicht integrieren kann sollte zudem klar sein und sicher gab es da Anfangsschwierigkeiten. Nichtsdestoweniger hat man in den letzten Jahren auch sehr viele richtige Entscheidungen getroffen und steht heute trotz finanzieller Probleme in den vergangenen Jahren als schlankes Unternehmen mit viel Potential da. Man hat die Fabs zu einem Zeitpunkt verkauft, als man dafür noch Geld bekam (IBM musste ihre fast schon verschenken), man hat sich das unnötige Geldverbrennen im mobile-Markt erspart (siehe Intel und nvidia), und man hat die im Vergleich zur Konkurrenz stark begrenzten Ressourcen offensichtlich richtig eingesetzt (siehe Zen). Es gab in der Vergangenheit sicher viele berechtigte Kritikpunkte, man hat allerdings darauf reagiert und mittlerweile vieles besser gemacht; Stichwort zB Software, AMD liefert heute den besten Linux Treiber wenn man sich in der Linux Community mal ein bisschen umhört.

[Loeschzwerg]

Ich glaube sogar, dass AMD mittlerweile ein sehr gutes Management hat.

Es hat sich gebessert, aber gut ist was anderes. Nach Summit Ridge hätte der Fokus viel stärker auf Raven Ridge liegen müssen. Der Notebook-Markt ist fürchterlich und die Versorgung mit offiziellen Treibern einfach schlecht.

[fondness]

Es hat sich gebessert, aber gut ist was anderes. Nach Summit Ridge hätte der Fokus viel stärker auf Raven Ridge liegen müssen. Der Notebook-Markt ist fürchterlich und die Versorgung mit offiziellen Treibern einfach schlecht.

Vega-IP ist erst ein halbes Jahr alt. Man hat RR sobald wie nur irgend möglich gebracht. Ein aktuellerer Treiber wird bald kommen. Wie kommst du darauf, dass der Fokus nicht voll auf RR lag? Der Notebookmarkt ist kein Endkundenmarkt für AMD.

[Loeschzwerg]

Schon mal versucht überhaupt einen RR Treiber über die AMD Homepage zu bekommen? Inexistent. Probleme die man mit Carrizo/Bristol Ridge hätte einfachst einstellen können.

Die Vega-IP hat das Unternehmen btw. schon eine ganze Zeit fertig, aber ja, hier werden vermutlich die Ressourcen knapp gewesen sein.

Wie kommst du darauf, dass der Fokus nicht voll auf RR lag? Der Notebookmarkt ist kein Endkundenmarkt für AMD.

Ja wo sind denn die ganzen Notebooks der OEMs? Das dauert viel zu lange und dann kommen Geräte mit ordentlichen Schwächen. Hat das Sampling für die OEMs hier zu lange gedauert? Mangelt es an der Firmware? Keine Kapazität für die Anfertigung der Kapazität?

Auf der CES wurde irgendwie auch herzlich wenig gezeigt. Ich hoffe die Situation bessert sich.

[fondness]

Schon mal versucht überhaupt einen RR Treiber über die AMD Homepage zu bekommen? Inexistent. Probleme die man mit Carrizo/Bristol Ridge hätte einfachst einstellen können.

Der Treiber liegt den Geräten bei bzw. können direkt vom Hersteller bezogen werden. Wer unbedingt einen aktuelleren benötigt kann auch einfach die .inf modifizieren. Kunden die einen solchen Notebook-SoC kaufen, sind in der Regel nicht auf den aktuellsten Treiber angewiesen. Der Notebookmarkt ist kein Endkundenmarkt für AMD. Aber es wird mit dem RR-Start im Februar auch aktuellere Treiber geben.


Die Vega-IP hat das Unternehmen btw. schon eine ganze Zeit fertig, aber ja, hier werden vermutlich die Ressourcen knapp gewesen sein.

Es hat Zeiten gegeben, da hat es >1 Jahr gedauert, bis neue Grafik IP den Weg in einen SoC fand, 5 Monate ist Rekord. Viel schneller ist einfach unrealistisch. Man hat in der Vergangenheit auch viel daran gearbeitet, um diese Zeitspanne zu verkleinern.


Ja wo sind denn die ganzen Notebooks der OEMs? Das dauert viel zu lange und dann kommen Geräte mit ordentlichen Schwächen. Hat das Sampling für die OEMs hier zu lange gedauert? Mangelt es an der Firmware? Keine Kapazität für die Anfertigung der Kapazität?

Auf der CES wurde irgendwie auch herzlich wenig gezeigt. Ich hoffe die Situation bessert sich.

Du glaubst also ein gutes Produkt reicht aus, dass sich die OEMs plötzlich in Massen auf AMD stürzen? Lieb. :)
Im Notebookmarkt zählt der Brand viel mehr, die meisten Kunden wollen aus Prinzip Intel, da kannst du ihnen noch so oft erklären, dass das AMD-Gerät das bessere für die wäre. Ich finde es auch seltsam, dass du automatisch annimmst, dass es AMDs Schuld ist, wenn die Notebookhersteller nicht mehr bzw. keine besseren Geräte mit RR bringen. Das ist doch schon seit einer halben Ewigkeit das Problem von AMD. Deshalb ist man angewiesen auf den gut informierten Endkundenmarkt, wo wirklich noch die Produktqualität zählt.

[YfOrU]

Neue APUs dürften auch in Zukunft immer um 10 - 12 Monate nach den CPUs auf den Markt kommen. Also Tape Out nachdem CPU und GPU IP/Designs getrennt validiert wurden. Der Ansatz ist am effizientesten und das Risiko am geringsten.


Ja wo sind denn die ganzen Notebooks der OEMs? Das dauert viel zu lange und dann kommen Geräte mit ordentlichen Schwächen. Hat das Sampling für die OEMs hier zu lange gedauert? Mangelt es an der Firmware? Keine Kapazität für die Anfertigung der Kapazität?

Siehe Epyc. Sehr frühe offizielle Vorstellung mit kaum bis keinen fertigen Produkten (die Plattform war es auch nicht). RR wurde dazu exklusiv eingeführt. Halbwegs komplett am Markt ist das Portfolio sowieso erst wenn die Pro APUs (sowie R3) verfügbar sind. AMD hat Kosmetik betrieben und damit die Roadmap erfüllt. In der Realität liegt man auf jeden Fall ein Quartal dahinter. Bei Epyc eher zwei.

[fondness]

Sehr frühe offizielle Vorstellung mit kaum bis keinen fertigen Produkten (die Plattform war es auch nicht).

Ähm, es gab wenig später lieferbare Notebooks.

[YfOrU]

Wenn es exklusiv von drei großen OEMs jeweils ein Gerät zur Einführung gibt (welches ansonsten auch noch 1 zu 1 dem Produkt mit Intel CPU entspricht) ist das eigentlich selbstredend. Da hat man sicher nachgeholfen. Spricht im Regelfall für geringe Verfügbarkeit, keine fertige Dokumentation (Integration) und zu wenig Ressourcen um mehr OEMs zum Start einzubeziehen. Also der typische Launch mit der Brechstange. Wäre es anders hätte man zumindest auf der CES ein paar zusätzliche Notebooks oder wenigstens Ankündigungen vorzeigen können. Da war aber nichts und daher auf der Zeitachse eher Richtung Q2 wie auch der Rest vom Ryzen Mobile Portfolio. Genaugenommen hat AMD das auch so kommuniziert. Ramping in Q1/2018. Transcript Q3/17: http://quarterlyearnings.amd.com/phoenix.zhtml?c=74093&p=quarterlyearnings

[Loeschzwerg]

Der Treiber liegt den Geräten bei bzw. können direkt vom Hersteller bezogen werden. Wer unbedingt einen aktuelleren benötigt kann auch einfach die .inf modifizieren. Kunden die einen solchen Notebook-SoC kaufen, sind in der Regel nicht auf den aktuellsten Treiber angewiesen. Der Notebookmarkt ist kein Endkundenmarkt für AMD. Aber es wird mit dem RR-Start im Februar auch aktuellere Treiber geben.

Prinzipiell ja (im Hinblick auf Office, Multimedia...), aber nicht wenn man für sich den Titel einer "Gaming on the Go"-APU beansprucht ;)

INF Modding kannst du nicht verlangen.


Du glaubst also ein gutes Produkt reicht aus, dass sich die OEMs plötzlich in Massen auf AMD stürzen? Lieb. :)
Im Notebookmarkt zählt der Brand viel mehr, die meisten Kunden wollen aus Prinzip Intel, da kannst du ihnen noch so oft erklären, dass das AMD-Gerät das bessere für die wäre. Ich finde es auch seltsam, dass du automatisch annimmst, dass es AMDs Schuld ist, wenn die Notebookhersteller nicht mehr bzw. keine besseren Geräte mit RR bringen. Das ist doch schon seit einer halben Ewigkeit das Problem von AMD. Deshalb ist man angewiesen auf den gut informierten Endkundenmarkt, wo wirklich noch die Produktqualität zählt.

Nach Carrizo/Bristol Ridge hätte ich erwartet dass die ganze Sache schneller ins Rollen kommt. Wirklich optimal schein der Draht zu den OEMs da irgendwie nicht zu sein.

Und wenn du aus dem Dilemma "AMD sind die Billigheimer" raus willst, dann musst du zusammen mit einem OEM ein entsprechendes Objekt liefern. Hier sehe ich aktuell keines und angekündigt ist ebenfalls noch nichts. Mich würde da schon interessieren wie es da hinter den Kulissen abläuft.

----

Gibt es eigentlich schon irgendwo ein Datenblatt zum Lenovo 720S-13ARR?

[fondness]

Weil vorhin die Frage nach weiteren Notebooks aufkam, ein paar Anmerkungen von Hallock bei PCGH:

Robert Hallock: Im ersten Quartal dieses Jahres sind auch Asus und Dell mit von der Partie - und sowohl Acer als auch Lenovo haben neue Geräte am Start. Acers Nitro 5 ist ein Gaming-Laptop der Einstiegsklasse und besitzt neben einem Ryzen 7 2700U oder Ryzen 5 2500U noch eine eigenständige RX-560-Grafikkarte. Bei Dell steckt zum ersten Mal überhaupt ein Ryzen-Chip in der High-End-Serie Inspiron 5000, auf Wunsch auch mit einer RX-530-GPU.

Robert Hallock: Zu den im letzten Jahr gestarteten und den aktuell angekündigten Laptops kommt Mitte bis Ende 2018 eine dritte Welle mit noch etlichen weiteren Systemen - dann hat AMD dank Ryzen Mobile so viele High-End-Notebooks auf dem Markt wie noch nie zuvor in der Firmengeschichte.

http://www.pcgameshardware.de/Vega-Codename-265481/Specials/Intel-und-AMD-Chips-mit-Vega-Grafik-CES-2018-Interview-1248828/

[deekey777]

Nicht RX 530, eher Radeon 530X, sehe das eine Asus-Teil bzw. https://www.anandtech.com/show/12233/amd-tech-day-at-ces-2018-roadmap-revealed-with-ryzen-apus-zen-on-12nm-vega-on-7nm/2

Oder es ist wirklich ein teildeaktivierterer Polaris 12.

[BoMbY]

Die RX 530 ist so oder so ein 6 CU Krüppel, und vermutlich schlechter als die iGPU in Ryzen Mobile ... die OEMs sind einfach nur allesamt dämlich.

[Zergra]

Kommt die V11 eig. an eine 1050GTX heran ?

[Pirx]

erste Benchmarks der Desktop-Modelle https://www.computerbase.de/2018-01/amd-raven-ridge-desktop-erste-benchmarks/

3DMark11 P

1050Ti (Notebook) ~9754
1050 (Notebook) ~7745
RX 460 (Laptop) ~7792
MX150 ~4555
960M ~5278
950M ~4367
Intel Iris Plus Graphics 650 (z.B. im Intel Core i7-7567U) ~2761
Intel UHD Graphics 630 (z.B. im Intel Core i7-8700K ~1860

2400G: 5042
2200G: 3950
2700U: 4072
2500U: 3655
2300U: 3252
2200U: 1898

thx CB-Mracpad & paul1508 (https://www.computerbase.de/forum/showthread.php?t=1745063&p=20890152#post20890152)

[dildo4u]

Kommt die V11 eig. an eine 1050GTX heran ?

1030

https://www.pcper.com/news/Processors/CES-2018-AMD-Ryzen-Desktop-CPU-Vega-Graphics-Coming-Feb-12

[mczak]

1030
https://www.pcper.com/category/tags/2200g
Das Niveau einer 1050 wäre auch ein bisschen viel verlangt. Selbst bei der theoretischen Rechenleistung kommt das nicht hin (ist immerhin einigermassen knapp).
Aber auch mit ddr4-3200 hat man nicht mal die halbe Speicherbandbreite, ausserdem nur 1/4 der ROPs (wobei mehr ROPs bei RR nichts bringen würden aufgrund der limitierten Speicherbandbreite, und die GTX 1050 hat sicher mehr als genug davon).
Um das Niveau der GTX 1050 zu erreichen bräuchte man eine APU mit ~16 CUs und HBM...

[Thunder99]

Sowas wie Intel dank AMD nun hat

[mczak]

Sowas wie Intel dank AMD nun hat
Das ist keine APU, sondern eine stinknormale diskrete GPU (mit etwas Software-Magie wegen der shared TDP).

[Loeschzwerg]

Letztendlich egal was du dem Kind für einen Namen gibst ^^

[Thunder99]

So sieht es aus ^^

[y33H@]

Testwünsche für Raven Ridge Desktop? Ich hab bisher paar Spiele, Adobe Premiere/Lightroom, reines Encoding - dazu noch ne Skalierung mit RAM (DDR4-2933-SR aufwärts), zudem freilich Leistungsaufnahme. Mit dabei sind i3-8100 + GT 1030 und der A12-9800.

[deekey777]

Testwünsche für Raven Ridge Desktop? Ich hab bisher paar Spiele, Adobe Premiere/Lightroom, reines Encoding - dazu noch ne Skalierung mit RAM (DDR4-2933-SR aufwärts), zudem freilich Leistungsaufnahme. Mit dabei sind i3-8100 + GT 1030 und der A12-9800.
Realitätsnahe Einstellungen, sprich Apfel-Birnen-Vergleich.

Beispiel: Crysis ist in 1080 mit Very High nicht spielbar, aber mit 1600/1440/1366p und einem Mix aus mittleren und hohen Einstellungen. Vielleicht als eigener Artikel.

[KORE]

Ein Vergleich zu etwas älteren Grafikkarten wäre Interessant.

[spotz]

Ja, mich würde auch interessieren was bei 1600x900 mit niedrigen, mittleren oder gar hohen Details spielbar ist. Außerdem würde ich gerne wissen, ob und wie tief der Takt der CPU gedrosselt wird und ob das bei prozessorlastigen Spielen ein Problem darstellt. Keine Ahnung, vielleicht bei Strategiespielen im späteren Spielverlauf mit vielen Einheiten?

[Oranje7]

Ein Vergleich zu etwas älteren Grafikkarten wäre Interessant.
Da wäre ich auch zu begeistern.

[Zergra]

1030

https://www.pcper.com/news/Processors/CES-2018-AMD-Ryzen-Desktop-CPU-Vega-Graphics-Coming-Feb-12

Danke, dann hat sich das für mich erledigt. Dann nehme ich lieber einen Ryzen + 1050.

[Tyrann]

Testwünsche für Raven Ridge Desktop? Ich hab bisher paar Spiele, Adobe Premiere/Lightroom, reines Encoding - dazu noch ne Skalierung mit RAM (DDR4-2933-SR aufwärts), zudem freilich Leistungsaufnahme. Mit dabei sind i3-8100 + GT 1030 und der A12-9800.

Eine Idleverbrauchsmessung mit einem Mini-ITX Board und Pico-PSU würde ich mir wünschen, dazu den x264/x265 ST vs. MT x64 CPU-Benchmark (https://www.forum-3dcenter.org/vbulletin/showthread.php?t=581419) und ein paar Versuche zu Undervolting wären nicht schlecht.

[2B-Maverick]

Testwünsche für Raven Ridge Desktop? Ich hab bisher paar Spiele, Adobe Premiere/Lightroom, reines Encoding - dazu noch ne Skalierung mit RAM (DDR4-2933-SR aufwärts), zudem freilich Leistungsaufnahme. Mit dabei sind i3-8100 + GT 1030 und der A12-9800.

Genial wäre ein IPC Vergleich zum normalen Ryzen:
gleiche Taktraten bei CPU/RAM und dann mal ein paar Anwendungen testen.

[Naitsabes]

Sonst wäre bei Ram-Skalierung nicht nur der Takt interessant (Latenzen, Takt, Modulzahl, Ranks, der IGP zugewiesene Speichermenge).

[reaperrr]

Genial wäre ein IPC Vergleich zum normalen Ryzen:
gleiche Taktraten bei CPU/RAM und dann mal ein paar Anwendungen testen.
Dem schließ ich mich an.

Vor allem auch Vergleich mit und ohne SMT (R3 1200, R5 1400), wenn Zeit ist auch IPC mit 1500X vergleichen (wegen 16MB L3).

[ZuseZ3]

Testwünsche für Raven Ridge Desktop? Ich hab bisher paar Spiele, Adobe Premiere/Lightroom, reines Encoding - dazu noch ne Skalierung mit RAM (DDR4-2933-SR aufwärts), zudem freilich Leistungsaufnahme. Mit dabei sind i3-8100 + GT 1030 und der A12-9800.

Zu der Hardware selbst, nicht nur OC sondern besonders UV tests fände ich toll um zu gucken ob man sie dann evtl. sogar passiv gekühlt bekommt? Wobei das bei euch iirc. ja meistens dabei war.
Bisher hatte ich eine RX 460 passiv, die aber wegen eines Defektes zurückging. Ein komplett passiver PC mit der selben Leistung wäre ein Traum, auch wenn es bei 65 W TDP trotz UV wohl eng werden würde.

Was Spiele angeht:

Es wäre lieb wenn du noch die neue "Encore" Engine von WoT testen könntest, da WoT an sich ja ein relativ beliebtes Spiel ist.
Gerüchteweise will Wargaming mit der Engine mal im Jahr 2015 ankommen :biggrin:
Die bisherigen APUs können WoT auf FullHD akzeptabel wiedergeben, ich bin gespannt ob mit den neueren APUs auch die neueren WoT Versionen akzeptabel laufen.
Hier ist der Link:
https://wotencore.net/3142_de1

Ansonsten wäre noch Witcher 3 nett, auf FullHD könnte das ja mitlerweile Spielbar werden?

[MadManniMan]

Schön wäre eine Leistungsnormalisierung auf den je aufzuwendenen Preis.

[Opprobrium]

Ein paar Chipsatz Vergleiche sind vermutlich recht aufwändig, oder? Also PCIe/USB/Sata Performance, evtl. Ethernet. Das wandert ja immer mehr in die CPU bzw. sitzt da schon mehr oder weniger komplett, und mich würde mal interessieren ob es da noch relevante Unterschiede zwischen Intel und AMD gibt.

[robbitop]

@y3h@
Was wirklich schön wäre: Taktnormierter (festgetackerter All-Core Takt!) Vergleich von Spielen (3-4 aktuelle Spiele) mit anständiger GPU im CPU Limit. Gegen einen Kern mit SKL mArch und einen mit Summit Ridge. Gleiche Anzahl von Kernen und Threads. Gleicher RAM Takt. Inkl. 1% lows. Inkl. Sanitycheck und warmlaufen.

[mczak]

Ram-Skalierung wäre nett auch runter von ddr4-2933 und nicht nur rauf. Klar, die GPU kann nicht genug Bandbreite bekommen, aber sollten OEMs das verbauen kriegt man wahrscheinlich nur selten mehr als ddr4-2400 (und muss dabei noch Glück haben wenn es dual-channel ist...).
Und der i3-8100 ist hoffentlich auch mit der IGP dabei?

[Ravenhearth]

Dem schließ ich mich an.

Vor allem auch Vergleich mit und ohne SMT (R3 1200, R5 1400), wenn Zeit ist auch IPC mit 1500X vergleichen (wegen 16MB L3).
Beim IPC-Vergleich in Spielen mit 4C-Ryzen würde mich auch interessieren, wie viel davon zustande kommt, weil RR nur einen CCX hat. Es wurde ja festgestellt, dass die 2+2 Aufteilung Leistung kostet. Also:

Ryzen mit 2+2
Ryzen mit 4+0 (simuliert)
RR

Somit könnte man genau gucken, wie viel der Verzicht auf die Aufteilung bringt, und ob/wie viel durch Verbesserungen an Cache, MC etc zustande kommt.

Was GPU-Leistung angeht ein Vergleich mit Xbox One (PS4 ist wohl noch zu stark) :biggrin: Also versuchen, in ein paar beliebten Spielen die gleiche Auflösung + Settings einzustellen und die Performance zu messen.

[Thunder99]

y33H@, Civ6 wäre gut :up:

[Knuddelbearli]

Testwünsche für Raven Ridge Desktop? Ich hab bisher paar Spiele, Adobe Premiere/Lightroom, reines Encoding - dazu noch ne Skalierung mit RAM (DDR4-2933-SR aufwärts), zudem freilich Leistungsaufnahme. Mit dabei sind i3-8100 + GT 1030 und der A12-9800.


DR Ram und auch 1-2 mal mit mit geringerem takt da komplett PCs oft auch mit weniger ausgeliefert werden.

Dazu je 1 heavy CPU limit spiel und dann anschauen wie sich dei GPu da verhaltet

[Loeschzwerg]

Jup, ein Vergleich SR vs DR wäre schön, Kaveri konnte hier ordentlich zulegen.

[basix]

IPC clock to clock vergleich mit Ryzen und HSW, KBL und später nachgereicht mit Pinnacle Ridge.

RAM Skalierung und ein Spezialtest mit Subtiming Optimierungen bei einem einzelnen OC RAM Setting hinsichtlich GPU-Leistung (Anleitung Subtiming Optimierung siehe TheStilt Guide für Ryzen)

[tm0975]

Testwünsche für Raven Ridge Desktop? Ich hab bisher paar Spiele, Adobe Premiere/Lightroom, reines Encoding - dazu noch ne Skalierung mit RAM (DDR4-2933-SR aufwärts), zudem freilich Leistungsaufnahme. Mit dabei sind i3-8100 + GT 1030 und der A12-9800.

TPC-H für den Bereich Anwendungssoftware, wobei das eigentlich erst für die 8-kerner im April interesant wird.

[dildo4u]

Userbench Ryzen 5 1400 vs 2400G.

http://cpu.userbenchmark.com/Compare/AMD-Ryzen-5-1400-vs-AMD-Ryzen-5-2400G-Vega-Graphics/3922vsm433194

[Pirx]

hmm singlecore float?? hakt wohl noch etwas?

[teetasse]

Userbench

Userbench ist Crap.

[teetasse]

Jup, ein Vergleich SR vs DR wäre schön, Kaveri konnte hier ordentlich zulegen.

Jau, hier schließe ich mich an: Dual Rank mit hohem Takt, bitte! Scheiß egal, ob das offiziell spezifiziert wurde, so lange es läuft! (die Spec hat bei Ryzen mit 3200er RAM auch niemanden interessiert.)

Dazu einen Intel i3 mit IGP testen, beide Modelle zum gleichem Preis (bei Ryzen den geschätzten Straßenpreis ansetzen, um den Vergleich nicht zu verzerren)

Und den aktuellen PCMark.

Der Vorschlag mit dem "festgetackerten Takt" / "clock-to-clock" hat das Problem, dass sowas total unrealistisch ist, vor allem heutzutage mit Techniken wie Precision Boost 2!

[robbitop]

clock for clock ist einfach nur interessant zu sehen wie sich die march taktnormiert verhält.

[y33H@]

Dual Rank schaffe ich DDR4-2667-CL15, einen Core i3-8100 hab ich da.

[teetasse]

Hmm, wenn er mehr nicht packt, würde mich der Vergleich mit Single Rank bei gleichem Takt interessieren.

[dildo4u]

Mit Raven Ridge Kompatible Boards sollen im Handel mit einem Sticker gekennzeichnet werden.


https://twitter.com/99_HONTEN_Parts/status/959338272844427265/photo/1

[mczak]

Mit Raven Ridge Kompatible Boards sollen im Handel mit einem Sticker gekennzeichnet werden.
https://twitter.com/99_HONTEN_Parts/status/959338272844427265/photo/1
Sollten doch alle sein? Oder werden manche immer noch mit zu altem BIOS verkauft (da ist dann immer die Frage ob es gar nicht läuft oder gut genug um wenigstens ein neues BIOS flashen zu können...).

[dildo4u]

Wird massig Boards ohne Bios Updates im Handel geben,Asus ist der einzige der fast seine komplette Palette aktuell hat. Natürlich wird es aber auch Asus Boards von 2017 mit altem Bios im Handel geben.

https://www.computerbase.de/2018-01/ryzen-2000-mainboard-bios-updates/

Bei den aktuellen Ram und GPU Preisen dürfte auch der durchverkauf von B350/370 Boards langsam sein,daher wird es ne Weile dauern bis nur kompatible Boards im Handel sind.
Fürs Mining würde ich ein 60€ Pentium als Plattform kaufen,AMD macht dort weniger Sinn.

[Pirx]

Startet ein Board mit altem Bios und RR gar nicht?

[StefanV]

gute Frage.
Wäre echt interessant.

Weil für mein Biostar gibts immer noch kein Ryzen 2k AGESA BIOS...

[DarknessFalls]

Also, ich habe ein altes AM3-Board von Gigabyte hier (irgendwas mit 790FX), das kein BIOS mehr für die Phenom X6 bekommen hat. Es startet trotzdem, gibt dann aber nur "unknown CPU type" an. Sogar mit korrekten MHz.

Ich denke, da kann man durchaus Glück haben, dass das Board startet...

[YfOrU]

Gehe ich nicht von aus denn Raven Ridge hat im Gegensatz zu Summit Ridge eine IGP (Firmware notwendig) und mit Blick auf Mobile dürfte es auch am Design (Power Management) einige Anpassungen gegeben haben.

[MadPenguin]

Wird RR eigentlich in 12nm gefertigt? Oder noch 14nm?

[bbott]

Wird RR eigentlich in 12nm gefertigt? Oder noch 14nm?

RR ist 14nm und SR ind 12nm, aber beide sollen Zen+ sein.

[Opprobrium]

RR ist 14nm und SR ind 12nm, aber beide sollen Zen+ sein.

Laut Anandtech (https://www.anandtech.com/show/12233/amd-tech-day-at-ces-2018-roadmap-revealed-with-ryzen-apus-zen-on-12nm-vega-on-7nm/2) ist RR nicht Zen+, sondern "first-generation Zen core"

At the heart of both of these designs is the combination of AMD’s first-generation Zen cores, specifically four cores in a ‘core complex’, connected to Vega-based graphics integrated into the silicon. The two units are connected via AMD’s Infinity Fabric, designed for high-bandwidth and scale, and a feature that permeates through AMD’s recent product portfolio.

[w0mbat]

RR ist 14nm und SR ind 12nm, aber beide sollen Zen+ sein.

RR und SR sind beide 14nm, PR ist 12nm.

[y33H@]

Laut Anandtech (https://www.anandtech.com/show/12233/amd-tech-day-at-ces-2018-roadmap-revealed-with-ryzen-apus-zen-on-12nm-vega-on-7nm/2) ist RR nicht Zen+, sondern "first-generation Zen core"Ist Zen+ noch 1st Gen wenn erst Zen2 die 2nd Gen ist? ^^ ich hab AMD explizit noch mal gefragt ob sie bei RR mit einem IPC Zuwachs verglichen zu SR erwarten und wenn ja, warum. Schau mer mal ...

[Thunder99]

Wenn die Desktop Version DDR4 2933 unterstützt dann wird wohl was von Ryzen+ drin sein, oder?

[BoMbY]

Ist Zen+ noch 1st Gen wenn erst Zen2 die 2nd Gen ist? ^^ ich hab AMD explizit noch mal gefragt ob sie bei RR mit einem IPC Zuwachs verglichen zu SR erwarten und wenn ja, warum. Schau mer mal ...

Das ist doch lange bekannt, dass Raven Ridge und Pinnacle Ridge praktisch keine Änderungen gegenüber Summit Ridge bei der Kern-Architektur haben - das ist alles znver1, Family 17h, K17 - znver2 wird auch wohl Family 18h bzw. K18.

[Thunder99]

Kommt noch was in Richtung 2700U und Tablet/Laptop Gerät? Außer dem HP, was mittelmäßig ist, sehe ich nichts

[deekey777]

Kommt noch was in Richtung 2700U und Tablet/Laptop Gerät? Außer dem HP, was mittelmäßig ist, sehe ich nichts
Sofort lieferbar: https://www.notebooksbilliger.de/lenovo+720s+13arr+81br000xge/incrpc/lastseen

Auch das Acer Swift 3 ist verfügbar: https://www.notebooksbilliger.de/acer+swift+3+sf315+41+r4ae/eqsqid/e6c8d22c-6262-4ebf-b475-f59196884e66

Das Problem:
Das Lenovo-Gerät soll nach dem aktuellen Stand nur Singlechannel können, was wirklich Mist ist, während das Swift 3 nur 15W darf.

[y33H@]

Das ist doch lange bekannt, dass Raven Ridge und Pinnacle Ridge praktisch keine Änderungen gegenüber Summit Ridge bei der Kern-Architektur haben - das ist alles znver1, Family 17h, K17 - znver2 wird auch wohl Family 18h bzw. K18.Ein paar Änderungen gibt es und dazu sollen sie bitte was sagen.

[dildo4u]

Kommt noch was in Richtung 2700U und Tablet/Laptop Gerät? Außer dem HP, was mittelmäßig ist, sehe ich nichts
Warte weiter ab es gibt immer noch keine aktuellen Treiber für den GPU Teil des Chips,ich würde das Ding erst kaufen wenn klar ist ob es wie die AMD GPUs ständig neue Treiber bekommt.Ist imo kein Zustand dann man aktuelle Treiber zur Zeit über den Geräte Manager installieren muss.Könnte mir vorstellen das der Notebook Treiber bessere Optimierungen für das Power Management hat.

[Thunder99]

Meinte ja eher Convertible Gerät.

Naja heißt es dann noch warten :(

[Achill]

Ich warte auch noch auf ein gutes Notebook, ich wünsche mir (brauche):
- 2500U oder 2700U
- 14" FullHD ISP Display matt
- 16+ GB RAM
- 512+ GB SSD
- DP-Ausgang
- Lautloser Lüfter bei Idle
- max. 1.8kg

Toll wäre noch:
- Beleuchtete Tastatur
- Docking-Lösung
- Fingerprint-Reader
- Linux-Kompatibilität ohne Basteln

Das Teilchen darf dann bei guter Verarbeitung auch gern +1500€ kosten. Sowas hat noch keiner gesehen oder?

[Loeschzwerg]

Das Problem:
Das Lenovo-Gerät soll nach dem aktuellen Stand nur Singlechannel können, was wirklich Mist ist, während das Swift 3 nur 15W darf.

Single-Channel, fest verlötet und sogar nur DDR4-2133 :(
http://psref.lenovo.com/syspool/Sys/PDF/Lenovo%20Laptops/ideapad%20720S%20(13_)/ideapad_720S_13.pdf

[Unicous]

Warum die ix Chips standardmäßig 2400er RAM verbaut haben, während RR mit 2133er auskommen muss weiß wohl auch nur Lenovo. Und warum wird der "Cache" falsch ausgewiesen?:confused:

[deekey777]

Single-Channel, fest verlötet und sogar nur DDR4-2133 :(
http://psref.lenovo.com/syspool/Sys/PDF/Lenovo%20Laptops/ideapad%20720S%20(13_)/ideapad_720S_13.pdf
Wo siehst du den Eintrag mit Single-Channel? ;(

(Die Daten bestätigen eigentlich die früheren Angaben vom Ende Oktober, aber die Hoffnung stirbt ja zuletzt.)

[Pirx]

Ich warte auch noch auf ein gutes Notebook, ich wünsche mir (brauche):
- 2500U oder 2700U
- 14" FullHD ISP Display matt
- 16+ GB RAM
- 512+ GB SSD
- DP-Ausgang
- Lautloser Lüfter bei Idle
- max. 1.8kg

Toll wäre noch:
- Beleuchtete Tastatur
- Docking-Lösung
- Fingerprint-Reader
- Linux-Kompatibilität ohne Basteln

Das Teilchen darf dann bei guter Verarbeitung auch gern +1500€ kosten. Sowas hat noch keiner gesehen oder?
Wenn die HP Elitebooks auf Ryzen Pro "geupgraded" werden vielleicht.



Single Channel beim 13"-Lenovo, auch bei der Intel-Version
https://www.pcper.com/category/tags/ideapad-720s
grml

[Loeschzwerg]

Wo siehst du den Eintrag mit Single-Channel? ;(

(Die Daten bestätigen eigentlich die früheren Angaben vom Ende Oktober, aber die Hoffnung stirbt ja zuletzt.)

Davon steht da leider nix, hier stütze ich mich auch nur auf die Daten von der AMD Folie:
https://linustechtips.com/main/applications/core/interface/imageproxy/imageproxy.php?img=https://images.anandtech.com/doci/11964/amd_ryzen_processor_with_radeon_graphics_press_deck-legal_final-page-043_575px.jpg&key=de7cf6ac5a73697ae6385bb15b39dc2e580beb6d91af4e8430d57746fd16b62d

Das Notebook wäre sonst echt interessant, irgendwie ziemlich schade.

[Pirx]

auf der Lenovoseite steht beim 15" 720S explizit Dualchannel, beim 13" nichts https://www3.lenovo.com/il/en/laptops/ideapad/ideapad-700-series/c/Ideapad-700

[Loeschzwerg]

Wo gibt es das 15" 720S mit RR?

[Pirx]

gar nicht, siehe Link zu Lenovo:(

[dildo4u]

PCPER: AMD Ryzen 5 2500U Mobile APU Performance with Raven Ridge

https://www.pcper.com/reviews/Mobile/AMD-Ryzen-5-2500U-Mobile-APU-Performance-Raven-Ridge

[gmb]

PCPER: AMD Ryzen 5 2500U Mobile APU Performance with Raven Ridge

https://www.pcper.com/reviews/Mobile/AMD-Ryzen-5-2500U-Mobile-APU-Performance-Raven-Ridge


Da bestätigt sich mal wieder, dass AMD mit Raven Ridge immer noch nicht konkurrenzfähig ist bei der CPU Leistung im ULV Bereich. AMD braucht 25W um Intels 15W Leistung zu erreichen. Im gleichen TDP Budget wird Intel Raven Ridge locker abziehen.


In CPU heavy tasks such a POV-Ray, we saw a power draw of around 37W for the Ryzen 5 2500U, 14W more than the quad-core Intel processors.

Looking at the power draw numbers from this specific notebook with the R5 2500U, you could make an argument that it actually should be compared to Intel’s higher performance H-series parts, which are quoted at a 35W TDP.


Treibersupport wie schon im Notebookcheck Test immer noch unter aller Sau. KBL-R mit MX150 hat auch bei der gaming Effizienz große Vorteile.


There have been no updated drivers released for the HP Envy x360 since it’s launch in November

[Opprobrium]

Da bestätigt sich mal wieder, dass AMD mit Raven Ridge immer noch nicht konkurrenzfähig ist bei der CPU Leistung im ULV Bereich. AMD braucht 25W um Intels 15W Leistung zu erreichen. Im gleichen TDP Budget wird Intel Raven Ridge locker abziehen.

Treibersupport wie schon im Notebookcheck Test immer noch unter aller Sau. KBL-R mit MX150 hat auch bei der gaming Effizienz große Vorteile.

Zum ersten Punkt würde ich noch ein paar mehr Tests abwarten, könnte aber natürlich letztendlich darauf hinaus laufen. Der Unterschied ist aber schon deutlich geschrumpft, besonders wenn man die Grafikleistung mit in Betracht zieht. Und es sieht auch besser für AMD aus, wenn es richtung Multithreading geht.

Was den Treibersupport angeht kann man nur hoffen, daß es mit dem Start der Desktop RRs besser wird :( Allgemein wurde RR bisher ja eher halbherzig behandelt. Sowohl von AMD als auch von den Laptop herstellern. Ist aber auch noch sehr jung :smile:

[Pirx]

Gibt andere Tests, in denen der 15W RR sehr gut aussieht, auch CPU-seitig. Leider bezieht gmb diese nicht in seine Betrachtungen ein.

[Blediator16]

Zum Glück ist das ein allgemeiner 2500U Test, der auf sämtliche andere Notebooks zutrifft :facepalm:

[dildo4u]

Ich würde 15 Zoll immer mit 25 Watt konfigurieren,die meiste Zeit wird man das Ding am Stecker haben.Bei 14 Zoll macht 15Watt deutlich mehr Sinn,das macht HP schon richtig.
gmb ignoriert natürlich das Vega 8 Intels IGP komplett zersägt,100% mehr Leistung bei 50% mehr Verbauch.

[mczak]

Da bestätigt sich mal wieder, dass AMD mit Raven Ridge immer noch nicht konkurrenzfähig ist bei der CPU Leistung im ULV Bereich. AMD braucht 25W um Intels 15W Leistung zu erreichen. Im gleichen TDP Budget wird Intel Raven Ridge locker abziehen.

So extrem würde ich das nicht formulieren. Die Single-Core Leistung dürfte nicht wesentlich abnehmen bei 15W. Bei den multi-core Benches war der Ryzen ja manchmal auch schneller - klar da verliert man dann natürlich Leistung, dürfte aber immer noch ziemlich konkurrenzfähig sein.
Bei den 3d-Benchmarks wird man sicher auch Leistung verlieren - ist aber kein Problem, die intel igpu wird man trotzdem noch immer locker abhängen.
Ausserdem muss man da immer aufpassen wie genau man da misst, denn auch die 15W TDP Intel Chips dürfen ja kurzfristig deutlich mehr verbrauchen. Hat man also einen Benchmark der bloss kurze Zeit läuft zählt eigentlich bloss das kurzfristige Limit.
Im Sinne der besseren Vergleichbarkeit wäre es natürlich wünschenswert dass die CPUs ähnlich konfiguriert sind (zumindest gleiche TDP - bei den kurzfristigen Limits ist eine identische Konfiguration wohl gar nicht möglich).

Das im Review erwähnte Problem mit den Treibern finde ich hingegen echt schlimm. AMD darf sich hier einfach nicht auf die OEMs verlassen und muss Treiber dafür anbieten. Es scheint fast als hätte man seit dem Fiasko mit den umschaltbaren diskreten Grafikchips (die mit MUX - ist eine Weile her...) nichts gelernt. Ansonsten kriegt man vielleicht mit etwas Glück 1 Update jedes Jahr, und das auch bloss die ersten 2-3 Jahre, danach kann man das eh vergessen. Um die Original-AMD-Treiber zu installieren dürfen keine Basteleien nötig sein.

[Achill]

Da bestätigt sich mal wieder, dass AMD mit Raven Ridge immer noch nicht konkurrenzfähig ist bei der CPU Leistung im ULV Bereich. AMD braucht 25W um Intels 15W Leistung zu erreichen. Im gleichen TDP Budget wird Intel Raven Ridge locker abziehen.

[..]

Treibersupport wie schon im Notebookcheck Test immer noch unter aller Sau. KBL-R mit MX150 hat auch bei der gaming Effizienz große Vorteile.

Der Test bzgl. Leistungsaufnahme kann man doch schon wieder vergessen:

[..]
As it turned out, this was the case with the Ryzen 5 2500U, specifically in the HP Envy x360. Performing testing with fully charged notebooks plugged into AC adapters and the same external monitor (internal displays were disabled due to potential variance), we measured how much each notebook was drawing “at the wall.”
[..]


So wie es dort steht wird nach dem Netzteil gemessen, was je nach Preisklasse sicherlich unterschiedlich in der Effizienz ist. Damit sind die Werte bzgl. Leistungsaufnahme zwar interessant, passen aber nicht für P/W Aussagen und denn jeweiligen Schlussfolgerungen hier (imho).

--
Edit: Bzgl. "AMD braucht 25W um Intels 15W Leistung zu erreichen." kann ich auch nicht im Text wiederfinden, wo steht das die AMD APU mit 25W läuft?

[deekey777]

Sie läuf mit 25W, genauer gesagt, beherrscht das Envy mXFR. Und hier fängt der Schwachsinn eigentlich an, denn gewisse Prädiger in diesem Thread sind offensichtlich so blind, dass sie nicht einsehen wollen, dass so gut wie alle "15W"-CPUs je nach Kühlung und Auslegung der Stromversorgung deutlich mehr als 15W verbrauchen dürfen, anderenfalls können sie ihren Turbotakt gar nicht erreichen. Irgendwann wird die Taktrate abgesenkt bzw. sie muss abgesenkt werden, sonst wird das Gerät zu heiß etc. mXFR bis zu 25W erlaubt eine längere Zeit mit höheren Taktraten zu laufen.

Das sind Ergebnisse mehrerer CB-Durchläufe eines Geräts mit R5 2500U auf 15W limitiert: https://www.notebookcheck.com/Test-Acer-Swift-3-SF315-Ryzen-5-2500U-Vega-8-256-GB-FHD-Laptop.275900.0.html#toc-leistung

Und das ist das Envy mit 25 W:
https://www.notebookcheck.com/Test-HP-Envy-x360-15-Ryzen-5-2500U-Radeon-Vega-8-Laptop.267826.0.html#toc-leistung
Deutlich stabilere Ergebnisse und dazu höher.

[mczak]

Das sind Ergebnisse mehrerer CB-Durchläufe eines Geräts mit R5 2500U auf 15W limitiert: https://www.notebookcheck.com/Test-Acer-Swift-3-SF315-Ryzen-5-2500U-Vega-8-256-GB-FHD-Laptop.275900.0.html#toc-leistung

Und das ist das Envy mit 25 W:
https://www.notebookcheck.com/Test-HP-Envy-x360-15-Ryzen-5-2500U-Radeon-Vega-8-Laptop.267826.0.html#toc-leistung
Deutlich stabilere Ergebnisse und dazu höher.
Sind dann so ~12% Unterschied (bei MT). Da sieht man auch sehr schön dass 15W vs. 25W eben bei nur kurz dauernden Benchmarks keinen Unterschied macht - im ersten Durchlauf sind beide ziemlich genau gleich schnell.
Leider geben viele Reviews bloss den Wert des ersten Durchlaufs an (die Werte bei pcper sehen definitiv nach erstem Durchlauf aus).
Wobei manche OEMs konfigurieren auch ein etwas zu hohes TDP - das äussert sich dann in nicht stabilen Ergebnissen zwischen Durchläufen (weil Thermal Throttling unmittelbar deutlichere Taktratensenkungen zur Folge hat und es halt immer eine gewisse Verzögerung bei der Temperaturentwicklung gibt). Zumindest mit intel-Chips gab's schon Tests die das klar aufzeigten - wie sich da AMD Chips genau verhalten weiss ich nicht, aber wenn AMD es richtig gelöst hat dürfte es ähnlich sein. Immerhin hat sowas keinen allzugrossen Einfluss auf den Durchschnittswert (gegenüber einem leicht tieferen TDP-Limit das zu keinem Thermal Throttling führt).

[deekey777]

Das Problem ist: Worauf kommt es eigentlich an?

Für reine Laptops ist die Leistung überdimensioniert. "15 Watt" sind genug, wenn die Leistung kurz abgerufen wird (zB Aufbau einer Seite mit vielen eingebeteten Videos).

Wenn der Laptop wirklich über längere Zeit belastet wird, dann will man doch, dass die Leistung so hoch wie möglich bleibt.

[mczak]

Wenn der Laptop wirklich über längere Zeit belastet wird, dann will man doch, dass die Leistung so hoch wie möglich bleibt.
Das kommt darauf an - kann sein dass z.B. der Lärm in keinem Verhältnis zur Mehrleistung steht, ich mag meine PCs gerne leise :biggrin:. Manche Notebooks können richtig unangenehm laut werden (zumindest für mein Empfinden). Im Idealfall wäre das mehr oder weniger frei konfigurierbar (z.B. via Energiesparplan).

[Loeschzwerg]

So dünn wie aktuelle Notebook sind, können diese bei 15-25Watt gar nicht mehr wirklich leise sein. Unter Dauerlast sind diese immer deutlich hörbar, da dürften die Silent-Freaks hier aus dem Forum reihenweise krepieren :D

Ich würde mir hier durchgehend mehr Optionen im UEFI/Bios der Notebooks wünschen. Bei Bedarf 15 Watt und mehr, für normalen Office Betrieb 10 Watt und weniger.

[deekey777]

Es ist alles die Frage des Preises, das Surface Book 2 ist passivgekühlt (das Tablet) und kann nach einem Leistungsabfall die Leistung halbwegs stabil halten, https://www.notebookcheck.com/Test-Microsoft-Surface-Book-2-i7-GTX-1050-Convertible.263782.0.html#toc-leistung

Das ist je nach Gerät die Leistung eines aktivgekühlten i5-8250U nach mehreren Durchläufen.

Man kann unter Windows 10 schon die Leistung bestimmen - wenn der HErsteller dies auch will. Mein Billig-HP (A10-9600P) hat (nur) eine Option im BIOS: Fan always on/off (diese hat auch das Envy mit dem RR). Ist sie off, bleibt der Lüfter im Energiesparmodus still, sprich beim einfachen Fernsehen/Surfen dreht der Lüfter selten auf (aber hörber und es kommt sehr warme Luft raus), dafür läuft die CPU fast durchgehend mit 1,15 GHz und taktet sehr widerwillig hoch. Wird die CPU durch Antimalware hochgejagt, dann läuft auch der Lüfter - darum ist Surface Book 2 wohl passivgekühlt. X-D

[Opprobrium]

Es ist alles die Frage des Preises, das Surface Book 2 ist passivgekühlt (das Tablet) und kann nach einem Leistungsabfall die Leistung halbwegs stabil halten, https://www.notebookcheck.com/Test-Microsoft-Surface-Book-2-i7-GTX-1050-Convertible.263782.0.html#toc-leistung

Aber da wird sicher nicht die TDP ausgereizt. Man hat halt oft die Wahl zwischen fiesen Lüftergeräuschen oder einem sehr warmen Gerät, daß seine Leistung nicht abrufen kann weil die CPU nach kürzester Zeit drosselt. Hab das auf einem Surface Pro 3 mal gemerkt als ich auf einer Zugfahrt Darkest Dungeon zocken wollte. Dazu kommt dann oftmals noch die Problematik, daß nicht einmal die Netzteile für dauerhafte Belastung ausgelegt sind, so daß sich dann (ebenfalls beim Darkets Dungeon zocken im Zug) der Akku trotz angeschlossenem Netzteil langsam entleert. Ist beim Surface Book wohl auch so wenn ich das richtig im Kopf habe.

Bei 400€ Laptops könnte ich diese Probleme akzeptieren, aber nicht bei Geräten die sich weit jenseits der 1000€ bewegen können.

[Pirx]

Tum Apisak wieder in Aktion

http://ranker.sisoftware.net/show_device.php?q=c9a598d994d0f0b1c5adc1aec0e0d2e2d295d0f0a2c3a7c2adc3e3b5d0b7d6 f6b1c3a2d2bad3b0c3e582bf92a385f7cafbddb489afc7fadca499bfdabf82b294e7dae2&l=en

Dualcore? Desktop? Athlon? Vega?
:D

[BoMbY]

Die "Great Horned Owl" scheint auch auf dem Weg zu sein (https://twitter.com/momomo_us/status/961219917545488384):

https://pbs.twimg.com/media/DVbwafbUQAAr8U9.jpg:orig

[teetasse]

Noch ein Wunsch für den Golem-Test:

Details über die beiden verbesserten IP-Blöcke "Video Core Next" und "Display". Falls das zeitlich eng wird, gerne auch später.

[Loeschzwerg]

Tum Apisak wieder in Aktion

http://ranker.sisoftware.net/show_device.php?q=c9a598d994d0f0b1c5adc1aec0e0d2e2d295d0f0a2c3a7c2adc3e3b5d0b7d6 f6b1c3a2d2bad3b0c3e582bf92a385f7cafbddb489afc7fadca499bfdabf82b294e7dae2&l=en

Dualcore? Desktop? Athlon? Vega?
:D

Hm... möglicherweise der "Banded Kestrel" Ableger für den normalen Consumer Markt.

[y33H@]

Details über die beiden verbesserten IP-Blöcke "Video Core Next" und "Display". Falls das zeitlich eng wird, gerne auch später.Wir gucken uns grade VP910b unter Linux an.

[Kehaar]

Wann kommen die neuen Chipsätze (insbesondere B450) raus? Erst mit Pinnacle Ridge oder schon mit Raven Ridge? Wie sieht die Situation bei den Mainboardherstellern aus? Wird da umfangreich auf neue Sachen (mit B450) umgestellt oder läuft eher das jetzige alte Sortiment weiter?

Direkt an die hiesigen Pressevertreter: Macht AMD mit dem Start von Raven Ridge dazu irgendwelche näheren Aussagen?

[dildo4u]

Die neuen Chipsätze kommen im April.

https://www.forbes.com/sites/antonyleather/2018/01/07/amd-confirms-new-zen-ryzen-cpus-for-april-2018-x470-chipset-threadripper-and-apus-inbound-too/2/#

Schätze mal das Raven Ridge NDA fällt am 12.2.

https://twitter.com/AMDRyzen/status/961381258969280512

[teetasse]

Wir gucken uns grade VP910b unter Linux an.

Öhm, zu der Abkürzung finde ich nur einen Viewsonic Monitor :confused:
Aber ich werte es mal als Zustimmung :smile:

Diese beiden Blöcke sollen ja gegenüber Vega verbessert sein, wie bei Phoronix zu lesen war.

[Unicous]

VP9 10bit.

[basix]

Schätze mal das Raven Ridge NDA fällt am 12.2.


Das ist nicht nur eine Schätzung sondern definitiv so ;) Hardware Unboxed hat das explizit so kommuniziert (ok in Australien 13.2 um 1 Uhr Morgens ;D)

[Unicous]

:confused:

https://www.pcper.com/files/imagecache/article_max_width/news/2018-01-07/02_0.jpg

Wen interessieren irgendwelche Youtuber? Das Datum kommt offiziell von AMD.

[dildo4u]

Test NDA muss nicht immer der Launch Tag sein.

[y33H@]

Diese beiden Blöcke sollen ja gegenüber Vega verbessert sein, wie bei Phoronix zu lesen war.Bug-Fixing oder was schrieb Michael?

[teetasse]

Im Phoronix-Forum kommentieren auch die Treiber-Entwickler, die naturgemäß Ahnung von der Materie haben. Der User agd5f ist "AMD open source graphics developer" und schreibt:

"Depends what you consider "vega". Every GPU is a combination of IP blocks (display, memory controller, gfx/compute, multi-media, etc.). Raven shares a number of IP blocks with vega10 (e.g., gfx/compute), but some are different (display, multi-media)."

https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/1005998-radeonsi-vcn-encode-now-supports-hevc-main?p=1006025#post1006025

[y33H@]

Ja, ich sehe ein paar Unterschiede nun.

[teetasse]

Ja, ich sehe ein paar Unterschiede nun.

Hat AMD die Neuerungen nicht dokumentiert, in Form von Folien oder als Text?

[dildo4u]

AMD Ryzen 5 2400G synthetic and gaming benchmarks emerge

https://videocardz.com/74961/amd-ryzen-5-2400g-synthetic-and-gaming-benchmarks-emerge

Der Single Core Turbo ist massiv besser als bei den alten Ryzen Modellen,CPU-Z liegt dort um 360 bei den 65 Watt Modellen.2400G 440.

[w0mbat]

Also wenn die Daten stimmen und der 2200G wirklich 3,5GHz base-clk hat, bzw. der 2400G sogat 3,6GHz base-clk, dann können wir bei PR Flagschiff min. 4GHz base-clk erwarten.

Der 2200G ist quasi ein 1300X mit IGP, für $99 anstatt $129. Der 2400G hat 100MHz mehr base-clk und 200MHz mehr turbo-clk als ein 1500X, kostet mit $169 aber nur so viel wie ein 1400.

AMD wird die Preise mit PR. bzw. Ryzen 2k, nach unten drücken und den Takt gut anheben. 3,6GHz base-clk haben bisher nur 1600X und 1800X, jetzt kommt schon der kleine 2400G damit an :D

[y33H@]

Hat AMD die Neuerungen nicht dokumentiert, in Form von Folien oder als Text?Jein.

[mironicus]

Braucht man für die Grafikfähigkeiten des R2400G nicht auch ein Mainboard was HDMI 2.0 und DP 1.4 unterstützt? Davon gibt es wohl noch nicht so viele.