Beiträge von elmacci

Also in München wäre ich tatsächlich auch dabei - 23.02. passt auch super, genau in meiner Elternzeit

Die Werte wären bei mir nicht aussagekräftig, da ich eine Vega Frontier Edition habe. Aber grundsätzlich - wenn ich das richtig in Erinnerung habe - sollten die Werte einer Vega mit dem iMac Pro SMBIOS besser sein.

Mit iMac18,3 und deaktivierter iGPU bekommst Du auch DRM und beide Häkchen grün, aber die Vorschau funktioniert nicht ohne den Hilfsmittelkext. Mit dem iMacPro SMBIOS funktioniert auch die Vorschau ohne zusätzliche Kext. Würde ich also empfehlen.

Dass die Grafikkartr mit N/A angezeigt wird ist in der Konfiguration auf einem Hackintosh normal.

Nachteile konnte ich keine feststellen.

Frohes Fest!

Zitat von yamek

elmacci Falls das Netzteil noch da wäre würde ich es nehmen, da ich unbedingt ein neues brauche Aufgrund des Updates auf die Vega 64. Ich wäre aus München direkt schreib mir via PN falls noch da !

Du hast Post

Vielleicht sollten wir doch mal einen Sticky-Thread machen zum Thema Hacki mit Vega und Encoding/Quicksync/Drm, was meint ihr DSM2 und CMMChris

daniel14513 :

Bei Deinem Setup ist folgende Konfiguration zu empfehlen:

- SMBIOS imacPro1,1

- iGPU im BIOS aus

- Whatevergreen und Lilu

- Kein Inject Intel oder ähnliches in Clover

Damit erhältst Du zwar kein auicksync (das hat der iMacPro auch nicht in der Form), bist aber schneller unterwegs als mit der Intel UHD630 da die Vega auch beim encoding besser ist.

Ausserdem bist du dann sehr nah an einem echten Mac dran, denn:

- DRM funktioniert so in iTunes, ebenfalls Netflix und Co in safari

- Die Vorschau funktioniert ebenfalls ohne NoVpA kext oder die iGPU unter Mojave

- Sowohl h264 als auch h265 Encoding funktioniert (Check über das Programm VideoProc, 2 grüne Haken). Und das schneller als mit der UHD 630

Cheers

Zitat

Geht mir darum, dass ich Musik produziere und das bei vielen Spuren und vielen Effekten (Audio Plugins) enorm auf die CPU geht. Da ist mir natürlich jedes Stück Leistung wichtig Oder merkt man den Unterschied selbst da in der Praxis nicht?

Zur Leistung für die Musikproduktion kann ich leider keine Aussage treffen - kann mir schon vorstellen dass hier die Leistung linear skaliert, sprich: 28.000 vs. 32.000 sind nochmal ca. 15% mehr Leistung. Also auch 15% schnellere Berechnung.

Zitat

Habe mich aber auch davor eingelesen und da hieß es sogut wie immer, dass ab 2400MHz+ kaum ein signifikanter Unterschied in Performance jeglicher Art vorhanden ist. Aber anscheinend hat dein Benchmark das Gegenteil bewiesen? War der Score nur im Multicore besser, oder auch im Singlecore?

Ich weiß leider nicht mehr wie die genauen Werte waren, es war aber auf jeden Fall sowohl Single - als auch Multicore.

Zitat

P.S.

Unter macOS und einer niedrigeren Auflösung (Testweise wegen Onboard Karte) habe ich ein Ergebnis von 200 Punkten mehr im Single-Core und dementsprechend auch mehr im Multicore:

https://browser.geekbench.com/v4/cpu/11318444

Unter macOS habe ich auch grundsätzlich bessere Werte. Die 28.000 jetzt bei Dir kommen nah an den Wert ran als ich noch die 2400MHz-Riegel in Verwendung hatte.

