EliteBook 755 G2

Wir driften OT, aber ich versuch mich mal trotzdem:

Ich denke die CPU muss kein SVM "beherrschen", natürlich hat die Zugriff auch auf diesen Teil des Systemspeichers, auf den die diversen HSA Ausführungseinheiten (z.B. GPU) kohärent zugreifen können, dafür sorgen die MemoryController.

Ich würde sagen ein lokaler GPU Speicher, soweit vorhanden, wird dann prinzipiell zum local Cache der vom Treiber bereit gestellt wird. Wenn eine GPU diskret angebunden ist muss die das SVM via PCIe selbst kohärent halten, ob nun mit HW Unterstützung (ACEs bei GCN) oder nur mittels Treiber ist ja erst mal egal. Das geht dann mit jeder CPU, eine gute APU kann das aber in HW direkt, der local Cache ist nicht nötig. Das ist doch der Kern der hUMA, wie im Hotchips Vortrag erläutert (z.B. Seite 8 ).

Erst mit Carrizo war aber die HSA Standard 1.0 kompatible Funktionalität der Kohärenz und des direkten Memory Access implementiert, so dass HSA Komponenten anderer Hersteller z.B. über PCIe eingebunden werden können. D.h. nicht nur AMD kann kompatible Treiber und Anwendungen entwickeln, sondern andere Vendors sollten mit ihren HSA Komponenten und der AMD APU (CPU&GPU) auf einen gemeinsamen virtuellen Adressraum entsprechend Standard zugreifen können. Den allozierten Speicher sehe ich allerdings im System weiterhin als Teil des Systemspeichers bei der bootenden CPU angebunden.

Ich dachte die Frage war ob die CPU nun im OpenCL 2.0 Treiber auch mit der HW-Optimierung entsprechend eingebunden ist, dass diese auch für solche Anwendungen transparent nutzbar wird. Da würde ich meinen wenn Codebeispiele explizit auf APU Bedarf unter Linux hinweisen, dass das dort implementiert wurde.
Letztlich muss es aber dort die Funktionen für SVM geben, damit man bewusst eine HSA unterstütze Anwendung entwickelt. Ich nehme an dass sonst die Treiber alles nach dem alten Modell mit Copy in den GPU RAM abwickeln (HotChips Vortrag Seite 9 ). Eine HSA Komponente anderer Hersteller mit entsprechendem Treiber Support sollte dann von OpenCL 2.0 SVM Applikationen auf Carrizo Plattformen ebenso angesprochen werden können aka "the future next".

LG
E555user
 
Zuletzt bearbeitet:
Dass wir hier OT gehen, ist nicht schlimm. Außer dass vielleicht andere Interessierte die Diskussion in diesem abseitigen Winkel des Forums übersehen.

Du redest viel über HSA. Carrizo ist die erste APU mit voller HAS Unterstützung, Kaveri unterstützt HSA nicht vollständig, soweit von AMD kommuniziert.
Aber HAS ist nicht mein Thema (vielleicht Deines?), sondern OpenCL.

