Problem mit Windows Boot über OC 0.78 bei eingeschalteter IGPU mit dGPU

    Moin,


    hier mein zweites Problem. Ich bearbeite gerade einige Filme mit Tools im Windows. Nun würde ich da gerne QuickSync nutzen.


    Ich schalte also die IGPU im Bios ein. Verstecke diese mittels einer Device Properties in der config.sys vor MacOS und starte dann neu.


    Wähle ich nun Windows aus - startet es zwar, ich lande aber vor einem Blackscreen. Dann wenn die Bildschirm Initialisierung starten sollte und der Anmeldeschirm kommen müsste...bleibt er schwarz.


    Gehe ich über die Bootauswahl im Bios bootet er sauber durch. Liegt also an OC. Nun habe ich mir mal die PDF von OC durchgelesen und versucht etwas zu finden, dass es verursacht...Pustekuchen.


    Könnte da mal einer in meine Config schauen oder mich in die richtige Richtung schupsen?


    Und ja, ich nutze noch OC 0.78, da mir gerade einfach die Zeit fehlt den augenscheinlich steinigen Umstieg auf OC 0.87 zu bewältigen... Da ist Einiges anders und ich müsste mich da einlesen. Auch fehlt der wahre Nutzen. Ich möchte gerade bei Monterey bleiben. Mache ich bei Zeiten, die Config ist auch schon vorbereitet. Zunächst wäre das aktuelle Problem toll.


    Es ist egal, welches Windows ich boote. Windows 10 und 11 gleiches Bild.


    Danke für Eure Unterstützung.


    VG


    g.com

    Dateien

    • EFI.zip

      (3,71 MB, 35 Mal heruntergeladen, zuletzt: )

    OpenCore unterscheidet nicht zwischen den Betriebssystemen sprich es wird alles einfach 1:1 durchgereicht alle ACPI Dateien aber auch alle eventuell gesetzten DeviceProperties und je nach Konfiguration auch das SMBIOS. Du schreibst jetzt das Du die iGPU mittels config vor MacOS versteckst wie machst Du das denn? Ausser einem komplett leeren DevProps Eintrag in Deiner config kann ich dazu nämlich nicht wirklich was finden? Startet Windows denn über OC wenn die iGPU im Bios deaktiviert ist und wenn es start würde es dann auch starten wenn Du den DeviceProperties Eintrag aus der config.plist testweise mal entfernst?

    Haswell, Notebook

    G.com Hast eine PN. OC aktualisiert auf 0.88DEV. Einträge für IGPU headless in DP gesetzt. Da stand nichts von IGPU. Ausserdem waren einige Einträge bei den Kernel-Extensions verhunzt (borked).


    Das mit DRM fiel mir später auch ein.

    Die borked-Meldungen hatte er bei SMCSuperIO.kext und SMCProcessor.kext.

    Sowie beim CPUFriendDataProvider.kext, der gar nicht vorhanden war.


    @griven IGPU unter DP deaktivieren? :think: Ich könnte mir das per SSDT vorstellen.

    Dateien

    Spoiler anzeigen

    Einmal editiert, zuletzt von bluebyte ()

    Per SSDT wäre der sinnvolle Weg wenn man es denn unbedingt machen will und dann aber bitte auch mit OSI Weiche weil andernfalls wirkt es sich natürlich ja auch auf Windows aus. Was man mit den DP machen kann ist der iGPU eine unsinnige DeviceID/igPlattformID verpassen was dann in der Folge dazu führen würde das die iGPU zwar aktiv ist aber sich zumindest in macOS kein Treiber daran binden kann ergo macOS würde sie höchstwahrscheinlich ignorieren. Ich weiß aber ehrlich gesagt nicht ob sich das nicht doch auch irgendwie auf Windows auswirkt denn irgendwas muss da ja passieren wenn der Rechner mit deaktivierter iGPU über OC Windows startet umgekehrt aber nicht und da in der config nichts weiter zu finden war als der leere Eintrag für die DP liegt zumindest der Schluss nahe das das eben auch Windows aus dem Tritt bringt...

    Haswell, Notebook

    https://dortania.github.io/Ope…tml#windows-gpu-selection


    Laut Dortania geht es und hat auch funktioniert bei meinen Experimenten.


    In den DCPI Bereich vom Hackintool war sie nicht mehr zu sehen.


    griven Kannst Du mal meine SSDT‘s anschauen? gerade bei der SSDT-CPU funktioniert die Weiche nicht. Setzte ich sie unter Scope werden die cf-frequencies nicht mehr geladen.


    Bei den anderen sollten sie drinnen sein. aber vielleicht falsch/unvollständig. Da bin ich echt noch zu unerfahren mit den Erstellungen. Wäre mir eine riesige Hilfe!

    Joa aber das ist ja für den exakt umgekehrten Fall nämlich dafür das die dGPU unter macOS nicht unterstützt ist und daher die iGPU benutzt wird. In dem Dortania Beispiel geht es darum das das Display an der iGPU hängt und Windows dann diese benutzt um zum Beispiel Spiele oder was auch immer zu rendern anstelle der stärkeren aber von macOS nicht unterstützten dGPU (eigentlich nur bei NVIDIA Karten wirklich akut). In Deinem Fall ist aber ja die RX580 die primäre GPU unter beiden Systemen von daher macht das was im Dortania Guide beschrieben ist bei Dir zumindest so keinen Sinn...


    Ich frage mich eh was Du mit Quicksync willst denn eigentlich kann die RX580 das doch mindestens genauso schnell/gut wie die iGPU wenn nicht sogar besser. Die RX580 hat mit Intel QuickSync vergleichbare De/Endoder für H264/H265 an Bord und zumindest den Haswell iGPU's dürfte sie leistungstechnisch haushoch überlegen sein. Was die SSDT-CPUFriend angeht um die musst Du Dir keine Gedanken machen diese spezielle SSD ist für den CPUFriend.kext und ohne diesen komplett nutzlos (sowohl unter macOS als auch unter Windows)...

    Haswell, Notebook

    griven Danke für deine Hinweise. Mein Tool scheint aber unter Windows immer nur Quicksync zu unterstüzten. Zumindest wenn ich die Hardware Acceleration einschalte und dann dem Decoder mitteile dass ich es nutzen möchte teilt er mir mit er könne keine Intel Media SDK Session öffnen.


    Aber ok, dann teste ich das mal an der Stelle.


    Jetzt aber zur SSDT-CPUFriend. Bitte schaue Sie Dir mal genau an. Folgendes habe ich gemacht:


    - CPUFriend in der Shell gestartet, CPUDataProvider SSDT erstellt.

    - SSDTPrgen in der Shell gestartet und eine SSDT-CPU erstellt.

    - cf-frequencies aus der CPUDataProvider SSDT in die SSDT-CPU unter Method 4 eingefügt.


    Somit nach meinem Verständnis eine vollständig eigenständige SSDT.


    Überhaupt, ich dachte die SSDT´s werden nur geladen, wenn MacOS gebootet wird, deinen Worten entnehme ich aber dem ist anders. Somit beeinflussen meine SSDT´s Windows wenn keine Weiche gesetzt wird.


    Wärest Du von daher mal so nett diese kurz anzuschauen, sind jetzt 5 Stück und 4 davon 08/15 Standard. :)

    Wie schon erwähnt OpenCore kümmert sich nicht darum welches OS gestartet wird bzw. weiß das nichtmal zu dem Zeitpunkt an dem die ACPI, SMBIOS, DeviceProperties usw. Geschichten verarbeitet werden dies alles passiert nämlich bereits bevor der BootPicker überhaupt erscheint demnach ja natürlich all diese Dinge wirken sich auf alle Betriebssysteme aus die über OpenCore gestartet werden das aber nur am Rande. Zurück zu Deiner SSDT. Das, was da in der _DSM Methode deklariert wird sind die FrequenzVectoren für das Apple eigene XCPM dieses Property liest der CPUFriend.kext und nutzt es um das PlattformPlugin von macOS entsprechend zu patchen. Alles was dort deklariert ist hat keinerlei Einfluss auf den Betrieb oder die Funktion eines anderen Betriebssystems als macOS. Für macOS spielen die dort deklarieren Werte aber auch nur dann eine Rolle wenn der Kext geladen wird ohne den Kext kann auch macOS mit den Informationen nichts anfangen bzw. ignoriert diese.


    Das CPU-PM vom MacOS ist Software basiert sprich anders als Windows oder Linux verlässt sich macOS an der Stelle nicht auf das ACPI sondern bezieht die Informationen zu den zu nutzenden P und C States aus dem Plattformplugin zum jeweiligen SMBIOS man spricht hier von "Frequency Vectors". Natürlich passen diese Vektoren von Haus aus nur zu exakt der CPU mit der das jeweilige Modell bestückt/ausgeliefert wurde für Apple und deren Rechner fein für unsere Kisten eher nicht optimal weil natürlich in einem Hackintosh selten die CPU steckt die im gewähltem SMBIOS verbaut war (gutes Beispiel ist das gerne genutzte iMacPro SMBIOS das von Hause aus eine XEON W CPU vermuten lässt). Deine _DSM Methode korrigiert das indem sie passende Vektoren für die tatsächlich verbaute CPU bereitstellt. Lange Rede, kurzer Sinn selbst wenn da keine _OSI Weiche drin steckt kannst Du das getrost ignorieren weil die Informationen die dort enthalten sind von allen und jedem ignoriert werden solange sie nicht macOS heißen und zufällig vom CPUFriend.kext quasi mit der Nase drauf gestoßen werden :)

    Haswell, Notebook

    griven

    TOP! Danke Dir. Aber ich habe gerade mal rein aus Spass ohne den CPUFriend.kext gebootet und die cf-frequencies sind dennoch vorhanden. Allerdings an anderer Stelle, als wenn ich die CPUFriendDataProvider.kext nutze.


    Ebenso tauchen Sie an derselben Stelle auf, wenn ich CPUFriend lade.


    Dazu hatte ich bereits einen anderen Thread erstellt.



    Wenn ich mir nun die SSDT anschaue, soll er diese ja genau dahin laden.


    Nur scheint der CPUFriend.kext dann nix auszulesen.


    Habe sogar aus Spass einfach mal die SSDT in ssdt-data.aml umbenannt. Hat keinen Unterschied gemacht.


    Was verstehe ich hier nicht?


    Habe es genau nach der Anleitung gemacht.


    #### Data Combination

    1. Generate a correct copy of `CPUFriendDataProvider.kext` with `./ResourceConverter.sh --acpi /path/to/file`.

    2. Open SSDT previously generated by [ssdtPRGen.sh](https://github.com/Piker-Alpha/ssdtPRGen.sh), and search for `Method (_DSM, 4, NotSerialized)` in a text editor.

    3. Paste `"cf-frequency-data"` entry from `ssdt_data.dsl` to the SSDT generated by [ssdtPRGen.sh](https://github.com/Piker-Alpha/ssdtPRGen.sh). A glance at the final work looks as follows.

    ```


    Darf ich aber unabhängig davon verstehen, dass die SSDT unabhängig, ob CPUFriend daraus liest oder nicht - nicht für andere Betriebssysteme relevant ist?

    Wie die SSDT heißt ist vollkommen egal und auch dass die Informationen da landen wo sie landen unabhängig davon ob der Kext geladen ist oder nicht ist so korrekt.


    Eine SSDT (Secondary System Description Table) ist ein Teil des ACPI und das funktioniert unabhängig von irgendwelchen Kexten usw. die SSDT's fügen dem ACPI Eigenschaften an einer definierten Stelle hinzu (in dem Fall die Vektoren) oder ändert diese je nachdem halt was in der SSDT deklariert wird. Diese Änderungen oder Ergänzungen tauchen dann unter anderem auch im DCPI Manager auf. Je nachdem was hier in der SSDT deklariert wurde wirken sich diese Änderungen direkt aus (SSDT-EC zum Beispiel die einen "virtuellen" Ersatz zum vorhanden EC erstellt an den sich der MacOS eigene Treiber binden kann) oder sind erstmal nur da ohne das direkt etwas damit passiert weil zum Beispiel kein OS Bestandteil keine direkte Verwendung dafür hat. Wie ich ja schon versucht habe zu beschreiben verwendet macOS ein Software gesteuertes CPUPM will meinen das CPUPM von macOS kümmert sich erstmal nicht darum was im ACPI zur CPUPM steht sondern bezieht die zum PM nötigen Informationen aus dem Plattform Plugin. Windows und Linux auf der anderen Seite beziehen die Informationen zum CPUPM stark vereinfacht aus dem ACPI bzw. überlassen das CPUPM direkt dem ACPI und geben nur die entsprechenden P und C - States ans ACPI weiter und sind fertig damit.


    Jetzt wird man sich fragen warum dann der ganze Zauber wenn macOS sich nicht drum kümmert und Windows/Linux das auch mehr oder weniger egal ist? Ganz einfach an der Stelle kommt nämlich wieder der CPUFriend.kext ins Spiel denn damit der seine Arbeit verrichten kann braucht er diese Informationen wobei die gar nicht mal unbedingt aus dem ACPI kommen müssen sondern durchaus auch aus einem zusätzlichen Kext stammen dürfen (CPUDataProvider.kext). Der Weg über das ACPI ist schnell und bequem und daher der bevorzugte. Egal woher solange der CPUFriend die Informationen bekommt und lesen kann sorgt er in der Folge dafür das sie an der richtigen Stelle im PlattformPlugin landen und das CPUPM unter macOS passend zum verbauten Prozessor funktioniert.

    Haswell, Notebook

    griven Danke für deine ausführliche Erklärung für Dummies ;)


    Ist für mich alles schon höhere Mathematik, vor allem da ich ja nur gelegentlich alle Jubeljahre noch dran komme. Family first halt. Dazu schon lange kein neues System mehr erstellt.


    However, was mich verwirrt hatte, war, dass die Daten, wenn der CPUDataProvider.kext genutz werden an einer anderen Stelle eingestellt werden.


    Nämlich unter AppleACPICPU, nun ging ich davon aus, dass dies bedeute, es liefe etwas nicht korrekt, auch wenn das Steppen optimal lief. Deine Erläuterungen haben mir das aber nun klar gemacht. DANKE!


    DANKE auch noch mal an bluebyte für das Update! Musste noch ein paar Kleinigkeiten korrigieren, das OCAT schreibt da immer ein paar Daten um, warum auch immer das nur bis OC 0.78 kann. Ich bevorzuge eh den Weg über den Plist Editor.


    Und nachdem ich mir die Plist im CpuDataProvider.kext angeschaut habe, ist mir das alles auch klarer geworden. Der patcht an einer anderen Stelle auf einem anderen Weg. OK!


    Für die CPUFriend ist das egal. Das zählt.

    Kleiner Tipp zu OCAT: geh mal auf Edit oben im Menu und klick da OpenCore DEV an dann kann es nämlich auch die aktuell Developer Version von OC ;)

    Einmal geklickt musst Du noch auf das "Update OpenCore and Kext" gehen und dort "Get OpenCore" klicken und dann bist Du ready für bleeding Edge oder so *gg*

    Haswell, Notebook
    Zitat von G.com

    OC 0.78 kann

    Nennt sich bei OCAT ( Sync OS )

    TOP! Soeben erledigt... 3 Wochen wenig Schlaf und viel Technik im Haushalt. Nu bin ich feddich, danke Euch!

    Entschuldigung, das ich das mit OCAT nicht erklärt habe. Ich bin davon ausgegangen, dass du das weißt. Jetzt siehst du, dass so eine Aktualisierung kein großes Problem mehr ist.

    Hier im Forum gibt es einen informativen aber auch unterhaltsamen Thread von kuckkuck . Dieser Thread widmet sich ausschließlich dem CPU-Speed-Stepping. Dieser Thread ist Pflicht, sobald man die Kisten mit einem „nicht passenden “ SMBIOS betreibt. Die Sachlage hat griven ja schon erklärt.

    Such mal kuckkuck und cpufriend.


    CPUFriend Guide, HWP & Speedstep: X86PlatformPlugin vs ACPI_SMC_PlatformPlugin

    Spoiler anzeigen