Kaveri - der Trinity Nachfolger
- Ersteller FredD
- Erstellt am
Das mit der A8-7600 Verschiebung scheint die Runde zu machen:
http://www.hartware.de/news_60456.html
http://www.hartware.de/news_60456.html
Eine Verschiebung des Produktes ist es nicht, eher eine Verschiebung der Priorität für die Leistungsschwächeren Kaveri, hin zu der Verteilung, welche sie bei Llano hatten (OEM first, channel last).
FredD
Gesperrt
- Mitglied seit
- 25.01.2011
- Beiträge
- 2.472
- Renomée
- 43
[Aus dem anderen Spekulations-Thread, hier thematisch passender]
Keine special function unit. Sondern ein nettes Beispiel für die Performance und Vielseitigkeit von HSA. Im Idealfall kann das dem Nutzer schon einiges an Zeit ersparen, z.B. Batch-Konvertierung in Adobe Photoshop. Bei einzelnen Bildern von kleinen Dimensionen dürfte der Vorteil eher bescheiden ausfallen.
Keine special function unit. Sondern ein nettes Beispiel für die Performance und Vielseitigkeit von HSA. Im Idealfall kann das dem Nutzer schon einiges an Zeit ersparen, z.B. Batch-Konvertierung in Adobe Photoshop. Bei einzelnen Bildern von kleinen Dimensionen dürfte der Vorteil eher bescheiden ausfallen.
mariahellwig
Grand Admiral Special
Jupp. Es muss nicht immer die SD-Karte der Digitalkamera sein. Da reicht schon eine bildreich bestückte Internetseite.
LoRDxRaVeN
Grand Admiral Special
Ist das so? Wo ist da eine durchschnittliche CPU nicht schnell genug, also dass man mit dem HSA Decoder im Browser Performancevorteile hätte?
Shadowtrooper
Grand Admiral Special
Nenn mal ein Beispiel. Für eine ordentlich erstellte Internetseite ist selbst ein olles iPad (ab gen 2) schnell genug...
Zuletzt bearbeitet:
FredD
Gesperrt
- Mitglied seit
- 25.01.2011
- Beiträge
- 2.472
- Renomée
- 43
Am Java-Code scheiden sich dann aber die Geister. Wenn man mal gut 10 bis 30 Tabs offen hat, einige mit rechenaufwändigem Java bzw. Flash, und oben drauf für jede Seite Tracker- und Adblocker, zwingt man mit so einem Surf-Verhalten selbst aktuelle CPUs in die Knie. Solange hier nicht auch mit HSA abgeholfen werden kann, rückt das leider schon wieder zu sehr vom Thema ab. Ich stimme jedoch soweit zu: beim Web-Browsen dürfte das JPEG Dekodieren bestenfalls einen Nebenschauplatz darstellen.
Immer dann wenn du größere Bilder und ggf. mehrere davon in Batch/Reihe bearbeiten möchtest. Die Intensivierung der Zusammenarbeit mit Adobe (v.a. Photoshop, Flash, Premiere) erscheint da schon obligatorisch.
Dr@
Grand Admiral Special
Kabini nutzt laut AMD OpenCL und Kaveri angeblich HSA. Nachprüfen kann ich das nicht.
Kabini kann kein HSA.
Kabini kann kein HSA.
FredD
Gesperrt
- Mitglied seit
- 25.01.2011
- Beiträge
- 2.472
- Renomée
- 43
Gute Frage, ob der JPEG-Decoder für HSA spezifiziert/optimiert ist, oder allg. GPGPU fähig. Nach Bauchgefühl würde ich sagen, dass eine HSA-Optimierung des JPEG-Dekoders in Beispielfällen weit höhere Performance-Vorteile zeigen würde.
Woerns
Grand Admiral Special
- Mitglied seit
- 05.02.2003
- Beiträge
- 2.983
- Renomée
- 232
Von OpenGL her kenne ich verschiedene Ausführungsarten von nativem OpenGL Code je nachdem, was vorhanden, bzw. installiert ist:
Dedizierte Grafik mitsamt OpenGL Treiber: schnelle Ausführung,
einfache Grafik mit OpenGL Treiber: halt langsamer,
kein OpenGL Treiber: grottenlahm aber lauffähig, weil die CPU das native OpenGL ausführt.
Bei OpenCL wird es möglicherweise ähnlich sein. Vermutlich wird auf Kaveri JPEG auch per OpenCL dekodiert, aber der OpenCL Treiber nutzt bessere Codepfade, die sich z.B. die Kopierarbeit wegen HSA sparen können.
Und möglicherweise gibt es noch einen Unterschied zwischen OpenCL ohne GPGPU und erst gar keiner Verwendung des OpenCL Treibers. Dann wäre die Frage, wie der Enthusiast-Default in obiger Grafik zu verstehen ist.
MfG
Dedizierte Grafik mitsamt OpenGL Treiber: schnelle Ausführung,
einfache Grafik mit OpenGL Treiber: halt langsamer,
kein OpenGL Treiber: grottenlahm aber lauffähig, weil die CPU das native OpenGL ausführt.
Bei OpenCL wird es möglicherweise ähnlich sein. Vermutlich wird auf Kaveri JPEG auch per OpenCL dekodiert, aber der OpenCL Treiber nutzt bessere Codepfade, die sich z.B. die Kopierarbeit wegen HSA sparen können.
Und möglicherweise gibt es noch einen Unterschied zwischen OpenCL ohne GPGPU und erst gar keiner Verwendung des OpenCL Treibers. Dann wäre die Frage, wie der Enthusiast-Default in obiger Grafik zu verstehen ist.
MfG
mariahellwig
Grand Admiral Special
So war das nicht gemeint. Die meisten Seiten sind schon auf Grund der beschränkten Bandbreite so konzipiert.
Aber wenn du z.B. unter images.google.com nach Bildern suchst, was ich persönlich häufig mache, und als Filter "groß" verwendest, stellt man schnell fest dass der Bildaufbau nicht "sofort" erledigt ist, wenn man sich die Bilder als Vollbild ansehe. Bei geringer Bandbreite kann man sich das natürlich sparen.
Es hat auch niemand behauptet, das dies das absolute Killerfeature ist, aber sinnlos ist es nicht. Alternativ würde ich dir mal FastPictureViewer empfehlen, welcher DirectX statt OpenCL nutzt. Hat man sich erst mal an die Geschwindigkeit gewöhnt, möchte man sie nicht mehr missen.
Ich schließe mich der Schlagersängerin an. Noch ein Beispiel aus meinem Alltag (hatte ich oben glaub ich schon geschrieben): Die Speicherkarte von der Spiegelreflex kopiere ich erstmal komplett auf die SSD, wo die Bilder sortiert werden. Wenn du große Bilder hast und den Ordner zum 1. Mal öffnest, müssen alle Thumbnails erstellt werden. Und wenn das jetzt doppelt so schnell geht, ist das doch nett. Wie Maria schon sagte kein Killerfeature, weshalb ich mir unbedingt genau diese APU kaufe, aber man nimmt den Vorteil doch gerne mit. Gerade weil es keine zusätzliche Hardware erfordert und auf allen (jetzigen und zukünftigen) APUs funktioniert. Wenn noch mehr solcher netten Features dazukommen, z. B. Videokonvertierung, wird daraus in der Summe ein Paket, weshalb man dann doch zu einer APU greift, falls die anderen Gründe noch nicht überzeugend genug waren.
Was außer HSA-Videokonvertierung noch dringend fehlt ist die Nachrüstung von Multicore-Support in allen Packern out of the box. Für private Nutzung vielleicht nicht so dringend aber auf dem Server erstelle ich schon Archive mit einigen Gigabytes. Es gibt Projekte wie threadzip und pbzip2, die ich mir noch ausführlich ansehen muss. Bei einem Packer bin ich erstmal konservativ.
Zuletzt bearbeitet:
LoRDxRaVeN
Grand Admiral Special
Ich hatte ja die selbe Frage gestellt und es ursprünglich auch so aufgefasst, wie Shadowtrooper. Das es durchaus einige Anwendungsfälle gibt, wo dies tatsächlich spürbare Vorteile bringt, war zumindest mir schon klar, aber die Frage beschränkte sich eigentlich auf den Browser bzw. klassischen Websites. Aber die Sache ist ja nun geklärt.
Bzgl. deinem Thumbnail Bespiel stellt sich mir aber die Frage, ab da nun tatsächlich die CPU der Flaschenhals ist, oder immer noch die SDD.
LG
Bzgl. deinem Thumbnail Bespiel stellt sich mir aber die Frage, ab da nun tatsächlich die CPU der Flaschenhals ist, oder immer noch die SDD.
LG
Crashtest
Redaktion
☆☆☆☆☆☆
Das sind die Ax-APUs.
Aber interessant: Es wird Opterons als reine CPU ohne GPU geben.
Dr@
Grand Admiral Special
Das sind schlicht Kaveri mit deaktivierter/defekter iGPU.
Wahrscheinlich schlicht "R series", die haben mit mobile ja auch mehr gemein als mit Desktops, was Sockel und TDP angeht.
BavarianRealist
Grand Admiral Special
- Mitglied seit
- 06.02.2010
- Beiträge
- 3.358
- Renomée
- 80
Langsam wird es klar, warum wir nichts von den Notebook-Versionen von Kaveri hören: die braucht vermutlich niemand mehr, wenn Beema im Sub-25Watt-Bereich schon an die Leistung eines 35Watt-Kaveri im CPU-Bereich ran kommt: hier ein Link von Wörns zu einem Lenovo-Notebook mit Beema, der 4x2,4Ghz haben soll. Welchen Takt bräuchte Kaveri, um da mithalten zu können? Zudem ist Beema bereits ein SoC und Kaveri benötigt noch eine Southbridge.
Kaveri scheint mir eine noch schlimmere Pleite zu werden, als Llano. Im Notebook wird Kaveri keine Rolle mehr spielen und für den Desktop wird man nicht viele Stücke benötigen. Eine Version von Beema mit 6 Cores, Dualchannel-Ram und mehr GPU wäre wohl viel interessanter als ein Notebook-Kaveri oder -Carizzo.
Kaveri scheint mir eine noch schlimmere Pleite zu werden, als Llano. Im Notebook wird Kaveri keine Rolle mehr spielen und für den Desktop wird man nicht viele Stücke benötigen. Eine Version von Beema mit 6 Cores, Dualchannel-Ram und mehr GPU wäre wohl viel interessanter als ein Notebook-Kaveri oder -Carizzo.
Zuletzt bearbeitet:
... kein Beema mehr.
LoRDxRaVeN
Grand Admiral Special
Daumen mal Pi 1,8 bis 2,0GHz bei zwei Modulen. Bzgl. der Energieeffizenz würde es aber, trotz fehlender Southbridge, keine nennenswerten Vorteile für Beema geben. Dazu kann man den A8-5545M mit 19W TDP zum Vergleich heranziehen. Gleichzeitig würde der Kaveri, bei dementsprechend aktiven Shadern und Speicherbandbreite, Beema in der Grafikleistung aber gut zurücklassen.
Zuletzt bearbeitet:
Der Linux-Kernel 3.15 bringt ein Interface für den VCE2 (video encoder in Kaveri) mit. Ein dazu passender Encoder-Treiber hält in Mesa 10.2 Einzug, ist also auch Standard. Dieser Treiber wird vom Framework GStreamer über OpenMAX angesprochen. Es geht also weiter voran in Sachen Linux-Support. Schön zu sehen, als das OSS-Lab in Dresden geschlossen wurde hatte ich schon Befürchtungen.
Effe
Redaktion
☆☆☆☆☆☆
Test des A10-7850K bei Technic3d :http://www.technic3d.com/review/cpu-s/1648-amd-a10-7850k-kaveri-apu-im-test/1.htm