Ich stelle mir die Implementierung von SVM im OpenCL Treiber ungefähr so vor: Nimme ein HPC System mit mehreren dedizierten GPUs, die SVM haben.
Da sorgt der Treiber dafür, dass die Speicherbereiche an den Synchronisationspunkten kohärent gehalten werden. Der OpenCL Treiber wird das z.B. über PCIe abgleichen. Es gibt grob granulierten SVM (im OpenCL 2.0 Standard) und fein granulierten SVM (optional in OpenCL 2.0). Je feiner die Granularität ist, desto weniger wird der Treiber abgleichen müssen, also desto performanter ist er vermutlich.
Im Prinzip gilt das gleiche in einem einfachen System mit APU und zusätzlicher dGPU: der OpenCL Treiber kann SVM mit von der GPU genutztem Speicher auf der APU und Speicher auf der dGPU kohärent halten.
Jetzt aber der andere Fall nur einer APU: hier würde es sich anbieten, wenn der Treiber Speicher zwischen CPU und GPU teilen könnte. Mit einer OpenCL 2.0 Implementierung des CPU Anteils könnte der Treiber das Abgleichen der Speicherbereiche komplett überspringen, weil tatsächlich derselbe physische Speicher zwischen CPU und GPU geteilt werden kann. Allerdings beherrscht die Open CL 1.2 Implementierung des CPU Anteils keinen SVM. Dieses Feature ist neu in 2.0.
Wäre es vorhanden, könnten ganz neue Anwendungsfälle angegangen werden.
Normalerweise gibt es bei OpenCL die Herangehensweise, möglichst große Arbeitspakete der GPU (bzw. dem Accelerator, falls es keine GPU ist) zu überlassen, weil das Hin- und Herkopieren zwischen CPU-Arbeitsspeicher und dem Speicher der dGPU für einen gehörigen Overhead sorgt. Anwendungsfälle, bei denen die GPU eher Kleinkram macht, würde man erst gar nicht auf OpenCL portieren, weil dieser Overhead jeglichen Beschleunigungseffekt zunichte macht.
Im Fall einer APU muss das aber nicht so sein, weil die Übergabe zwischen CPU und GPU gar keine Arbeit mehr macht. Der OpenCL-Treiber sagt einfach: bitte schön, hier ist der Pointer. Und das wars. Kein Hin- und Herkopieren.
Damit würden ganz neue Anwendungsfälle erschlossen. Und das wären Anwendungsfälle, wo Nvidia nicht mitreden kann, weil Nvidia eben keine CPU mit iGPU hat. Intel wäre auch gelackmeiert, weil das riesige Potential der iGPU endlich erschlossen würde, und AMD da einen riesigen Vorteil hat.

Das ist der Grund, warum ich den Kopf schüttele, dass AMDs APUs OpenCL 2.0 (und damit SVM) nur auf der GPU- und nicht auf der CPU-Seite unterstützen.
HSA ist eine andere Baustelle.
MfG
 
Ja, in fast allen Punkten stimme mit Dir überein.
.....
Jetzt aber der andere Fall nur einer APU: hier würde es sich anbieten, wenn der Treiber Speicher zwischen CPU und GPU teilen könnte. Mit einer OpenCL 2.0 Implementierung des CPU Anteils könnte der Treiber das Abgleichen der Speicherbereiche komplett überspringen, weil tatsächlich derselbe physische Speicher zwischen CPU und GPU geteilt werden kann. Allerdings beherrscht die Open CL 1.2 Implementierung des CPU Anteils keinen SVM. Dieses Feature ist neu in 2.0.
...
Das sehe ich genauso. Nur denke ich dass es ein Missverständnis ist die CPU der APU könnte das SVM wie es in OpenCL 2.0 genutzt wird nicht. Es ist bei der AMD APU die hUMA, mehr braucht es nicht. Es ist nur eine Frage des Treibers ob das OpenCL Compilat entsprechend im gemeinsam genutzen Hauptspeicher alloziert und nur mit Pointern zugreift, oder der Treiber für das SVM bei Pointern noch Pinned Ram im Hauptspeicher nach GPU Ram kopiert.

SVM trifft nach meinem Verständnis heute den Kern und eigentlichen Grund der heterogenen System Architektur. Deswegen gehört das zusammen diskutiert bei APUs. Es geht doch auch bei HSA darum, dass alle auf einen gemeinsamen Datenspeicher für ausführbare Programme zugreifen. Der zweite wichtige Part ist dann das gegenseiteige Schedulung mit hoffentlich vernünftigem lokalen Context-Switching, aber das ist bei OpenCL 2.0 afaik sekundär, wurde bei Kaveri noch nicht umgesetzt bei der Carrizo GPU wohl schon.
Deswegen denke ich der Kaveri kann SVM für OpenCL 2.0, es fehlt ggf. leider noch der Treiber dazu. Bei AMD Beispielen, die nicht OpenCL 2.0 nutzten, hat AMD doch die Vorteile schon 2014 in APU-Compute Beispielen demonstriert, das geht nur mit SVM (HotChips Vortrag Seite 30 ).
 
Ich habe mir die HotChips Präsentation nochmal angesehen.
Möglicherweise hast Du recht, und es braucht kein OpenCL 2.0 auf der CPU Seite, um meine Vorstellungen umzusetzen.
Den Speicher sollte man auch so von der CPU aus allokieren und anschließend gemeinsam nutzen können mit clSVMAlloc(...).
Danke für die Diskussion mit Dir!
MfG
 
Das Beherrschen auf Seiten der CPU dürfte ein reines Softwareproblem sein.
 
Anscheinend bewegt sich HP bei meinem Elitebook außerhalb der Kaveri Spezifikation.
Oder die Pro Modelle der Kaveris, die anscheinend exklusiv für HP rausgebracht wurden, haben doch mehr als nur eine gestreckte Lieferbarkeit zu bieten.
MfG
Ich möchte nochmals zum Thema RAM etwas hinzufügen, warum auch immer bin ich jetzt eben erst über ein AMD Dokument (LINK) von Ende Mai 2015 gestolpert, bei denen diverse RAM-Riegel auf deren Kaveri Referenz Plattform durchgetestet wurden. Dort waren 1600er bei DualChannel bzw. 2 Dimms per Channel (2DPC) nur mit 1.5V erreichbar, deren damaliges Test-Szenario entspricht soweit ich beurteilen kann den maximalen Werten der BKDG das einige Monate zuvor herausgegeben wurde. Leider gibt es hierzu wohl keine aktualisierten Informationen seitens AMD. Wenn die deinen halbes Jahr älteren 755er als Referenz hergenommen hätten würde man sich bei AMD nicht so unter Wert verkaufen, ich hoffe mal das Dokument war von Mai 2014 und die hatten in 2015 nur Tippfehler korrigiert :]
LG
E555user
 
Ich habe noch eine kleine Frage an einen Elitebook-Besitzer: Kann man bei dem Gerät eine Akku-Ladeschwelle einstellen? Bei Thinkpads kann man bis unter Windows 7 dem Gerät verklickern, dass er bitte den Akku maximal bis zu XX % volllädt und erst bei XX-Y% wieder mit dem Laden anfängt.
Das hat sich langfristig als recht gute Strategie herausgestellt, um Akkualterung halbwegs erträglich zu halten. Geht das auch mit einem Elitebook, speziell der 7x5-Reihe mit AMD-APU?
 
Das ist ne gute Frage. Ich habe bis heute leider keine solche Einstellung gefunden.

Der Akku wird nach meiner Beobachtung bei ca. 93 % im Netzbetrieb erneut geladen.
 
Ich habe da keine Einstellung für gefunden, allerdings auch nie danach gesucht.
Eigentlich ist das ein Thema älterer Akkugenerationen, in denen man die Akkus unbedingt regelmäßig entladen musste, bevor man sie wieder auflud, weil sie sonst erheblich an Kapazität eingebüßt hatten. Ich habe im Hinterkopf, dass sich diese Problematik schon seit ein paar Jahren in Luft aufgelöst hat.
Genaueres würde mich allerdings auch interessieren.
MfG
 
Dieses Problem existiert in den aktuellen Treibern nicht mehr!




Ich krame mal den Thread hoch, weil ich eine Beobachtung zum Turboverhalten festhalten möchte.

Ich musste feststellen, dass der CPU-Turbo durch die Einstellungen im CCC beeinflusst wird. Stelle ich nämlich im PowerPlay-Menü, was ja eigentlich nach meinem bisherigen Verständnis nur die GPU beeinflussen sollte, "Batterielebensdauer maximieren" ein, wird dadurch effektiv der CPU-Turbo vollständig deaktiviert! Die Steamroller-Kerne laufen dann maximal nur noch mit der Standardtaktfrequenz von 2,1 GHz bei der verbauten A10 PRO-7350B R6 APU.

Ich kann nicht beschwören, dass es schon immer so war, aber dies geschieht so unter Windows 8.1 64 Bit mit Catalyst 15.9.1 Beta & 15.10 Beta definitiv.

Betrifft das auch den Turbo der GPU?
 
Ich habe da keine Einstellung für gefunden, allerdings auch nie danach gesucht.
Eigentlich ist das ein Thema älterer Akkugenerationen, in denen man die Akkus unbedingt regelmäßig entladen musste, bevor man sie wieder auflud, weil sie sonst erheblich an Kapazität eingebüßt hatten. Ich habe im Hinterkopf, dass sich diese Problematik schon seit ein paar Jahren in Luft aufgelöst hat.
Genaueres würde mich allerdings auch interessieren.MfG
Das betrifft NiMH sowie NiCd-Akkus ("Memory-Effekt"). Li-Ionen-Akkus sind diesbezüglich toleranter.
Vor Jahren gab es in der c't einen Artikel über Li-Ionen-Akku-Chemie. Demnach zersetzen sich Li-Ionen-Akkus bei hohen Temperaturen in Kombination mit sehr hohem oder sehr niedrigem Ladestand. Wobei man hohe Temperaturen durch a) hohe Außentemperaturen oder b) hohe (Ent-)Ladeströme erreicht.
Der Schlussfolgerung daraus: a) den Akku kühl zu halten. b) Ihn nach Möglichkeit nur selten komplett zur beladen. c) Ihn nach Möglichkeit niemals tiefentladen

