Posts by mitchde

    Hi, hatte mich gleich für HS entschieden und nachdem das so gut lief, Mojave am laufen.

    Unter HS (da unsupported, dosdude1 HS Patcher) hatte ich noch HFS+ wg Mojave aber auf APFS umgestellt.


    Da das MacBook Pro 2009 (MBP 5,3) ja kein ROM mit native APFS support hat - man aber trotzdem APFS boot nutzen kann da der Patcher ein APFS EFI hinzufügt welches aber beim Booten einen kurzen ähnlich verbose mode text anzeigt, habe ich APFS ROM Patcher (auch von dosdude1) verwendet um dem MBP ein um APFS Funktion erweitertes ROM zu geben. Somit bootet er APFS nun native! - also ohne den APFS Patch (ca. 2-3 Sekunden perboot mit verbose text).




    Gestern nach das Sec Update -03 drauf gemacht .. geht bisher alles.

    Für mich auch. Zudem scheint Apple sich nun wieder mehr in Richtung HW Insel (OK , eine hübsch bunte Insel ) zu entwicklen, nachdem es sich nach dem Switch PPC-Intel ja hw mäßig stark geöffnet hatte. Nebenbei wurde Dank dem PPC Intel switch auch SW seitig die Tür weit aufgemacht und die X86/Win Emulation praktisch auch Nutzbar - vom nativ booten mal ganz abgesehen. Damals war das Virsuliseren, glaube VirtualPC hies die APP nur was für geduldige User. Selbst PPC G5 im Vollausbau kamen bei VirualPC galube ich auf 300-400 MHz Pentium Speed. Das reichte für ein Steuerprogramm mehr aber net.

    Diesmal stellt sich - anders als bei vorigen Major OS Wechseln - mir deutlicherdie Frage des Zusatznutzens dieser ARM/Intel Emoi Version.

    Selbst wenns sich in den nächsten Wochen Dank Anpassungen bei OC/Clover grob laufend installieren lässt, frage ich mich was es diesmal bringen soll. Klar, das Austesten mache ich bestimmt auch, aber einsetzen?!

    Fraglich ob - das wäre zumindest für AMD Navi + kommende BIG Navi User ein Zusatznutzen - Apple das Ziel hat diese AMDs bestmöglich zu supporten oder auf lange Sicht andere Pläne hat was GPUs angeht und weiterhin nur "grobes" AMD Fixen macht.

    Je nach CPU / iGPU Typ kann das verschieden sein mit der KP. War in der Vergangenheit schon mal so wurde aber gefixt. Bei der Masse an unterschiedlichen CPUs kann sowas schon mal vorkommen - der .kext greift ja sehr HW nah aug die CPU Register zu was Bugs im Code viel schwerwiegender macht (sofort KP) als wenns Bugs in der GUI (z.B. "nur" Anzeige der Werte fehlerhaft) wären. Geduld ;)

    Rob hat die 5600M auch mal getestet (im Vergleich zu einer eGPU 5700XT , Anmerkung: eGPU vs nativ im PCIe Slot kostet 5-20% Speed, je nach Anwendung)


    Wieder sieht man mal das Geekbench bedingt tauglich ist valide Aussagen zur compute speed zu geben :)

    Gut, das es weitere - eher realen Welt entsprechenden - Testmöglichkeiten gibt.

    Geekbench Wert vs DaVinci Resolve 16.2.2 , Luxmark etc. Werte bilden eher die Realität ab.


    Trotz allem ist die 5600M für manche sicher gut welche statt einer MacbookPro + eGPU 570/580 Lösung (welche nicht schneller wäre) auch ohne eGPU ansprechende Speed zu haben.


    https://barefeats.com/16-inch-…-5600M-versus-5700XT.html


    Apple Info zum Thema Bandwidth - Unterschiede bei Speed je nachdem ob das Display direkt an der eGPU hängt oder trotz eGPU nur das interne Display genutzt wird = mehr Speedverluste über TB3.

    https://developer.apple.com/do…derstanding_gpu_bandwidth


    Was bei Rob bei den INTERNAL / EXTERNAL Werten auch mehr oder weniger stark (je nach App) sichtbar wird.


    ... das wird noch schlimmer werden - garantiert!

    Trotz den BUGs erweitert Apple die AMD GPU Flotte im MacBook Pro ;)

    - AMD Radeon Pro 5600M mit 8 GB HBM2-Grafikspeicher

    Ein MacBook Pro 16" mit Radeon Pro 5600M kostet somit mindestens 3699 Euro. (Quelle MTN)

    Apple zeigt WAS GEHT?!



    Nichts ist unmöööööglich .... Apple :)



    Nun das etwas OT hier nun auch mal Sinn macht, kommt weil das Apple bisher nicht gut hinbekommen hat.

    Anders als in früheren OS X Versionen gibts bei einer x.6 Beta halt noch Sachen die nicht gut laufen. Bei einer x.1 oder .2 Beta würde wohl keiner Meckern!

    Und richtigen Erfolg hat Metal nur bei iOS Developernm, deutlich weniger bei MacOS/Win/Linux Firmen, welche nicht ausschließlich für OS X entwickeln sondern auch Win+Linux bedienen. Ist auch kein Wunder, das Metal nirgendwo anders (außer bei iOS) eine wichtige Rolle spielt.

    Jupp, wobei es ja noch offen ist, ob Apple in Zukunft ein geschlosseneres HW System bevorzugt oder offen bleibt.

    Geht Apple wieder zurück in die PPC Zeit? Ein was HW Erweiterungen angeht wesentlich geschlosseneres System bzw. von Apple kontrolliertes System gegenüber heute. Dieser Weg würde über ARM/Apple CPUs + "ausgewählten" non Apple GPUs führen ober bleibts so wie jetzt? Selbst wenn auf diesem ARM/AppleCPU/GPU Weg erstmal die non mobil / non allinone Macs von Apple/ARM CPUs /+ GPus) = MacPros verschont bleiben würden, wäre das ein Zeichen "back to Apple 90er Jahre" wie es mal zu PPC Zeiten war.

    Naja, vor dem Hintergrund was CMMChris schildert, sind zwei Sachen auch traurig:

    1. Wenn im Winter 2020 die AMD BigNavis erscheinen, geht das Problem - zumindest am Hackintosh & Mac USer mit eGPU bestimmt weiter! Die werden sicher rudimentär "laufen" aber genauso sicher wieder Probleme in eGPU und am Hack, MacPro machen.

    2. Das Nvidia von Apple nicht mehr angeguckt wird und/oder auch Nvidia nicht mehr gut mit Apple kann ist übel. Da man nun allein auf AMD von der HW und Apple Devs - der Apple AMD Treibermist - angewiesen ist.

    Schade da ab Pascal und was nun noch alles kommt durchaus eine Alternative zu AMD gehabt hätte. So ganz überzeugt bin ich nicht von den RX 5xxxx Karten (unter OS X!!) - schauen wir mal was die BigNavis so mit OS X bringen. Denn vom gpu compute her sind die Zeiten seit Pascal vorbei wo AMD stets besser war (egal ob Win/Mac).

    Beide, AMD und Nvidia bringen im Winter bzw. Herbst neue Modelle raus - wird sicher interessant.

    Jedoch hat die freie Wahl und vollen Nutzen wohl nur der Win Nutzer. Sogar der Linux USer hat inzwischen recht brauchbare Treiber vermute ich mal. Der Hack/Mac User freut sich auch über neue features + Speed aber ärgert sich in der Praxis weiter über Probs bis zu den KPs.

    Mag sein, dass Apple mit der eGPU Sache - unpassend zu deren AllInOne Gen - die Türe für "Alien GPUs " zu weit aufgemacht hat und das weder in den Griff bekommen kann noch wirklich will.

    Ich denke das Apple eGPU Support auch bald einstellen wird oder wenn dann nur aus einer Hand, also eine Apple Blackbox eGPU verkauft - wo dann das meiste geht - zumindest KPs selten sind ;)

    Apple kann einfach nur gut mit HW die sie selbst einkauft und am liebsten innen (fest) verbaut.

    Was die Umsatzanteile von Apple bei non Allinone HW angeht bestht auch für Apple kein Grund zur Panik wg. AMD Alien GPU Karten Kundenärger. Die MacPros werden im ganz niedrigen einstelligen Umsatzbereich liegen - trotz deren hoher Preise . Und eGPU User gibts, aber wohl nicht genug damit Apple da ein wirkliches Problem hätte.

    Ich seh da echt bissle schwarz was die Happyness mit OS X nonallinone angeht.

    Hi, ich habe das selbe Mainboard, bisher nur Clover im Einsatz. Dher habe ich mir erlaubt das EFI vom griven - DANKE - mal als meinen ersten OC Test zu nutzen. HAbe die WLAN/Bluetooth Sachen rausgenommen da ich diese nicht hinzugefügt habe.

    LAN ging nicht, ich vermute ich muss den AtherosL1cEthernet.kext verwenden statt dem im EFI (..E2200.kext).

    Ansonsten war der erste Boot problemlos und flink.

    Fragen:

    Wenn ich Fakesmc (samt seinen Plugins für CPU,...) statt Virtualsmc nutzen möchte.

    Das mit den .kext is mir klar aber bei Clover habe ich noch ein SMCHelper.efi welches ja irgendwie auch zu OC Drivers muss. Versuche das gleich mal zu machen wie ich denke das es sein müsste.

    Was ich mit OC feststelle ist, dass die CPU nicht ganz optimal performt.

    Bei Clover mit den generate PC/C States ca. 15% mehr Speed.


    Clover generate P States (OC nur ca. 760 Single Core)

    Ich habe zwar unter Clover auch schon mit der ssdt (erzeugt für meine 3570K mit Turbo 3900), jedoch auch dort war Clovers generate Pstates einfach besser. Speed etwas höher ohne Mehrverbrauch an Watt.


    Gibt es diese generate PStates Funktion auch in OC?

    Kleiner Hinweis für Polaris User (ich habe eine RX 460(=560).

    RAdeonboost in Version 1.6 läuft prima mit 10.15.5.

    Was ich jedoch festgestellt habe ist, dass sich AGPM bei mir (..EF) negativ auf die Speed auswirkt, sprich reprodizierbar weniger Speed in Luxmark sowie anderen Benches (bis auf Geekbench) habe wenn ich AGPM nutze. Auch braucht sie im Desktop Modus mit AGPM etwas mehr Watt, ca. 22 Watt statt ca. 17 Watt. Letzeres macht aber nix :) Beides sehr gute, niedrige Werte bei nur einem Moni.

    Bei Geekbench machts bei der Speed keinen Unterschied AGPM an ist oder nicht. Komisch... GB ist speziell ;)

    Mit Radeonboost um die 24000 (Metal) mit/ohne AGPM ist egal, ohne Radeonboost nur um die 16000 - guter Boost für ne RX 460er!!!



    Mit AGPM:


    Leerlauf



    Ohne AGPM:


    Leerlauf


    Daher habe ich meine ..EF wieder aus dem AGPM rausgenommen.




    PS: Die max. Watt während den Benches war gleich hoch, um die 100 Watt egal ob AGPM oder nicht. Die max. Werte sind laut Chris jedoch oft viel zu hoch angegeben (je nach GPU Typ), jedoch relativ gesehen (nicht Absolutwerte) trotzdem gut bei "Tunings" zu vergleichen.


    Insofern für Radeonboost USer mit RX 4/5xx Polaris (RX 460/560 device ID ..EF User müsen die .plist anpassen, ..DF nach ..EF ändern, klar) schon gut zumindest AGPM an/aus mal mit Benches jenseits GB zu prüfen ob es da eine spürbare Änderung (Speedverlust mit AGPM) gibt oder nicht.

    Was evtl. sein könnte - Unterschiede durch SMBIOS - ist, das er indirekt zustande kommt. Sprich nicht direkt die GPU Leistung verändert wird (bleibt gleich) sondern die CPU , welche natürlich gerade bei so eher realen GPU Benches wie Valley mit hineinspielt durch ein anderes SMBIOS einen leicht höheren Benchwert erzielt. Evtl. leicht anderes Stepping der CPU CLK je nach CPU Last ---die max. CPU CLK wird jedoch gleich bleiben.

    Magst du mir das evtl via PN erläutern?

    Lg

    Nun im BIOS der Karte ist die Lüftersteuerung "verankert" also die Lüfterkurve usw. genauso wie ich die Clocks für GPU + VRAM sowie Volt GPU/VRAM. Mn kann dies mit einem BIOS Editor (Polaris Bios Editor) ansehen und auch ändern und das geänderte mit AMDWinflash zurück flashen.

    Das ganze funktioniert aber nur per flashen, keine Wirkung wenn man das geänderte VBIOS mit Clover als File nutzt.

    Da nicht unkompliziert und auch AMD Win Treiber meckern (erkennen das dsa VBIOS verändert wurde) lohnt das zumindest weniger bei einem Dual Boot Hackintosh.

    Hi, zuerst wäre es wichtig welche HW Bescheunigung du meinst, die generelle OpenGL. Metal, OpenCL bzw. Ünterstützung voller Auflösung (nicht VGA Mode wenn AMD tReiber nicht geladen werden) ODER wahrscheinlich die HW ENC / DEC Beschleunigung der AMD für Videoencoding - decoding auf der AMD statt iGPU.

    Falls letzteres, AMD HW Videobeschleunigung, wie hast du festgestellt, dass diese nicht aktiv / nicht genutzt wird (beim encodieren)?

    PS: Mein Tools AMD GPU Menue zeigt dir das (HW Enc Y/N , live bei Encodig Tasks) an, neben weiteren GPU Performancewerten. Ansonsten Videoproc , Einstellungen Video


    Was bei dir "reinspucken" kann ist die gleichzeitige Nutzung von WEG und Inject ATI (in Clover) sowie

    bei ACPI der noch aktive Rename PEGP0 to GFX0.

    Würde das mal - am besten per USB Stick - ausprobieren ATI Inject und Rename ... zu deaktivieren.


    PS: Du nutzt ja ein SMBIOS was keine iGPU hat . schon mal gut, jedoch hast du auch im MB BIOS die iGPU disabled? Das ist wichtig. Ansonsten wird in der Regel die iGPU (trotz AMD aktiv) für HW Enc/Dec genutzt.


    Autoconfig scheint bei Polaris leider nicht zu funktionieren.

    Die Werte wurden auch sicher unter GFX0 übernommen, die RX460 bleibt aber trotzdem bei 600 MHz.

    CMMChris Guck am besten nochmal genau bei meinen Properties, bevor wir das zu den Akten legen.

    Hi, ich habe ja auch eine RX 460. Jedoch war das bei der sowohl unter Mojave wie Catalina - ohne Boost Sachen - so, dass die immer normal durchgetaktet hat, also Idle 300 MHZ CPU+VRAM, bis zum Max Clk GPU+VRAM hoch. Natürlich mit CLKs dazwischen.

    Ich vermute, dass hier das BIOS der Karte wohl eine Rolle spielt - mag sein auch eine Rolle bei Rucklern nach aufwachen. Auch dieses Problem hatte meine RX 460 nicht.

    Was jedoch wohl bei uns (meist) gleich ist, ist dass ich mit boost oder PP,PP_..Firmware... 1 auch spürbar höhere Geekbenchwerte bekommen (nicht Thread Thema, klar). PS: Gucke ich mir die CLKs beim Geekbench mit und ohne boost Sachen an, sehe ich keinen Unterschied. Die Taktunk geht gleich weit hoch, nebenbei bemerkt.

    Das mit den Rucklern gabs es schon mal vor längerer Zeit - Ursache war da in der Tat, dass die GPU im IDLE Clk Modus (der ist meist zw. 300 und 600 MHz) verharrte, was man damals - die GPUS waren weit langsamer - auch schon beim reinen Desktop (Scrollen, Fenster verschieben etc.) leicht durch ruckeln gemerkt hat.

    Frage zu

    Device Properties PP,PP_EnableLoadFalconSmcFirmware 0x1

    Valley Metrics: Core Clock 1940-1256 MHz, 280 Watt (relativer Murkswert) , Temp GPU Avg 75 °C

    Ist in diesem Fall nur das device property PP,PP_EnableLoadFalconSmcFirmware 0x1 in Clover eingfügt und sonst nichts (also auch kein boost.kext)?

    Ich vermute auch, das relativ wenig PP oder CFG hinzugefügt bzw. geändert werden müssen damit der Effekt (bei dir Probs nach Wake) eintritt. Zumindest unsere Polaris GPUs brauchen recht wenig denke ich. Geekbench Wert nur mit diesem PP,PP_EnableLoadFalconSmcFirmware 0x1 auch schon höher oder muss da mehr hinzu um Geekbench boost zu erreichen?

    Sehr interessant das mit der Power Sache. Denn die GPU wird (zumindest unter Win) runtergetaktet wenn ein Powerlimit (auch im BIOS hinterlegt) überschritten wird - und nicht nur wenn GPU Temp (evtl. auch zusätzlich Hotspots überwacht bei ganz neuen GPUs) zu hoch wird.

    Jedoch wird die Powersache gerade beim Geekbench OpenCL(Metal kaum ein Grund für den Boost sein, da Geekbench wesentlich weniger Watts erzeugt wie zB. Luxmark ode Games. Auch wenn wie Chris sagt die Watt Werte des AMD Treibers zu hoch sind, sieht man im Vergleich Geekbench und Luxmak wie Geekbench viel weniger Last % / Watt und (zudem nur sehr kurzzeitig)auf die GPU bingt wie Luxmark oder Games.

    Bei Geekbench muss die Wirkung der boost Sache also entweder an einer erhöhten Speicherbandbreite liegen oder evtl. auch dass Geekbench, anders als andere Apps/Benches gewisse Codeoptimierungen je nach den ATY properties durchführt und die Benches deshalb mit boost parameter beschleunigt werden.

    Allein bessere Speicherbandbreite müsste auch bei Luxmark & Co, wenn nicht mit 30% (boot meiner RX 30% bei Geekbench OpenCL! , was ich viel finde) dann wenigstens mit 5-10% durchschlagen. Sind aber halt bei allen boost Usern bei Luxmark um 0%.