Ein Aspekt wäre noch wichtig: Ich weiß nicht was für eine Kühlung Du hast, evtl. geht Deine CPU ins Thermal Throttling und regelt schnell runter, sprich läuft gar nicht konstant mit voller Geschwindigkeit.

Am besten mal unter Windows folgendes machen:

- Prime95 runterladen/installieren

- HWInfo64 runterladen/installieren

Dann Prime95 mal laufen lassen und die CPU-Temperatur und Taktung der Kerne im Blick behalten. Mindestens 10 Minuten, besser eine halbe Stunde.

Auf die Weise findest Du übrigens auch raus, ob Deine Übertaktung stabil ist. Wenn nicht spuckt Prime entsprechende Fehler aus.

Hm, also ehrlich gesagt sind meiner Meinung nach die Geekbench Werte bei einem OC auf 4,8 GHz eher bescheiden.

Prüfe mal bitte folgende Einstellungen im BIOS, Du hast ja auch ein ASUS Board - insofern sollten die auch ähnlich heißen bei Dir (untenstehend folgen meine Settings):

Ich fahre das System bei 4,7GHz auf allen Kernen mit einem AVX Offset von 0. Der AVX Befehlssatz wird zwar nur selten genutzt, aber für mich ist es nur ein "reines" Overclocking wenn das System auch da stable ist. Sonst könnte ich auch locker auf 5,1 GHz kommen mit bspw. einem AVX Offset von 4.

Bitte beachte das ich mit einer Loadline Calibration (LLC) von Level 5 arbeite (Level 1 ist dabei so, wie Intel es vorgesehen hat in seinen Spezifikationen - Level 7 ist das aggressivste und absolut nicht zu empfehlen).

Kurzer Exkurs zu LLC:

Nehmen wir mal an es liegen 1,3V im Idle auf der CPU an und die LLC ist so eingestellt, wie von Intel vorgesehen - sobald die CPU unter Last geht sinkt die Spannung physikalisch bedingt nach unten - das ist der sog. Vdroop. Sprich: Wenn Du die Spannung der CPU beobachtest dann ist sie im Idle bei 1,3 V, sobald Du aber einen Benchmark startest geht sie bspw. auf 1,232V runter. Wenn der Benchmark dann vorbei ist springt die Spannung aber sofort wieder nach oben.

Stell Dir das vor wie bei einem Gummiband oder Pendel - denn die Spannung springt nicht einfach nur wieder von 1,232V auf genau 1,3V, sondern eher (kurzfristig) auf 1,35V bevor sie sich wieder bei 1,3V einpendelt.
Intel gibt vor, dass es einen Vdroop geben muss - einfach um die CPU bei diesen Spannungsänderungen vor gefährlichen "Spikes" zu schützen.

Mit der LLC wird dieser Vorgabe von Intel bewusst über VRMs auf dem Mainboard entgegengewirkt.
Ziel von LLC ist es, dass die Spannung die man im BIOS einstellt auch die Spannung ist die unter Last anliegt - das macht das übertakten einfacher.
Sprich, 1,3V im BIOS sind auch 1,3V im Idle und unter Last. Das hört sich nun erstmal nach einer super Sache an. Es gibt dabei aber folgendes Problem:

Bei niedrigen Voltzahlen ist das noch vertretbar. Wenn man aber bspw. seine CPU bei 1,4V betreibt mit LLC von 6 oder 7, dann wird mit ziemlicher Sicherheit bei jedem Lastwechsel eine Spannung (teilweise nur für millisekunden) erreicht, die außerhalb der Spezifikationen von Intel liegen (bspw. 1,45V). Und das kann die CPU schrotten bzw. die Lebensdauer verringern. Zumindest in der Theorie. In der Praxis kann man das wahrscheinlich sogar ignorieren, je nachdem wie lange man vorhat die CPU zu nutzen. Aber ich persönliche fahre da lieber auf Nummer sicher.

Ist kein einfaches Thema, ich hoffe ich habe es ein wenig rüberbringen können.