Ich hatte vorher ein Travelmate und bei diesem in fünf Jahren drei Akkus "verbraucht". Der Akku im Thinkpad hat nach fünf-einhalb Jahren noch 2/3 der Kapazität und ein zweiter in einem zweiten Thinkpad nach 3,5 Jahren noch weit über 90 % der Kapazität. Bei den Thinkpads kann ich aber eben auch einstellen, dass der Akku an der Steckdose maximal bis z.B. 95 % aufgeladen wird und erst unter 85 % wieder anfängt zu laden. Wäre toll, dergleichen bei den Elitebooks zu finden.
 
Und lädt dann von 93 % auf 100 % auf?
Ja
Betrifft das auch den Turbo der GPU?
Kann ich gerade nicht sagen. Würde aber vermuten, dass es so ist. Spielt bei meiner Nutzung halt keine Rolle.



Generell: es handelt sich um einen Langlebigen Akku, der laut hp bei 1000 Zyklen nicht unter 80 % Kapazität (Basis ist die max. Kapazität im fabrikneuen Zustand) im geladenen Zustand kommen soll. (Angaben sin gerade aus dem Gedächtnis )
 
Wenn man die Musik gehört hat und danach nicht reif für die Klapsmühle ist, kann einen im Leben nichts mehr schockieren.
Geile Musik!
MfG
 
Der Krimson Treiber nervt. Nach jedem Booten meldet der sich, er hätte Updates. Und wenn man die durchführt, installiert er sie nicht. Wahrscheinlich weil er merkt, dass die für das Elitebook G2 dann doch nicht passen...
MfG
 
Hast Du schon mal den originalen Treiber von der hp Homepage probiert?

Bei meinem G3 hatte ich mit dem Crimson die selben Probleme. Seit ich wieder den Catalyst von hp nutze, sind die Probleme weg.

Gruß,
Ritschie
 
Ich hatte extra den neuesten Treiber drauf installiert, weil meine Frau mit ein paar Adobe Programmen OpenCL nutzt.
Davon wollte ich gerne die neueste Version haben.

Immerhin weiß ich jetzt, dass ich nicht allein bin...
Besten Dank und mfG
 
Hallo,

ich bin auf der Suche nach einem geeigneten Monitor für den externen Anschluss des Elitebooks.
Es wird wahrscheinlich eine Auflösung von WQHD (2560x1440) auf einem 27'' Display.
Hat schon mal jemand versucht, über Displayport einen WQHD Monitor anzuschließen?
Bei HP steht, dass der Displayport Anschluss Auflösungen von bis zu 3200x2000 Bildpunkten bei 60Hz unterstützt.

Muss ich darauf achten, dass der Monitor auch 60Hz unterstützt?
Ich habe gerade von Iijama die beiden ProLite Modelle XB2788QS-B1 und XUB2792QSU-B1 im Blick. Beim ersten ist eine Bildwiederholfrequenz von 60Hz beim zweiten von 70Hz angegeben.
Sollte doch egal sein, oder?

Hat jemand noch einen anderen Tipp, was zu beachten ist, oder einen konkreten Vorschlag?
Vielen Dank und mfG
 
Nachdem meine Fragen offensichtlich (und wohl berechtigterweise) als zu blöd abgetan wurden, will ich nachtragen, dass es ein Iiyama ProLite X2788QS geworden ist.
Mit einem "AMD FreeSync" Aufkleber. :D
MfG
 
Oder der Beitrag wurde übersehen oder man hatte zu wenig Zeit oder zum nötigen Zeitpunkt war es ungünstig.
 
Jedenfalls funktioniert er mit 60Hz.
Subjektiv betrachtet springt der Lüfter des Notebooks jetzt öfter mal an, allerdings ohne dabei sonderlich laut zu sein.
Ist auch kein Wunder, denn die iGPU muss jetzt ja auch zwei Bildschirme versorgen.
MfG
 
Zurück
Oben Unten