Mein MBP 16" war nicht defekt... OCLP und Windows-Updates vertragen sich manchmal nicht.

Nvidia Software ist ja wie ein OCLP Patch. Windows selbst scheint die Umschaltung nicht nativ zu können.
Nö, das ist wie Windows grundsätzlich funktioniert. Die Hardwarefunktionen erledigen Treiber, die vom Hardwarelieferant bereitgestellt sind.
Das Lustige ist ja, dass BootCamp für den MBP2014 die IrisPro Treiber mitliefert. Sie werden nur nicht freigeschaltet und lassen sich nicht ohne den OCLP Patch installieren.
1726416815100.png
 
Müsste ohne Betriebsystem funktionieren. Wenn ich macOS booten kann, geht auch EFI reparieren ohne Tool.

Die Idee ist, ein aktuelles Backup der ESPs zu haben.

Es geht immer ohne tool, aber das kann halt sperrig werden. Bei einer Disk ists ja noch locker. Denk aber an die Mac Pro Leute mit bis zu 10 internen Platten/SSDs. Ja das geht, wenn NVMes auf PCI Slots mit einrechnest.

Ich schreib die Tools auch für mich, meine Testkiste hat schon mal einen (übertrieben beschriebenen) Boot Picker mit nem halben Meter Systeme und Bootlader. Muss ja viel testen.
 
Möglicherweise sehen die lizenzvereinbarungen vor, das komplette Treiberpaket mitzuliefern.
(Auch wenn Apple nur die notwendigsten Teile davon installiert.)
Es gibt ja den fast baugleichen MacBookPro mit iGPU only(i) oder mit dGPU&iGPU (d). Deshalb sind die iGPU - Treiber bei Bootcamp dabei, da ja im (i) zwingend erforderlich.
 
Zuletzt bearbeitet:
Ich habe jetzt gerade mit zwei unterschiedlichen EFIs getestet:
Bei einem EFI mit dem Flag GMUX bootet Windows normal und zeigt beide Grafikeinheiten
Bei einem EFI ohne dem Flag GMUX bootet Windows normal und zeigt nur NVidia. Also der installierter Iris Treiber stört nicht.
Man kann jederzeit zurückrudern.
 
Ja, externes TB-LW habe ich da und könnte damit mal rumexperimentieren, stand eh irgendwo weit hinten auf der Liste der Winter-Hobbybastlerei.
So, das Thema Windows auf dem Thunderbolt_LW habe ich jetzt mal kurzerhand umgesetzt. Die WinOS Installation ging auch sehr flott. Wie von @RIN67630 bemerkt, wird das TB-LW automatisch als 1.Datenträger erkannt, wenn die Bockigkeit von WinOS mit 2.Datentragern galant umgeht.

Die Installation ist gerade noch klassisch, also erstmal blank installiert, dann Bootcamp-Treiber nachinstalliert.

Nun ist, wie ja erwartet, aber mir bisher nicht bewusst lediglich die dGPU angesprochen:

1726509447792.png

Als nächster Schritt werde ich nun die OCLP - GMUX - Option aktivieren und schauen was WinOS da macht. Dazu gehe ich aber erstmal wieder offline im WinOS, damit da nix automatisch anläuft (Update-Pause für 7 Tage habe ich sicherheitshalber auch aktiviert)
 
Und hier die Rückmeldung mit dem Ergebnis des OCLP-GMUX-Tweak.

Das System erkennt nach der genannten Vorgehensweise auch Offline die neu ansprechbare iGPU und aktiviert diese selbstständig mit dem augenscheinlich richtigen Treiber:

MBP14,3 mit iGPU in WinOS.PNG

Ohne Online zu gehen habe ich dann gleich das wieder abschalten der OC-GMUX-Option ausprobiert. (dabei kam übrigens gleich auch ein OCLP-Bugfix von 2.0.0 auf 2.0.1 rein, wo es wohl genau um die NVIDIA Patches in macOS ging, aber hier egal, da OC wohl gleich blieb).
Ergebnis wie von @RIN67630 bereits auch geschrieben - iGPU dann einfach wieder weg und keine Probleme beim Systemstart von WinOS

Was mir nebenbei auffiel: Im WinOS-Taskmanager wird immer nur die NVIDIA / dGPU dargestellt wird und auch etwas Last bekommt, egal ob mit Standardsetting nur dGPU und mit OC-GMUX dGPU und iGPU. Die iGPU wird also im Tastmanager nicht dargestellt. Kann man aber, wenn man misstrauisch ist auch 'überinterpretieren', dass die iGPU vielleicht garnicht arbeitet.

MBP14,3 mit dGPU only in WinOS Tastmanager.PNG MBP14,3 mit dGPU & iGPU in WinOS Tastmanager nur dGPU.PNG
 
Was mir nebenbei auffiel: Im WinOS-Taskmanager wird immer nur die NVIDIA / dGPU dargestellt wird und auch etwas Last bekommt, egal ob mit Standardsetting nur dGPU und mit OC-GMUX dGPU und iGPU. Die iGPU wird also im Tastmanager nicht dargestellt. Kann man aber, wenn man misstrauisch ist auch 'überinterpretieren', dass die iGPU vielleicht garnicht arbeitet.
Bei mir wird die iGPU sehr wohl im Task Manager angezeigt, allerdings stimmt es, dass fast alles dennoch von NVidia erledigt wird.
:rolleyes:
Ob man die Balance in den Einstellungen noch bestimmen kann, muss ich wohl morgen eruieren.
 
Ich habe ja auch noch ein MBP11.2 da, also eben gerade der fast baugleiche aber ohne dGPU und nur mit iGPU. Bei dem wollte ich im Tastmanager mal als Kreuzvergleich die iGPU und deren Last anschauen...aber - Neue sonderbare Erkenntnis:

Meine Windows-Installation auf dem TB-Drive, welche ich am MBP11.3 eingerichtet hatte, wird am MBP11.2 garnicht als bootbares LW erkennt. Soll heißen, das WinOS wird garnicht im OC-Bootloader angeboten. Das ist echt schade, weil ich das WinOS auf TB-LW gerne Geräte-übergreifend austesten und ggf. auch nutzen wollte.

Zudem: Im Apple-Bootpicker wird das externe TB - WinOS auch schon am MBP11,3 nicht angeboten. Erst der OC-Bootloader macht es sichtbar. Bei WinOS auf einem interen LW ist mir das so nicht bewusst vorgekommen - wird als irgendwie mit dem TB-LW zusammenhängen.

Nochwas: Beim MBP11.3 hat die Windows-Installation mein EFI-Symbol beim Apple-Bootpicker in 'Windows' umbenannt. Funktioniert aber weiterhin, um damit die EFI der interenen SSD mit OC drauf anzusprechen und dann da auch OC zu verwenden. NVRAM-Reset hat daran nicht geändert. Funktioniert am MBP11,3 wie es soll, sieht aber blöd aus. Jedoch passiert das ja nicht einfach so und ich vermute hier einen Zusammen mit der Nicht-Funktion unter dem MBP11.2. Irgendwas hat der WinOS Installationsprozess etwas spezifisch mit dem MBP11.3 angestellt, was dem 11.2 wiederum fehlt.
 
Hat vielleicht irgend jemand eine Idee, warum das WinOS auf dem MBP11.2 nicht angeboten wird?
 
Das Thunderbolt LW ist in GPT vorbereitet. In weiteren Partitionen und darunter auch Containern sind Daten und macOS High Sierra drauf.
 
Zurück
Oben Unten