Kaveri - der Trinity Nachfolger
- Ersteller FredD
- Erstellt am
BoMbY
Grand Admiral Special
Ich denke schon, denn wenn der OpenCL-Treiber nichts von der Hardware weiß, dann macht der ja weiter ein Memcopy, wo er eigentlich keines braucht. Daher wäre ein Vorher/Nachher-Vergleich gut, wenn die 13.35 Treiber raus sind. Soweit ich das verstehe, brauchen die erstmal den neuen LLVM-Compiler zwischen API und Hardware, damit es läuft. Also im Beispiel von OpenCL sollte es eigentlich so laufen: OpenCL -> LLVM -> HSAIL -> Hardware.
Edit: Siehe auch deren Hsa10 whitepaper:
Zuletzt bearbeitet:
gruffi
Grand Admiral Special
Wobei einfache memcopys immer im gleichen Adressraum erfolgen. Also wo sie bisher notwendig waren, werden sie auch weiterhin notwendig sein. Interessant ist also, wo bisher vom RAM in den VRAM und umgekehrt kopiert werden musste. Keine Ahnung, wie das intern genau abläuft. Was vom Treiber übernommen wird, kann mit einem hUMA-aware Treiber sicherlich noch optimiert werden. Was von der Hardware übernommen wird, sollte wie gesagt auch ohne expliziten Treibersupport besser laufen.
BoMbY
Grand Admiral Special
Naja, ich meinte jetzt schon den Transfer in das GraKa-RAM. Im Prinzip müsste das ein Kommando an die CPU/GPU per DMA einen Speicherbereich über den PCIe-Bus zu kopieren. Wenn der Treiber das Kommando schickt, dann wird das auch weiter gemacht? Ich kann mir nicht vorstellen, dass das Kommando einfach ignorieren wird, und stattdessen direkt auf den Speicher zugegriffen wird, ohne das man das explizit erlaubt? Mal ganz abgesehen von möglichen Problemen wegen geschütztem Speicher, etc.
chrisihamm
Lieutnant
Hat sich jemand eigentlich schon einmal die ersten HSA Benchmarks angeschaut?
Ich bin zufällig auf """""""http://www.xtremesystems.org/forums/showthread.php?288366-AMD-Kaveri-Review-Focused-on-HSA-Features"" darauf gestoßen.
Ich bin zufällig auf """""""http://www.xtremesystems.org/forums/showthread.php?288366-AMD-Kaveri-Review-Focused-on-HSA-Features"" darauf gestoßen.
FredD
Gesperrt
- Mitglied seit
- 25.01.2011
- Beiträge
- 2.472
- Renomée
- 43
Hier nochmal als Link:
Xtremesystems.org - AMD-Kaveri-Review-Focused-on-HSA-Features
Xtremesystems.org - AMD-Kaveri-Review-Focused-on-HSA-Features
Ich glaube, den können wir noch gebrauchen, spätestens wenn mal wieder ein übereifriger Forist die gefühlt 38947561209435892te Debatte "Aber SuperPi und X86..." anstößt.
Zuletzt bearbeitet:
Wenn jetzt nicht nur Corels AfterShot Pro sonder Capture One 7 Pro genauso schneller wird, wird die Sache hochinteressant. Wenn das zusätzlich zu dezidierten Grafikkarten zu einer Beschleunigung führt, könnte das für AMD doch noch interessant werden.
---------- Beitrag hinzugefügt um 13:08 ---------- Vorheriger Beitrag um 13:03 ----------
Ich habe mal bei Phase One eine Anfrage gestellt.
---------- Beitrag hinzugefügt um 13:08 ---------- Vorheriger Beitrag um 13:03 ----------
Ich habe mal bei Phase One eine Anfrage gestellt.
BoMbY
Grand Admiral Special
Hab noch folgendes zu OpenCL und HSA im Artikel von AnandTech vom 14.01. gefunden:
Wobei ja schon für die 13.35 Beta HSA-Unterstützung angekündigt wurde - die Frage ist in welchem Umfang.
Wobei ja schon für die 13.35 Beta HSA-Unterstützung angekündigt wurde - die Frage ist in welchem Umfang.
Complicated
Grand Admiral Special
Alleine die Tatsache, dass AMD mit HSA die JPG Komporimierung um über das Doppelte beschleunigt ist ausreichend, wenn man bedenkt wie oft eine Webseite oder anderes Bildprogramm genutzt wird. Das ist definitiv schon ein Killerfeature, welches sicherlich auch gebencht werden könnte mit bestimmten Bildlastigen Webseiten oder anderen Programmen.
Edit: Sorry es ging um transcoding, also keine Webseiten die auf diesen Bench zutreffen.
Edit: Sorry es ging um transcoding, also keine Webseiten die auf diesen Bench zutreffen.
Zuletzt bearbeitet:
@Complicated: Da wäre ich mir nicht so sicher. Das erledigt ein Core i3 sicher in wenigen µs ohne überhaupt hochzutakten.
Jedenfalls wenn es nicht gerade JPEGs mit Gigapixel-Format sind, sondern 08/15 Bilddateien mit gängigen Abmessungen.
Andererseits wäre es interessant zu wissen wie sich HSA auf die Energie-Effizienz auswirkt. Ob sie gar verschlechtert wird?
All die Shader für solche Bagatell-Aufgaben zu wecken und sie kurz darauf wieder schlafen zu legen klingt recht ineffizient.
Jedenfalls wenn es nicht gerade JPEGs mit Gigapixel-Format sind, sondern 08/15 Bilddateien mit gängigen Abmessungen.
Andererseits wäre es interessant zu wissen wie sich HSA auf die Energie-Effizienz auswirkt. Ob sie gar verschlechtert wird?
All die Shader für solche Bagatell-Aufgaben zu wecken und sie kurz darauf wieder schlafen zu legen klingt recht ineffizient.
Zuletzt bearbeitet:
Wann tritt denn die jpg-Komprimierung auf? Beim Betrachten von Bildern oder wenn diese bearbeitet und dann gespeichert werden.
Falls erstes zutrifft, dann Spina, würde ich nicht zu versuchen zu verallgemeinern. Ich benötige zur Bildbearbeitung und Betrachtung von 10 000+ Bilder (Verschlagwortung, Bewertung, etc.) auch bei 08/15 Bilddateien ein entsprechendes System. Wie immer gilt, es kommt darauf an, wer was damit macht. Und dementsprechend mag es für Dich (!) Bagatell-Aufgaben sein, für mich sind das eher wichtige Aufgaben, da ich mit meinem System arbeite. Und da hätte ich gerne, dass mehr Software-Entwickler "all" die Shader dafür benutzen.
Falls erstes zutrifft, dann Spina, würde ich nicht zu versuchen zu verallgemeinern. Ich benötige zur Bildbearbeitung und Betrachtung von 10 000+ Bilder (Verschlagwortung, Bewertung, etc.) auch bei 08/15 Bilddateien ein entsprechendes System. Wie immer gilt, es kommt darauf an, wer was damit macht. Und dementsprechend mag es für Dich (!) Bagatell-Aufgaben sein, für mich sind das eher wichtige Aufgaben, da ich mit meinem System arbeite. Und da hätte ich gerne, dass mehr Software-Entwickler "all" die Shader dafür benutzen.
Aber meinst du nicht, dass da eher Internetleitung oder Festplatte der Flaschenhals sind?
Ich denke eine x86 CPU wird beim JPEG Rendern Däumchen drehen und sich langweilen.
Also ich meine jetzt das reine Anzeigen. Keine Bildbearbeitung mit aufwendigen Effekten.
Ich denke eine x86 CPU wird beim JPEG Rendern Däumchen drehen und sich langweilen.
Also ich meine jetzt das reine Anzeigen. Keine Bildbearbeitung mit aufwendigen Effekten.
Dass Festplatten da auch ans Limit kommen, kann ich mir schon vorstellen. Aber ich sehe das, dass unterschiedliche Software unterschiedlich schnell arbeiten. Zum Beispiel relativ schnell auch viele Dateien anzeigen. Andere Programme (ich liebe z.B. gerade IMatch, da ist es langsamer) haben da Schwierigkeiten. Die Festplatten sind immer gleich. Außerdem könnte man auf Vorschaubilder-Cache verzichten, wenn man immer direkt aus den Original-Dateien rendern könnte. Gerade bei größeren Bilder (z.B. meiner Vollformat-Spiegelreflex) macht das schon etwas vom Workflow aus. Ich denke, da ist die Berechnung häufig langsamer, als das Lesen von Festplatte. Aber Fachmann bin ich da nicht und lasse mich gerne eines besseren Belehren. 
Zuletzt bearbeitet:
Complicated
Grand Admiral Special
Transcodieren ist Umwandeln. Und der Unterschied zu den i3 und i5 sind auch deutlich. Soll mir niemand erzählen das wäre keine praktische Anwendung und würde nicht Vorteile bieten die ohne HSA nicht machbar sind.
Allerdings ist es tatsächlich der JPG Decoder der HSA Fähig ist und von AMD mit dem Catalyst Treiber den Windows eigenen ´Decoder ersetzt.
http://www.extremetech.com/computin...-wait-for-the-first-true-heterogeneous-chip/5
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
ALso bei meinem Firefox-Build gabs früher nen extra JPEG-Patch, der Bilder schneller codieren sollte, da er multithreaded war. Seit ein paar Versionen gibts den nicht mehr, ich nehme an, dass der jetzt schon standardmäßig drin ist.
Wird sich schon rentiert haben bei den vielen Bildchen die in nem Browserfenster umherschwirren.
Ob HSA in dem Nutzenszenario aber jetzt soviel im Gegensatz zu multithreaded CPU-Code reißen könnte .. kA, hängt sicher auch von der Bildgröße & Anzahl ab
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Nö ich meinte es so, dass es bei den Bildchen im Browserfenster vielleicht noch keinen Unterschied macht, insbesondere, ween mans mit den Intels vergleicht.
Stimmt.
Zumal ja auch heute schon Hardware-Beschleunigung mit dabei ist (was sich auch immer dahinter verbirgt).Gut, aber zu diesem Benchmark heißt es in der Erklärung, dass eine Serie von JPEG Dateien durchgegangen wird. Nur wieviele sind es letztendlich? 1.000? 10.000? 100.000? Also ich lade manchmal Bilder bei Snapfish hoch und setze dafür die Auflösung in der Stapelverarbeitung runter, um die Upload-Zeit zu verkürzen. Das geht innerhalb weniger Sekunden auf der SSD. Also ich denke da gibt es bessere Killerapplikationen für HSA. Womöglich Videokompression in Echtzeit beim Webcam-Einsatz oder dergleichen. Obwohl es dafür wohl schon VCE gibt. Aber wenn es VCE nicht gäbe, käme HSA bestimmt ganz gelegen.
Markus Everson
Grand Admiral Special
Den Gedanken hatte ich auch schon.
WindHund
Grand Admiral Special
Naja, wenn die Arbeit in der halben Zeit erledigt wird, wäre es bei doppelt so viel Verbrauch +/- 0%
Welcher Teil der APU mehr verbraucht, sollte angesichts der Cache Größe klar sein, oder?
Markus Everson
Grand Admiral Special
Halbe Zeit bei doppeltem Verbrauch? Greifst Du da nicht ein bisschen tief? Ich denke es sollte höchstens ein drittel der Zeit bei 25% mehr Verbrauch sein!
Ein Drittel der Zeit bei 25% mehr Verbrauch sind geboten. Höre ich ein Viertel bei 25%? Kein interesse bei dem herrn mit dem MRAM-Prospekt dort hinten an der Säule? Ein Drittel zum ersten...
Scherz beiseite. Natürlich kann man sich beliebige Kombinationen aus Zeitbedarf und Leistungsaufnahme frei ausdenken und dann anfangen darüber zu spekulieren was wohl wäre wenn. Ich finde das aber ziemlich überflüssig und verweise angesichts der in der vierten(?) Generation von GPU und APU immer noch katastrophalen Leistungsaufnahme bei BD darauf das AMD schon mehr als einmal mit der Eselsmütze in der Ecke stand.
Mein Gedanke den ich nicht zu ende führte: Angesichts der immer nichtssagenderen Leistungsmessungen sollte man anfangen auf Energiemengen zu messen. Das wären dann Joule statt W wenn ich nicht irre und würde eine Summierung der Messungen der elektrischen Leistungsaufnahme über die Dauer eines Tests erfordern.
Naja, obiger Test (JPEG-Dekoder) zeigt doppelte Performance (= Halbe Zeit) durch den Einsatz von HSA. Der Verbrauch von Kaveri dürfte sich dabei höchstens verdoppeln (von CPU-Vollast auf CPU+GPU-Volllast). Ergo ist das was WindHund gesagt hat quasi worst case. Deine Art des Bieterverfahrens bei Spekulationen dürfte da fehl am Platze sein, WIndHunds Darstellung ist doch recht plausibel.Markus Everson schrieb:
Ich denke die GCN-Units arbeiten effizienter für diese Art von Aufgaben und dank HSA spart man sich einen Großteil des Verbrauchs für die Kopierarbeit. Die GPU muss ja auch nicht aktiviert werden, die ist eh aktiv, wenn der Desktop läuft, man muss sie höchstens hochtakten. (Oder deaktiviert AMD inzwischen Teile der GPU im idle?)
Zuletzt bearbeitet:
Das ist halt die Frage ob die integrierte Grafik der APU ein feingliedriges Power Gating und schnelle Umschaltzeiten zwischen Sleep States bietet.
Wenn sie in der Hinsicht hinter den x86 CPU Part zurück fällt, dann könnte ihre Nutzung sich durchaus nachteilig auf den Energiebedarf auswirken.
Das werden nur Tests zeigen können. Aber dort wo dies insbesondere eine Rolle spielt, wird man womöglich eh Kabinis antreffen und keine Kaveri.
Ergänzung: Die Rede ist natürlich abermals von wiederkehrenden Bagatell-Aufgaben und nicht von fordernder Dauerlast auf der Grafikeinheit.
Wenn sie in der Hinsicht hinter den x86 CPU Part zurück fällt, dann könnte ihre Nutzung sich durchaus nachteilig auf den Energiebedarf auswirken.
Das werden nur Tests zeigen können. Aber dort wo dies insbesondere eine Rolle spielt, wird man womöglich eh Kabinis antreffen und keine Kaveri.
Ergänzung: Die Rede ist natürlich abermals von wiederkehrenden Bagatell-Aufgaben und nicht von fordernder Dauerlast auf der Grafikeinheit.
Zuletzt bearbeitet:
LoRDxRaVeN
Grand Admiral Special
Ich weiß nicht ob hier schon mal jemand die Fläche eines Steamrollermodul gemessen/gepostet hat, aber ich poste es einfach mal. Darunter dazu einige Vergleichswerte. Die anderen Messungen sind glaube ich alle von Hans de Vries. Ein Steamrollermodul in 28nm ist also Daumen mal Pi gleich groß wie ein Bulldozermodul der ersten Generation in 32nm. Ein gewisser Fehler ist sicherlich vorhanden, da ich nur geschätzt habe, was nun zum Modul dazu gehört und was nicht, die Tendenz aber wahrscheinlich erkennbar.
LG
* 2 Kerne + 2MiB L2
LG
| Codename Architektur | Node | Fläche ohne L2/L3 Cache (mm²) | Fläche mit Cache (mm²) |
|---|---|---|---|
| Steamroller | 28nm | ~19,4 | ~31,1 inkl. 2MiB L2 |
| Bulldozer | 32nm | 18,0 | 30,9 inkl. 2MiB L2 |
| Bobcat | 40nm | 4,6 | 8,0 inkl 0,5MiB L2 |
| Jaguar | 28nm | 3,1 | |
| Sandy Bridge | 32nm | 18,4 | 29,5 inkl. 2MiB L3 |
| Llano | 32nm | 9,7 | 32,0* inkl. 2MiB L2 |
| Haswell | 22nm | 14,5 |
* 2 Kerne + 2MiB L2
Zuletzt bearbeitet:
