R9 390 im Betrieb mit macOS 10.13.4 nich möglich?

  • Hallo, guten Tag und Frohe Ostern liebes Forum :) ,


    ich habe leider das Problem, dass meine AMD Sapphire R9 390 Nitro unter 10.13.4 nich mehr funktionieren will.
    Dies ist der Grund warum ich mit der Time Machine wieder zurück auf 10.13.3 bin.


    Vorher war es immer möglich nach jedem größeren Update durch eine minimale Kext Änderung der AMD Kexte die
    Grafikkarte wieder ans laufen zu kriegen wie hier von @ralf. gut beschrieben wurde: R9 390 Unter Sierra


    Dies will jetzt nicht mehr ganz funktionieren. Die Grafikbugs bleiben und je nachdem wird der Bildschirm nach einem
    Neustart komplett grün und lässt sich erst mit einer Änderung der Auflösung in den Monitor Einstellung wieder fixen.


    Was ich bereits versucht hab: Whatevergreen zu updaten & Whatevergreen komplett wegzulassen.
    Beides hat nicht den gewünschten Erfolg erzielt. Jetzt weiß ich leider grade nicht mehr wirklich weiter :/


    Ich hoffe ihr habt eine Lösung für mich parat dies wieder zu reparieren.



    Ich bedank mich vorab schon mal für eure Antworten und wünsch euch einen schönen Ostermontag :)

  • Bin im selben Boot.


    Mein Verdacht ist, dass der Radeon Framebuffer bis 10.13.3 alle DeviceIDs genommen hat und jetzt nur noch von Apple wirklich verbaute akzeptiert.


    Hm ...


    Erinnere mich gerade, dass zwar im DPCI Manager Radeon FB steht, im Registry Explorer aber Exmoor angezeigt wurde.


    Werde mal versuchen Exmoor zu patchen.


    Vielleicht liegt es an der Port Erkennung und nicht an der DeviceId


    Update:


    Liegt nicht an den Connectoren im FB. Wohl eher in die Richtung der INI-Methode.


    Dies wird wohl der Grund sein, wieso die "normalen" AMD Karten jetzt OOB initialisiert werden. Und dies wird sich mit der bisherigen DSDT/CloverDeInit spießen.

  • UPDAAAAATE:


    Es funktioniert!



    Erster Schritt:


    Wieder Whatevergreen zu den Kexten im Efi Kext-Ordner.


    Die /System/Library/Extensions/AMD8000Controller.kext/Contents/Info.plist braucht nun ZWEIMAL die DeviceID hinzugefügt. Und dann noch in die AMDRadeonX4000 und AMDRadeonX4000HW die ID rein.



    Zweiter Schritt:


    KEINE DSDT erst einmal.


    Und dann "Tadaaa":


    Er bootet durch und hat Beschleunigung.


    Die nächste Überraschung: USB3 läuft und der HDMI-Audio-Teil der GPU wird erkannt.


    Geekbench zeigt mir OpenCL-Werte zwischen 120000 und 123000 an.


    Momentan keine Audio-Ausgabe. Damit spiele ich mich dann jetzt einmal -> neue minimalistische DSDT.



    UPDATE2:


    hahahahaha :D


    :feuerwerk:


    DP-AUDIO geht!


    Scheinbar wurde einiges geändert, dass sogar das bisher "unmögliche" HDMI-/DP-Audio bei den R9 390 funktioniert :D


    Jetzt muss ich nur wieder das Progrämmchen finden, mit dem man die HDMI-/DP-Laustärke regeln kann ....


    Irgendetwas Buntes war es.


    Update3:


    SoundFlowerBed


    http://tarikfayad.com/enable-m…isplayport-audio-devices/

  • Unglaublich, Hammer!


    Du hast sie zum laufen gekriegt :)
    Wenn ich jetzt richtig verstehe, muss ab jetzt immer die AMDController8000, AMDRadeonX4000 und jetzt zusätzlich die AMDRadeonX4000HW anpassen sehe ich das richtig?


    Außerdem weiterhin Radeon in den Settings benutzten oder Baladi? Probleme was den Ton anging hatte ich bisher nicht. Ton funktionierte bei mir schon immer Problemlos über HDMI.

  • @THack87


    Bezüglich der DeviceIDs liegst du genau richtig. Bei Clover kannst du die doch über die config.plist einbauen, oder?



    HDMI-/DP-Audio war ein Missverständnis meinerseits.


    Bin beim Wechsel zurück auf meine ProduktivInstallation mit 10.13.3 darauf gekommen, dass es an der Kombi SSDT-2.aml + Whatevergreen - DSDT liegen muss, da dort auch der Codec jetzt angezeigt wurde und DP-Audio nutzbar war.
    In den Anleitungsthreads bei den Verrückten wird immer noch darauf hingewiesen, dass es für R9 390er keine Lösung gäbe.


    Ich benutze ja Ozmosis und habe dort AtiInjection disabled.


    Meines Erachtens liegt es an der SSDT-2.aml von oben. Probiere mal aus, ob du es damit auch schaffst.


    Viel Erfolg!

  • Ich muss sagen hat sofort bei mir funktioniert!!!! :))
    Hab nur den neuen Kext dort mit umgeändert und habe keine Probleme mehr.


    Empfiehlt sich die SSDT-2 einzuspielen?

  • Sieht gut aus von dem was ich sehe:


  • Hallo,ich habe auch eine Radeon R9 390 von Gigabyte habe ich das richtig gelesen das die bei euch unter High Sierra 10.13.4 jetzt läuft ?Ich habe es auch schon probiert aber es klappt leider nicht kann mir da jemand von euch helfen? Was mache ich mit dem Quellcode ? Wie wird das eingebunden? Ich nutze Clover ! Gruß Michael

  • @griven hat auch eine R9 390 (X) laufen, und ich habe eine R9 270X laufen. Entweder mit Whatevergreen und Lilu in der EFI oder bei mir zumindest OOB ohne irgendwelche Injects in Clover unter Grafik.


    Gruß Mocca55

    ———>Kein Support über Privatnachrichten<———

  • Hi ok ich versuche das mal ohne die Injects in Clover habe allerdings die 390 ohne X! Whatevergreen und Lilu habe ich im Other Ordner von Clover! Werde ich später mal testen! Wäre aber über jeden Tipp dankbar! Habt ihr vielleicht ne Beispiel config.plist für mich ? Gruß M



    Klappt leider nicht bei mir! Keine GPU Beschleunigung kann mir jemand helfen ?

    Einmal editiert, zuletzt von SEQ303 ()

  • Also... ich hatte ja schonmal den Versuch gestartet auf 10.13 zu updaten aber die r9 390 wollte nicht so richtig (Keine Acceleration). Jetzt sehe ich hier das sie ja bei Einigen gut läuft, daher steige ich wieder ein :)
    Status:
    Whatevergreen und Lilu sind drauf und die Kexte AMD8000controller und AMDradeonX4000 wurden bearbeitet. Ich verstehe nicht ganz was damit gemeint ist, dass die ID in dem AMD8000controller Kext 2x eingetragen werden muss und wo ich die ID in dem AMDradeonX4000hw eintragen muss.
    Vg

  • Das war eine weitere Möglichkeit, wenn man z.B. Ozmosis benutzt. Das mit dem zweimal hinzufügen bezieht sich darauf, dass in dem betroffenen Kext es nun zwei Stellen gibt, in der die device-ids gelistet werden, anstatt früher nur einmal. Man sucht einfach nach 0x67 und dann sieht man, wo man die neue device-id überall eintragen sollte.


    Updatesicherer ist es mit fake-id entweder über Clover oder SSDT.

  • Das war eine weitere Möglichkeit, wenn man z.B. Ozmosis benutzt. Das mit dem zweimal hinzufügen bezieht sich darauf, dass in dem betroffenen Kext es nun zwei Stellen gibt, in der die device-ids gelistet werden, anstatt früher nur einmal. Man sucht einfach nach 0x67 und dann sieht man, wo man die neue device-id überall eintragen sollte.


    Updatesicherer ist es mit fake-id entweder über Clover oder SSDT.


    Meine Rede pretty much...


    Überall wo die 0x67B01002 sonst vorhanden ist in den 3 Kexten AMD8000Controller, AMDX4000 und X4000HWServices.


    Sind insgesamt 4 Einträge.

    Einmal editiert, zuletzt von THack87 ()

  • Die fake ID hatte ich bereits bei Clover drin also müssten die Kexte ja geladen werden. Die passiert aber nicht. Unter Mojave funktioniert es wieder, wie unter 10.12, leider aber nur mit einem Monitor statt 2.
    Vg

  • Probier mal die Einträge in Clover wegzulassen und direkt in die Kexte einzutragen.


    So hab ich es auch. Musst bloß nach größeren Updates das wieder anpassen was aber eine Sache von 5 Minuten ist.


    Um das wirklich fest zu machen sollte man dann ehh die passende SSDT haben.


    Aber da ja seit dem großen eGPU Update einige Einträge dazu gekommen sind hätte man hier auch wieder die SSDT dementsprechend anpassen müssen.

  • Hab jetzt mal die Fake ID herausgenommen, wie es zu erwarten war, geht es genauso wenig wie vorher :(