Lange Rede kurzer Sinn: Ich würde eine LLC von max. 5 bei ASUS Boards einstellen. Da ist dann noch genug Puffer nach oben und unten für das Abfedern dieser Spannungspitzen.

Bei mir fahre ich übrigens 1,33 V - die aber nur im Idle anliegen und bei Last wegen des Vdroops auf 1,264V runtergehen. Sprich, mein Overclock mit 4,7GHz und AVX0 ist nicht bei 1,33V, sondern bei 1,264V (denn nur die Spannung unter Last ist relevant). Der CPU tut es nicht weh wenn die Spannung im Idle höher ist, wichtig ist die Spannung unter Last.

Sprich, ich könnte auch im BIOS 1,28V anliegen wenn ich die LLC auf bspw. 6 anhebe - aber dann sind wir wieder bei der oben genannten Thematik.

Puh, soviel wollte ich eigentlich nicht schreiben - also wenn Du bis hierhin gelesen hast dann hier noch ein paar weitere Anmerkungen:

Wenn ich mir Deinen Geekbench Score anschaue sind dort 16GB RAM aufgeführt mit der "krummen" MHz-Angabe von 1.467MHz - ich gehe mal davon aus dass Du 2.933MHz Riegel hast? Bzw. eventuell nur 1 16GB-Riegel?

Ich weise deshalb darauf hin da ich selber feststellen musste dass in meinem System mit 32GB und 2400MHz der Geekbench Score (Multicore) bei ca. 28.000 war - als ich dann 4.000MHz Riegel eingebaut habe bin ich auf ca. 32.000 im Multiscore gekommen. Der RAM hat also auch nochmal einen nicht unerheblichen Einfluss auf den Score.

Ist das XMP-Profil im BIOS bei Dir aktiviert bzw. wird der RAM mit der korrekten Geschwindigkeit angesprochen?

Ansonsten kann ich mich nur ResEdit anschließen - nicht zu sehr von den Zahlen verrückt machen. Die Differenz im synthetischen Geekbench Score merkst Du im realen Leben sowieso nicht. Ich habe auch nur übertaktet weil es geht und ich es kann - nicht weil es sein muss.

cheers

Update: Hier auch mal mein Geekbench Score mit den oben genannten Einstellungen.

Und der entsprechende Link mit dem Ergebnis:

https://browser.geekbench.com/v4/cpu/11318269

Mit der Vega, der Wasserkühlung und dem 9900K würde ich auf mind. 750 Watt gehen beim Netzteil. Die Vega kann durchaus mal 400 Watt alleine schlucken

Falls Du in der Gegend um München wohnst - ich hab hier noch ein gerade mal 2 Monate altes 1000w be quiet dark pro netzteil im schrank das ich nicht mehr brauche.

Ansonsten vorab schon die empfehlung, smbios imacpro zu wählen beim aufsetzen mit deaktivierter gpu - damit bekommst du die optimale Konfiguration mit Encoding/Decoding über die Vega.

Zur Evo würde ich zumindest zu den Lese/Schreibwerten sagen dass sie gut aussehen. IOPS kann ich leider nicht beurteilen.

Zur CPU: Das sind immer noch normale Werte für einen 8700K ohne Overclock. Bitte bedenke dass dabei die 4,7 GHz nur der Turbotakt für einen einzigen Kern sind. Und bei allen 6 Kernen max. 4,3 GHz gleichzeitig im Turbo. Im Base Clock sind es nur 3,7 GHz.

Ich habe meine CPU auf 4,7 GHz übertaktet auf allen Kernen - und erreiche ähnliche Werte wie die von Dir genannten bei 5 GHz (was wahrscheinlich daran liegt dass ich einen AVX Offset von 0 habe, also „echte“, konstante 4,7 GHz auch wenn AVX Befehle genutzt werden - und bei dem genannten OC auf 5 GHz ein AVX Offset genutzt wird und damit im benchmark wahrscheinlich real auch „nur“ 4,7 GHz erreicht werden). Ein 5 GHz OC mit AVX Offset von 0 benötigt in den meisten fällen eine Custom wakü. Der AVX befehlssatz ist sehr rechenintensiv - deshalb gibt es im bios auch die Möglichkeit, einen Offset einzustellen.

