Eine GFX-SSDT Sammlung wie für Ozmosis-Bios wäre doch ein Hit.
AMD RADEON RX Grafikkarten ohne LILU & WhatEverGreen nutzen
-
-
Ich habe er gerade auch mal getestet, wirklich eine Klasse Sache!
Besonders lobenswert finde ich die unglaubliche Transparenz die Mieze an den Tag legt! Unteranderem deswegen ist mir dieser Patch auch lieber als Whatevergreen.
Zusätzlich scheint das ganze auch ein bisschen anders als Whatevergreen zu funktionieren, denn letzterer spricht individuelle Karten mit Ven und Dev IDs an, sonst funzt er nicht.
Auch kommt mir der Wake Vorgang mit diesem Patch wesentlich schneller als mit Whatevergreen vor.Ich habe das ganze auch mit SSDT versucht, da ich zurzeit überlegen komplett auf dem Ozmosis AcpiPatcher umzusteigen.
Um eine eigene SSDT für GFX0 zu erstellen, bin ich anscheinend zu blöd.
Haha genauso geht es mir.
Ich glaube da stimmt bei mir etwas mit den Pfaden noch nicht ganz, vielleicht kannst du @Mork vom Ork da kurz mal reinschauen 
Ich kann im Moment den Fehler nicht so ganz nachvollziehen, vielleicht steh ich auch einfach aufm Schlauch. -
Willkommen im Klub
, @kuckkuck. Es scheint wirklich nur an einer Kleinigkeit zu hängen...Was mir noch aufgefallen ist: Beim Booten mit Whatevergreen bekomme ich immer einen schwarzen Hintergrund und den weißen Ladebalken zu sehen (mit den bekannten kurzen Unterbrechungen / Blitzern). Mit der hier besprochenen Methode gibt's kurz vor dem Anmeldebildschirm grauen Hintergrund mit weißem Ladebalken.
-
Besonders lobenswert finde ich die unglaubliche Transparenz die Mieze an den Tag legt! Unteranderem deswegen ist mir dieser Patch auch lieber als Whatevergreen.
Zusätzlich scheint das ganze auch ein bisschen anders als Whatevergreen zu funktionieren, denn letzterer spricht individuelle Karten mit Ven und Dev IDs an, sonst funzt er nicht.
Auch kommt mir der Wake Vorgang mit diesem Patch wesentlich schneller als mit Whatevergreen vor.Genau deswegen würde ich das auch gerne machen, aber auch mit dieser Detaillierten Anleitung verstehe ich dennoch nur Bahnhof
Ich bin für jede Hilfe offen 
-
-
Nope, das wars leider auch nicht. Pack ich die wichtigen CodeSchnipsel direkt in die DSDT unter GFX0, funktioniert alles...
-
-
Ich habe das ganze auch mit SSDT versucht, da ich zurzeit überlegen komplett auf dem Ozmosis AcpiPatcher umzusteigen.
Haha genauso geht es mir. Ich glaube da stimmt bei mir etwas mit den Pfaden noch nicht ganz, vielleicht kannst du @Mork vom Ork da kurz mal reinschauen Ich kann im Moment den Fehler nicht so ganz nachvollziehen, vielleicht steh ich auch einfach aufm Schlauch.Hi kuckkuck,
versuche mal den gesamten Code hier (ist auch so in der angehängten SSDT enthalten):
Vergiss aber bitte nicht, an der markierten Stelle noch den Namen Deines Frambuffers einzusetzen - und poste bitte mal Deine DSDT, damit ich prüfen kann, ob dort der DTGP-Code bereits enthalten ist. -
Naja einfach kopieren würde ich den nicht, du muss schon eine fertige DSDT haben (GFX0 -> IGPU und ein GFX0 Device unter PEGP oder ähnlich).
Dann noch die entsprechenden Einträge im Block anpassen (Card#, ROM, model)Woher bekomme ich die Card# und ROM von meiner RX 480 Red Devil?
Wenn ich Lilu.kext deaktiviere, dann habe ich keine Audio Devices mehr.... Strange
-
@schluden Wenn du AppleALC benutzt macht das auch Sinn, denn der AppleALC.kext basiert auf dem Lilu Patcher...
Sevus @Mork vom Ork
Vergiss aber bitte nicht, an der markierten Stelle noch den Namen Deines Frambuffers einzusetzen
SSDT getestet und für mich den Hamachi eingefügt (wird aber sowieso auch von Ozm gesetzt), die SSDT wird BDMESG zufolge auch erfolgreich geladen, aber leider kein Erfolg...
ob dort der DTGP-Code bereits enthalten ist
Die DTGP Methode ist definitiv vorhanden.
Mir ist jedoch aufgefallen, dass der PEGP --> GFX0 Rename eventuell nicht vollständig ist. Du kannst dir das gerne mal anschauen. Ich werde die ganze Sache sowieso angehen, da ich gerade komplett auf On-the-fly Patch/Hotpatch wechsle. Der PEGP nach GFX0 Rename ist danach auf jedenfall gesetzt. -
Jau, es funzt!
Hab es nur mit deiner ersten hochgeladenen SSDT und der externen DTGP probiert, habe dort dann noch Hamachi gesetzt. Ich werde es jetzt mal komplett ohne DTGP und _DSM probieren, ich glaube GFX0-->GFX1 war der entscheidende Punkt.
Aber das verwirrt mich jetzt gerade ein wenig, in der DSDT ist ja ebenfalls das Device IGPU mit den Platform ID und Model-Einträgen. Unter GFX0 sind Einträge aus Toledas AMI-HD4600-AMD-Nvidia-A1... Wieso jetzt GFX1?Nur kurz als Nebeninfo: Ich benutze die DSDT schon seit langem und habe sie nie überarbeitet. Sie stammt noch aus einer Zeit wo ich mit ACPI fast nichts am Hut hatte, al6042 hat mir damals geholfen. Deswegen jetzt auch die zukünftige Umstellung auf AcpiPatcher, da mir die Methode gefällt, ich danach weiß was genau wo gepatcht ist und weil ein paar Device IDs etc nicht 100 % richtig waren (al6042 hatte damals die nötigen Daten dazu nicht). Seine DSDT hat jedoch bisher klasse Dienste geleistet!
Edit: Funktioniert auch super ohne DTGP und DSM
Habe mal die fertige SSDT für GFX1 angehängt: -
Ausschlaggebend zur "GFX1" war der folgende Punkt Deiner DSDT:
Das brachte mich darauf, daß hier "GFX1" gesetzt werden muss, da "GFX0" je bereits belegt ist. Und die folgenden CODE-Zeilen:External (_SB_.PCI0.PEG0, DeviceObj) // (from opcode)
External (_SB_.PCI0.PEG0.PEGP._ADR, UnknownObj) // (from opcode)
.
.
.
Store (0x0F, \_SB.PCI0.PEG0.PEGP._ADR)bewirken, das Dein "PEGP" bereits durch "GFX1" ersetzt wird.
PS: das fällt mir jetzt erst auf: in Deiner DSDT steht der Patch an der völlig falschen Stelle! Der müsste eigentlich unter der Device PEGP kommen, und nicht schon, wie bei Dir unter Device PEG0.
Schicke mir bitte mal eine unmodfizierte DSDT (kannst Du im CLOVER Bootmenu mit "F4" machen).Deine "Device (PEG0)" müsste eigentlich so aussehen:
-
Ah ich sehe, danke für die Erklärung!
In der Original DSDT ist unter PEG0 nur PEGP zu finden, in der gepatchten das Device GFX0 und HDAU. Da die Einträge in GFX0 (DSDT) und GFX1 (SSDT) sich beide auf die AMD Karte beziehen, könnte man sie doch eigentlich zusammenfügen.
Wenn ich jetzt also die DSM-Methode von GFX0 mit in die SSDT packe (dazu ggf. noch den Framebuffer) und eine weitere SSDT für HDAU erstelle (oder das auch noch in die gleiche SSDT packe), müsste doch alles unter GFX0 stehen und wieder passen... Ich hätte dann auch wieder nur eine _ADR Adresse für ein Gerät.Ich bin mir nämlich nicht so sicher, wie das von Apple vorgesehen ist. Mein bisheriger Stand war, dass die Intel GPU (original GFX0) bei Apple IGPU heißt und die ded. GPU (original PEGP) zu GFX0 geändert wird.
Wo wir gerade beim Thema sind: In der Whatevergreen Wiki wird mehrmals erwähnt, dass die Benutzung eines Framebuffers nicht empfohlen und vorgesehen ist. Die tieferen Gründe dahinter sehe ich nicht wirklich, aber wie ist das denn mit diesem Patch? Wüsstest du von irgendeinem Grund keinen Framebuffer einzubauen wenn dieser Patch benutzt wird
das fällt mir jetzt erst auf: in Deiner DSDT steht der Patch an der völlig falschen Stelle!
Jep, und deswegen auch das ganze durcheinander. In Zukunft wird das ganze über SSDT gelöst. Müsste dann so in etwa sein: -
@Kuckuck und @Mork vom Ork: Danke euch beiden. Ich schaue mir das am WE auch nochmal an, vielleicht bekomme ich es dann ja auch hin. Bei mir ist die HD530 ebenfalls IGPU und die PEPG in GFX0 umbenannt.
-
Bei mir auch. Aber dadurch dass ich AppleALC benutze bin ich ja irgendwie von LILU.Kext abhängig.
Wie habt ihr denn das gelöst? -
Lilu kannst du doch weiterhin nutzen, nur WhateverGreen muss raus.
-
Hätte die ganze Geschichte mit der SSDT und einer Vega 56 auch einen Sinn?
Benutze meine Graka gerade ohne jeglichen Kext. Den einzigen Unterschied wo ich mit Whatevergreen festgestellt habe ist, dass unter "Mein Mac" Graka als Vega 56 angezeigt wird, ohne Whatevergreen als RX XXX.Grüße aus Augsburg
-
Irgendwie sehe ich den Wald vor lauter Bäumen nicht mehr... Vielleicht kann mir ja jemand mit der DSDT im Anhang (die funktioniert) dabei helfen, das Device in eine SSDT auszulagern.
Nachtrag: Hab's mit einer DSDT hinbekommen, in der PEPG noch nicht in GFX0 umbenannt war. Zusätzlich fehler in der SSDT dann noch:
in der Methode _INI