Ich empfehle beim 8700k grundsätzlich einen zumindest moderaten OC (wozu hat man sonst ein K-Modell) . Selbst wenn man im Bios nur einstellt, dass alle Kerne synchron auf bspw. 4,5 GHz laufen sollen (und das sollte jede CPU schaffen ohne gross zusätzlich gekühlt werden zu müssen), bringt das schon einen guten Performancegewinn.

So kann man es natürlich auch machen kaneske

Zitat von CMMChris

Zumindest bei mir läuft die Vorschau ohne IGPU. Wenn du die Kext dafür brauchst ist das seltsam aber auch nicht weiter schlimm. Man hat dadurch ja keine Nachteile. Zumindest sind mir keine bekannt.

Also, nochmal auf iMac Pro umgestellt, sonst keine Änderung. Und siehe da, ich brauche die NoVPAJpeg-Kext nicht mehr.

Powermanagement der CPU scheint auch zu laufen.

Insofern bin ich nun auch wieder auf iMacPro umgestiegen.

Moment, verstehe ich das richtig das bei funktionierendem encoding mit der Vega (und DRM etc.) in 10.14.2 die Vorschau funktionieren sollte (bei deaktivierter iGPU)?

In dem Fall wundert es mich ein wenig dass ich die NoVPA Kext für die Vorschau immer noch brauche obwohl alles andere funzt...?!?

Hm, okay - das ist komisch.

Nochmal kurz Gegencheck:

- macOS 10.14.2

- iGPU deaktiviert

- SMBIOS 18,3

- Nur eine GPU aktiv, keine zweite verbaut?

- Whatevergreen installiert

- In Clover alle Haken bei Intel Inject o.ä. raus (da das Whatevergreen übernimmt)

Dann sollte es eigentlich überall grün sein.

CMMChris : Kurze Frage: Benötigst Du mit SMBIOS iMac Pro die NoVPA.kext für die Vorschau (ohne iGPU) oder läuft das mit iMac Pro dann auch ohne?

Ggf. wechsel ich dann auch wieder auf iMac Pro und muss dann eben das Speedstepping Thema noch lösen.

imac 18,3 oder imac 18,2?

18,3 war gemeint.

Zitat von CMMChris

Speedstepping läuft im iMacPro1,1 SMBIOS einwandfrei mit nicht Xeon Prozessoren. Gleiches gilt für Sleep. Die Probleme die du da hattest müssen eine andere Ursache haben.

Das kann sehr gut sein - sonst hätte ich von Dir oder anderen in der Konfiguration schon eher was gelesen.

Habe ehrlich gesagt nicht weiter nachgeforscht warum das so ist.

Aber bei der Gelegenheit eine Frage: Gibt pmset -g im Terminal bei Dir auch einen Wert für "Standby" aus? das war bei mir nicht der Fall.

Meine persönliche Einschätzung - ich würde an Deiner Stelle folgende Einstellungen vornehmen:

- iGPU ausschalten

- Whatevergreen installieren

- SMBIOS 18,3

In der Konstellation habe ich funktionierendes Powermanagement / Wake / Sleep, funktionierendes Speedstepping der CPU bis runter auf 800MHz, funktionierendes DRM in iTunes und Safari sowie Encoding von h264 und h265 über die VEGA (deutlich schneller als über Quicksync).

Es kann sein dass FCPX beim h264 Export abstürzt - das kann ich leider nicht nachprüfen da ich FCPX nicht nutze.

Aber CMMChris hat auch dafür einen Workaround gefunden, hier: #60

iMac Pro würde ggf. auch bei Dir gehen - ich hatte damit aber immer das Problem dass das Speedstepping der CPU nicht funktionierte (die CPU ist nie unter 2 GHz im Idle gegangen, obwohl Plugintype=true und X86Platform geladen war).

Darüber hinaus hat mir "pmset -g" im Terminal mit dem iMacPro Bios immer eine Ausgabe angezeigt ohne die Paramter "standby", "poweroff" etc. - die eigentlich da sein sollten.

Zitat von CMMChris

DSM2 Guck, noch einer der diverse Dinge nur mit WEG auf die Vega injecten kann. Schön, dass ich nicht alleine bin.

Ich habe jetzt ehrlicherweise noch nicht probiert, WEG testweise mal abzustellen und zu schauen ob es dann funktioniert/nicht funktioniert.

Kann ich heute abend nochmal testen. War gestern nur schon zu spät um da noch große Testreihen zu fahren

Update: Habe soeben mal ohne WEG gestartet, sowohl Encoding/Decoding als auch DRM funktioniert weiterhin.

Somit war es wohl nicht WEG sondern der Inject in das PEGP-Device.

Es kann sein dass ich beim ersten Mal die DSM-Methode zur Deaktivierung des Treibers direkt in den Slot PEG1 injectet habe - und damit zwar die VEGA deaktiviert habe, aber macOS sie dennoch gesehen hat.

Der Inject eine Stufe weiter in das PEGP-Device war wohl die Lösung, unabhängig von WEG.

Danke! Ich freu mich gerade wie ein Schneekönig! Das macht das ganze „hackintoshen“ ja irgendwie aus - Probleme zu lösen die man ohne den hacki eigentlich nicht hätte

Sodele - habe heute die Zeit gefunden es mal zu testen, al6042

Leider kann ich keinen Erfolg vermelden mit Deinen Anpassungen. Danke Dir aber für Deine Mühe, immer wieder toll wie einem hier im Forum geholfen wird!

Es hat mich nicht in Ruhe gelassen und frei nach dem Motto: Schlagt mich hart und nennt mich Wanda - es läuft!

Mich hat die ganze Zeit gewundert warum die Methode, "Blödsinnswerte" zu injecten - wie von ductator beschrieben - nicht klappt.

Ich habe nochmal von vorne eine neue SSDT erstellt die in den Scope PEGP des Slots PEG1 diese DSM-Methode integriert.

Ich schwöre, das hatte ich schon einmal nach der Methode probiert und war erfolglos - aber offenbar hab ich in der Vergangenheit einen Fehler gemacht. Obwohl mich das wundert, denn auch damals war nur noch 1 VEGA in iStat sichtbar und Encode/Decode hat trotzdem nicht geklappt.

Aktuell vermute ich dass ich damals nicht zusätzlich noch WEG im Einsatz hatte - das könnte eventuell die Wurzel des Problems gewesen sein dass WEG hier nun noch "Starthilfe" gibt. Ist aber im Nachgang nun schwierig nachzuvollziehen.

Sprich: Aktuell habe ich beide Vegas am Strom, unter Windows werden beide genutzt im Crossfire, unter macOS wird die zweite automatisch per SSDT deaktiviert und ich habe h264 und h265 Encode/Decode über die VEGA sowie funktionierendes DRM und Netflix über Safari. Heureka!

Anbei mal die SSDT für den Slot PEG1, vielleicht kann das ja noch jemand brauchen (bspw. kaneske oder DSM2 )

Danke an alle Beteiligten! Ich mach mir jetzt noch ein Bier auf - cheers!

Danke Dir al6042 !!

Komme heute nicht mehr dazu die zweite Vega wieder anzustöpseln, probiere es aber morgen nach der Arbeit direkt mal aus!

Schönen Abend Dir!

Hi al6042 ,

danke fürs Melden - Ioreg und DSDT etc findest du in dem verlinkten Post Nummer 62

Wäre Klasse wenn Du da mal einen Blick drauf werfen könntest, Danke!