Beiträge von elmacci

Danke für den Erfahrungsbericht!
Ich muss leider auch aus eigener Erfahrung feststellen, dass die Software-Entwicklung bei Gigabyte etwas zu wünschen übrige lässt.
Aktuelles Beispiel:
Seit Dezember lief auf meinem Z170X Gaming 5 Mainboard die BIOS Version 22c.
Und das wunderbar.
Im Januar kam dann Version 22d raus mit einem ersten Microcode-Update für die CPU. Blauäugig hab ich die mal installiert und auch eine neue DSDT gepatcht.
Bis ich dann leider feststellen musste das nach längeren Sleep-Phasen die IntelMausiKext für den Intel LAN Port eine Kernel Panic verursacht hat. Bis auf das BIOS Update wurde nichts verändert (natürlich gleiche BIOS Einstellungen wie zuvor).
Das es am BIOS liegen könnte ist mir überhaupt nicht in den Sinn gekommen. Erst als Gigabyte vor 2 Wochen die neue Version 22f veröffentlicht hat - recht kurz nachdem die 22d rauskam - bin ich stutzig geworden. Das die Version 22d auch nicht mehr offiziell auf der Gigabyte-Support-Seite angeboten wurde ist mir dann im Nachgang erst aufgefallen.
Sprich, offenbar wurde die 22d zu früh veröffentlicht bzw. war noch fehlerbehaftet.
Dann also 22f geflasht, aber: Pustekuchen. Gleicher Fehler /Kernel Panic mit der IntelMausiKext.
Jetzt hab ich aufgegeben, bin wieder auf 22c zurück - und siehe da, keine Kernel Panics mehr am LAN Port.

Soviel zur Softwarequalität bei Gigabyte. Also falls sich jemand mit Gigabyte Board und BIOS 22d bzw. BIOS 22f wundert warum der LAN-Port oder die IONetworkFamily-Kext Kernel Panics nach Sleep verursacht - einfach mal eine ältere BIOS-Version flashen

Ach ja, dazu muss ich vielleicht noch erwähnen das bei mir Wake on Lan aktiviert ist im BIOS, auch der Killer-LAN Port läuft mit der AtherosE2200 Kext.
Das alles problemlos mit BIOS 22c.

Sollte es nach der 22f noch eine weitere BIOS Version geben probiere ich es nochmal damit. Bis dahin mache ich aber so schnell keinen BIOS Flash mehr. Trotz Spectre/Meltdown.

cheers

@al6042 : Dein Screenshot bedeutet ja, dass die EFI-Daten auf der versteckten EFI-Partition der Platte liegen...
Deshalb ja auch meine vielleicht etwas naive Annahme, dass über die o.g. Tastenkombinationen einfach eine Online-Recovery durchgeführt werden kann.
Sonst hätte ich ja in der Vergangenheit niemals nimmer einfach eine neue, unbeschriebene fabrikneue (PC)-Platte einbauen können und macOS drauf installieren können...
Außer das "Mac-BIOS" (= EFI Firmware) wurde gegrillt...Aber wie das stattgefunden haben soll mit der Clover-SSD würde mich brennend interessieren (um es vermeiden zu können ).

@agrafx: Vielleicht einfach mal die Platte ausbauen, komplett formatieren und wieder einbauen? Eventuell klappt es dann mit der Tastenkmbi für die Recovery??

Hm, das ist echt ärgerlich, mein Beileid.
Was mir in der Tat nicht bewusst war (bevor ich diesen Thread hier gelesen habe) dass man mit einer Clover-EFI seinen originalen Mac "schrotten" kann?!

Ich dachte die EFI-Partition ist auf der eingebauten Platte - und wenn die defekt ist dann sollte eine Online-Recovery ja immer klappen?!
Beispiel:
Mac Mini gekauft, Originalplatte ausgebaut, komplett neue unbeschriebene Platte eingebaut, einer der folgenden Tastenkombinationen gebootet und über Internet neu installiert auf der frischen PLatte...

Befehlstaste (⌘)-R : Installieren Sie die letzte macOS-Version, die auf Ihrem Mac installiert war, ohne Upgrade auf eine neuere Version.
Wahltaste-Befehlstaste-R: Upgrade auf die neueste macOS-Version, die mit Ihrem Mac kompatibel ist.
Umschalttaste-Wahltaste-Befehlstaste-R: Erfordert macOS Sierra 10.12.4 oder neuer. Installieren Sie die macOS-Version, mit der Ihr Mac ausgeliefert wurde, oder ersatzweise die älteste, noch verfügbare Version. Für diese Kombination ist macOS Sierra 10.12.4 (oder neuer) erforderlich.

--> https://support.apple.com/de-de/HT204904

Oder wurde damit irgendwie die EFI-Firmware zerschossen? Was ich mir ehrlich gesagt nicht vorstellen kann...
Wie gesagt, ich dachte der Bootloader = EFI liegt immer auf der Platte...

Zitat von MacGrummel

Äh, @elmacci, wie kommst Du denn auf die Idee, dass die Webdriver nicht bei Apple zertifiziert wären? Da hast Du was grundlegend falsch verstanden. Die sind nicht von Apple, das war's dann aber auch, signiert sind sie trotzdem!
Genau wie die Idee, eine Nvidia GTX 750 Ti würde mit anderen Treibern laufen als eine GTX 970: BEIDE sind Nvidia-Maxwell-Karten, beide laufen NUR mit Webdriver-Paket richtig unter macOS..

Es gibt drei Stufen der Apple-Signatur bei Kexten: von Apple, von verifiziertem Entwickler und Unsigniert, dazwischen fallen dann noch signierte, aber veränderte Kexte. Da weiß das System nicht immer die richtige Zuordnung..

Vielleicht habe ich mich da etwas falsch ausgedrückt, insbesondere was die Verwendung des Begriffs "Signiert" angeht - ich wollte es nur nicht zu kompliziert machen.

Vielleicht hilft es, wenn man nicht von "signiert" spricht sondern davon, dass die Nvidia Webdriver nicht als "Platform Binaries" wahrgenommen werden. In dem Fall schlägt die "Library Validation" fehl die einige Programme (u. a. iBooks) verwenden, da diese voraussetzt das die zu ladende Bibliothek eine Systembibliothek ist.

Bez. der 750Ti hatte ich irgendwo im Hinterkopf dass diese keine manuell herunterzuladenden Webdriver benötigt sondern nativ (d.h. mit Treibern von Nvidia, die Apple aber offiziell in macOS eingebaut hat) läuft?! Da lag ich wohl falsch, ich dachte die 7er- Reihe läuft OoB...

Kurze Frage zu der iBooks Thematik:
Du hast zwei Hacks, einen Skylake mit einer GTX 970 und einen Haswell mit GTX 750 Ti, korrekt?

Vermutung: Dann läuft Dein Skylake mit WebDrivern von Nvidia, und Dein Haswell mit den macOS-eigenen Treibern für die GTX 750...
Das wäre zumindest jetzt einmal meine Vermutung warum Du das iBooks-Transparenzproblem auf dem Haswell nicht hast...
Wie @ductator schon geschrieben hat, ist das iBooks-Transparenz-Problem direkt verknüpft mit dem externen Webdriver von Nvidia. Vereinfacht gesagt: iBooks (und andere Programme bei denen der Fehler auftritt) benötigen eine bestimmte Komponente die geladen werden muss - diese Komponente muss von Apple signiert sein. Die Nvidia Webdriver sind NICHT von Apple signiert. Deshalb tritt der Fehler auf. Wenn man die macOS-eigenen Treiber für die Grafikkarte verwendet natürlich nicht.

Was allerdings sein kann: Soweit ich weiß hat Nvidia unter High Sierra die Validierung für die WebDriver geändert und diese sind somit signiert. Zumindest hab ich das irgendwo schon einmal gelesen, mich aber nicht weiter damit beschäftigt da ich wieder auf Sierra zurück bin.

Das ist übrigens auch der Hintergrund für diese Kext (die mittlerweile obsolet ist da die Funktionalität in NvidiaGraphicsFixup eingebaut wurde).
https://github.com/mologie/NVWebDriverLibValFix

cheers

EDIT: Ich lese auch gerade bei den FAQs des obigen Links das das Problem tatsächlich mit High Sierra und der neuen Validierungsmethodik gelöst ist. Insofern ist das iBooks Problem dort in der Tat nicht mehr präsent.

Evtl. geht es auch auf High Sierra, da werde ich es vielleicht auch mal testen wenn ich dazu komme meine externe SSD mal auszugraben

Übrigens hier auch der entsprechende Hintergrund zum Nachlesen:

https://github.com/vit9696/Shiki/issues/12

Interessant...ich hab mich ja schon länger nicht mehr mit Quicksync etc. beschäftigt da mein Hacki schnurrt wie ein zahmes Kätzchen.
Aber Dein Beitrag @henties hat meine Neugierde nochmal angestachelt ob es mittlerweile Neues auf dem Feld gibt.
Und nach ein wenig Recherche habe ich tatsächlich QuickSync Encoding UND Decoding sowie Airplay zum Laufen gebracht auf meinem System!Hier die Ausgabe von VDADecoderChecker:

MacX Video Converter zeigt auch YES bei Hardwaredecoding an, und das Intel Power Gadget zum ersten Mal auch Aktivität (Anstieg der Frequenz bei GT) beim Abspielen einer h.264 Vodeo Datei (und nicht nur beim umwandeln eines Films).

Ich hoffe ich hab jetzt nirgendwo einen Denkfehler drin, aber vielleicht kann das jemand bestätigen?

Folgende Dinge habe ich angepasst:
Nvidiagraphicsfixup nur noch in Verbindung mit dem bootflag für die pikera methode, ngfxnovarenderer habe ich entfernt. Damit das hier funktioniert:

Shiki Kext in Verbindung mit dem Bootflag shikigva=60.

Das wars auch schon.

System Skylake, GTX1080 TI, Soerra 10.12.6.

Ich bin begeistert - schon wieder einen Schritt weiter zum perfekten Hackintosh

Zitat von henties

@kuckkuck Mich wuerde echt interesieren ob @elmacci schon aufmerksam geworden ist das hardware encoding sowie Airplay jetzt geht, nun nachdem es einwandfrei zur Erkentnis gekommen ist das Lilu.kext in Zusammenhang mit NvidiaGraphicsFixup.kext die Ursache waren das es bislang nicht funktionierte. Vor einiger Zeit war @elmacci diesbezueglich in regen Schriftverkehr mit @vit9696 im Forum bei den "Verbloedeten Macs" taetig. Seine Bemuehungen waren damals aber leider Erfolglos.
Hoffe er hat jetzt auch Erfolg wenn er es probiert.
Gruesse

Hardware ENCODING ist nicht das Problem. Das funktioniert mit Lilu und Nvidiagraphicsfixup bei mir unter der Voraussetzung, dass ich folgende bootflags verwende:
-ngfxnovarenderer
ngfxpatch=pikera

--> Encoding, sprich z.B. Umwandlung eines Films in h.264, findet dann beschleunigt über Intel QuickSync statt. Ebenfalls funktioniert Airplay beschleunigt über QuickSync.

Was - und korrigiert mich gerne falls das mittlerweile gelöst wurde - nicht geht, ist das DECODING. Der VDADecoderChecker spuckt da dann eine Fehlermeldung aus.

Jetzt muss ich aber doch nochmal fragen @henties: Welche Diskussion bei den "verblödeten" meinst Du denn an der ich beteiligt war? Ich steh gerade irgendwie auf dem Schlauch...Mit vit9696 war ich in Kontakt, aber hauptsächlich wegen zwei Themen:
1. Multimonitor-Setup und Wakeup-Probleme / Black Screen. Gelöst durch Implementierung von drei verschiedenen Methoden mittels bootflag um das BlackScreenProblem zu fixen (bei mir funktioniert bspw. pikera problemlos). https://sourceforge.net/p/nvidiagraphicsfixup/tickets/3/
Bei mir funktioniert übrigens auch der KextToPatch-Eintrag von pikera, d.h. ich könnte eigentlich auf die Nvidiagraphicsfixup verzichten. Allerdings ist da der NVLibalFix eingebaut (für das iBooks Transparenz Problem), deshalb nutze ich lieber die Kext.

2. Abstürze von iTunes unter High Sierra aufgrund durch Apple geändertem AppleGVA.framework in Kombination mit Lilu.
Da ging es in erster Linie darum, dass ein aktiviertes QuickSync unter HS iTunes zum Absturz brachte.
https://github.com/vit9696/Lilu/issues/20

Meine Lösung war da: Zurück zu Sierra
Es gibt mittlerweile eine halbwegs zufriedenstellende Lösung mit High Sierra indem man shiki.kext installiert und mit dem bootflag shikigva=25 arbeitet (zumindest hatten da einige Erfolg mit).

Aber lange Rede, kurzer Sinn: Ich kenne ehrlich gesagt keine Kombination/Hackintosh bei der Airplay,/QuickSync Encoding UND Decoding funktioniert in der Konfiguration Skylake CPU, Nvidia Webdriver, Sierra...
Falls ich mich da täusche lasse ich mich gern eines besseren belehren...:)

cheers

Schön das es damit bei Dir geklappt hat!

Bezüglich Deiner Frage:
Diese Einstellung im BIOS legt fest, welche Grafikeinheit bei Dir als primäre EInheit angesehen werden soll, sprich bspw. welche Einheit genutzt werden soll um ein Bild beim Boot auszugeben.

IGFX= Interne GPU
PCIE1 = Grafikkarte in Slot 1
PCIE2 = Grafikkarte in Slot 2...etc.

Zumeist ist Slot 1 (PCIE1) der Slot in dem Deine GPU steckt bzw. stecken sollte, da auch nur da die meisten Lanes (=Speed) vorliegen.

Könnte dieses Thema hier sein, sofern QuickSync bei Dir aktiviert ist:
https://github.com/vit9696/Lilu/issues/20

Kurz: Unter High Sierra hat Apple ein paar Anpassungen unter der Haube vorgenommen die dazu führen dass bei aktivierter iGPU + dedizierter Grafikkarte (um Quicksync zum Laufen zu bringen) iTunes die ganze Zeit crasht.
Einfache Lösung:
Interne GPU deaktivieren (BIOS und Inject Intel raus) - wenn man QuickSync nicht braucht die wohl einfachste Methode.

Wenn Du keine dedizierte Grafikkarte hast dann probiere mal Shiki.Kext in Verbindung mit dem Bootargument shikigva=1

EDIT: Sehe gerade dass Du Ozmosis im Einsatz hast. Dann kann das auf dich zutreffen, muss aber nicht. Kenne mich mit Ozmosis leider nicht aus.

Wurden die Filme vorher runtergeladen aus dem Store oder versucht ihr euren gekauften Filme zu streamen? Letzteres geht nämlich nicht, ihr müsst die Filme vorher laden.

Zitat von mitchde

Inzwischen gibts den ..120er Treiber (für HS, nicht für die Betas).
Aber geht auch mit Betas wenn man die BuildNummer in dem NVSTart..kext anpasst.
Inzwischen laufen bei mir auch die MetalBench und CLBench Benches durch, mit .114 war das nicht der Fall.
Mal die Werte HS 10.13.1 Beta 1 mit .120er Treiber auf GT 1030.
PS: Geekbench geht nur OpenCL, CUDA + Metal nicht. Aber das betrifft alle non orig. Mac Gpus und das schon bei El Capitan, Sierra = GPU Compute Tests taugen für Hackintoshs nicht.

Also mit meiner 1080TI auf Sierra läuft Geekbench sowohl bei OpenCL als auch Metal durch (CUDA hab ich nicht installiert, lief aber damals auch durch als ich es noch installiert hatte). In der Vergangenheit ist er da auch immer abgestürzt bzw. hat abgebrochen nach ein paar Sekunden (nach histogram Equalization glaub ich). Erst als ich dann den NVWebDriverLibValFix installiert hab ging es.
https://github.com/mologie/NVWebDriverLibValFix/releases

In der neuesten NvidiaGraphicsfixup-Kext ist dieser Fix auch enthalten.

Zitat von al6042

Mit Workaround Nummer 2 geht es bei mir auch wieder...

Vielen Dank für die Kommunikation mit lvs1974 und dem exzessiven Testing...

Gerne - war ja nicht ganz Uneigennützig

Zitat von ductator

Habs nur im MacX Video Converter ausprobiert und da läuft Encoding dann auch.
CPU wird zum einen nicht voll ausgelastet und der Takt der HD530 geht auch von 0 auf 3xxMHz. Weiterhin deutlich schneller der ganze Vorgang, als ohne angehakten Intel.
Decoding habe ich nicht getestet, wenn du mir sagen kannst wie, dann mache ich das auch mal.

Encoding, sprich z.B. das Umwandeln einer Quelle mittels Codec in ein anderes Format (=MacXVideoConverer sagt "Ja"), war eigentlich nie das Thema bzw. shiki war insbesondere für das decoding wichtig. Encoding geht z.B. auch ohne shiki. Und wie Du schon richtig geschrieben hast, der Takt Deiner HD530 sollte in diesem Fall auch nach oben gehen.

Um decoding zu checken nutzt du am besten ein kleines Terminal-Script namens VDADecoderChecker - so wie es in der FAQ von Shiki beschrieben ist:
How can I check that hardware video decoding works?
Run an existing build of VDADecoderChecker for 10.11/VDADecoderChecker for 10.12 (or compile yourself) and check its output:
GVA info: Successfully connected to the Intel plugin, offline Gen75Hardware acceleration is fully supported
https://github.com/vit9696/Shi…b/master/Manual/FAQ.en.md

Einfach ausführen und schauen ob o.g. Meldung kommt.
Bei mir funzt nur das Encoding, Decoding nicht
Ich bekomme z.B. folgende Fehlermeldung:

In der Vergangenheit hat es mal funktioniert. Da hatte ich allerdings noch eine Maxwell Karte (GTX 970) - und mit Hilfe einer "Helfer"-Kext (eine modifizierte Kext namens "iMac.kext", die eine passende IOVARenderID injiziert hat) hat da auch das Decoding funktioniert unter Sierra. Da ich mittlerweile bei Pascal bin nutzt das leider nichts mehr. Für Pascal ist die richtige RenderID offenbar (noch) nicht bekannt.

cheers

UPDATE: Die neue Version ist offiziell draussen.

Interessant finde ich auch die Infos die der Entwickler nun einmal ausführlich in einer FAQ zusammengestellt hat:
https://sourceforge.net/p/nvid…vn/HEAD/tree/trunk/FAQ.md

Zitat von al6042

Das Thema habe ich auch und bin auf eine Lösung gespannt.

Aktuell gibt es m.E. folgende Varianten um das Problem zu lösen bzw. zu umgehen:

1) Workaround OHNE NvidiaGraphicsFixup.Kext

a) AppleGraphicsDevicePolicy-KextToPatch aktivieren von PikerA um das BlackScreen-Problem bei SMBIOS 6,1/15,1/17,1 zu lösen:

b) NVWebDriverLibValFix.Kext einsetzen um die NVIDIA-Treiber zu validieren (iBooks-Transparenz-Problem). Nur notwendig bis Sierra 10.12.6. In High Sierra werden die WebDriver von Nvidia anders eingebunden.
https://github.com/mologie/NVWebDriverLibValFix/releases

2) Workaround MIT NvidiaGraphicsFixup.Kext
Das geht aktuell nur mit einer inoffiziellen Variante in Kombination mit darin enthaltenen neuen Bootargumenten.
Diese Variante ist hier zu finden:
https://sourceforge.net/p/nvid…/239c/14de/83cc/9879/9588

Ergänzend müssen in Clover unter Boot folgende beiden Bootargumente ergänzt werden:
1) -ngfxnovarenderer
2) ngfxpatchlist=pikera

Achtung: das erste hat einen Bindestrich, das zweite nicht

Wobei das letzte Bootargument eigentlich nicht notwendig sein sollte für die meisten. Es definiert nur welche Methode der Kext verwenden soll um das BlackScreen-Problem nach dem Boot bei den SMBIOS-Definitionen 6,1/15,1/17,1 zu umgehen. Wenn man dieses Bootargument nicht angibt wird die Standardmethode verwendet die auch im offiziellen Release eingesetzt wird.

Info am Rande: Nutze ich die Methode von Piker dann habe ich (mit meinem Setup - Your Mileage May Vary) keine Probleme mehr mit meinem Monitoren beim Aufwachen (vor allem nach längerem Sleep). Deshalb setze ich entweder den KextToPatch ein oder den NvidiaGraphicsFixup.Kext mit dem entsprechenden Bootargument.

Die dritte Variante ist natürlich, zurück auf Lilu 1.1.7 zu gehen und NvidiaGraphicsFixup 1.1.3 zu verwenden. Da trat das Problem noch nicht auf.

Der Entwickler wird voraussichtlich im nächsten Release von NvidiaGraphicsFixup die verschiedenen möglichen Bootargumente implementieren.

Zitat von ductator

Hmm, alles ganz komisch. Ich hab die neueste Shiki noch mit dabei und mit shikigva=12 läuft Quicksync, solange die Anwendung manuell freigeschaltet wurde in der Kext.Aber Airplay funktioniert komischerweise gar nicht mehr.

So wie ich das verstanden habe ist shikigva=12 ja nur eine Methode, den VARenderer für eine in der Kext definierte Auswahl an Apps zu "whitelisten", oder?Ich habe beide Methoden getestet und nutze aktuell Methode 2). Shiki habe ich auch im Einsatz, allerdings ohne ein Bootargument (trotz Intel HD530 in Kombination mit GTX 1080TI). Der Vorteil von shikigva=12 liegt ja darin, dass man dann auch QuickSync DECODING hat, nicht nur ENCODING - oder?!

cheers

Zitat von Plonker

Ich nehme stark an, mein Nachbar ist Grafiker, er wird nicht mit 30 Hz arbeiten. Das checke ich glatt am Montag.Aber es gibt hier auch bestimmt Leute, die mind. 2 UHD-Monitore mit 60 Hz an einer Karte betreiben? Los - meldet Euch!

Der Thread ist schon ein wenig eingeschlafen - aber ich melde mich einfach auch einmal dazu

Hatte bis vor kurzem erfolgreich:
a) Eine GTX 970 an 3X LG 27UD88 4K Monitoren mit 60HZ

b) Zwei GTX 970 im SLI-Verbund (nur unter Windows wird die gemeinsame Power genutzt), die drei Monitore an einer der beiden Karten.
Auch hier mit 60Hz und UHD/4K Auflösung.
@apfelnico hatte mir damals sogar eine schöne SSDT gebastelt, damit beide Karten auch im richtigen Slot angezeigt werden (war aber eher kosmetischer natur).

c) Aktuell eine GTX 1080TI im Einsatz, da hängen auch die drei Monitore dran. Und klar, die schafft locker die dreimal 4K in 60HZ.

Zitat von rubenszy

@Aries1337 was soll das was du hier erzählst, natürlich braucht man mehrere Karten für Multimonitoring

So ein Beispiel:
NVIDIA TITAN X Maximale Auflösung 7680x4320 @ 60Hz
1x 5120x2880 und 1x 2560x1440, 2x 3840x2160, 3x 2560x1440, 4x 1920x1080 Monitor anschließbar

NVIDIA GTX 980 Maximale Auflösung 4096x2160
1x 3840x2160, 1x 2560x1440, 2x 1920x1080 Monitor anschließbar

NVIDIA GTX 980 Ti Maximale Auflösung 5120x3200
1x 5120x2880, 1x 3840x2160, 2x 2560x1440, 1 x 2560x1440 und 1x1920x1080, 2x 1920x1080 Monitor anschließbar

Alles anzeigen

Achtung, da hat sich ein kleiner Rechenfehler bzw. methodischer Fehler eingeschlichen.
Zunächst einmal:
1. Bei der Titan X handelt es sich bei der Angabe von 7680x4320@60Hz um die Gesamtauflösung, die die Karte IN SUMME schafft
2. Bei den beiden anderen sind das wahrscheinlich die Angaben pro Anschluss/Monitor.
D.h., man sollte zunächst immer erst einmal eine gleiche Basis herstellen bei den techn. Eigenschaften. Das ist auf der NVIDIA Seite mit den techn. Daten leider nicht deutlich genug dargestellt.

Jetzt zum Rechenfehler:
Bei der Titan X sind 7680x4320 @ 60Hz als maximale "Pixelschubser-Kraft" angegeben. Das heisst, die Karte kann maximal 7680x4320=33.177.600 Pixel mit einer Wiederholrate von 60Hz liefern.
1 Monitor mit UHD-Auflösung hat 3840x2160=8.294.400 Pixel, die befeuert werden müssen. 3 Monitore demnach 24.883.200 Pixel.
Und das liegt nunmal unter den max. möglichen 33 Mio. Pixeln bei 60Hz, sprich die Karte schafft das locker. Theoretisch gehen da sogar 4 UHD-Monitore in voller Auflösung mit 60Hz. Allerdings immer abhängig davon ob es genug passende Anschlüsse gibt.

cheers

hi zusammen,

könnte mal bitte jemand mit der Kombi Nvidia und Skylake sowie einem SMBIOS 6,1 / 15,1 oder 17,1 und der Kombination Lilu/Nvidiagraphicsfixup testen ob Quicksync noch funktioniert?
Hintergrund:
Die neueste Version von NvidiaGraphicsFixup (1.20) scheint QuickSync zu deaktivieren. Bei ansonsten gleicher Konfiguration läuft QuickSync (mit NvidiaGraphicsFixup v. 1.1.3) oder aber nicht (mit Version 1.20).

Dazu diskutiere ich gerade mit dem Entwickler hier:
https://sourceforge.net/p/nvid…#1ef1/1ecd/5366/239c/14de

Dankeschööööön

Zitat von MacGrummel

Ich kann dazu nur sagen: grundsätzlich am Thunderbolt liegt es nicht. Mein Quo mit seinem externen Thunder-Dock und mein X99er haben ihre externen Platten allerdings auch über FireWire an Thunderbolt angeschlossen, eine Platte mit Mini-DP- oder USB3.1-C-Port für den direkten Anschluss hab ich nicht. Die gehen bei mir genau so wie jede direkt angeschlossene Platte Schlafen und wachen auch wieder mit auf.

Danke - dann liegt es evtl. daran das ich da eine Samsung T3 dranhabe die einen USB-C-Anschluss hat, sprich nutze auch ein Usb-C auf USB-C Kabel.

@apfelnico: Da ich mir jetzt auch die Tage dieselbe Karte beschafft habe würde ich den wunsch von @Mork vom Ork nach dem Upload deiner schönen SSDT gerne nochmal hervorholen und ebenso mal frech die Hand ausstrecken Wär echt Klasse!

Und eine weitere Frage: Gibt es die Möglichkeit, dass TB3 Festplatten beim sleep bzw. nach dem aufwachen nicht automatisch ausgeworfen werden? bekomme da immer die fehlermeldung nach dem aufwachen. bei platten am regulären usb passiert das nicht. oder hängt das damit zusammen das die karte im pci slot steckt? merci

Meine Fresse - dieser MultiCore-Score...Berechnest Du nebenher Klimamodelle daheim oder wie?

Glückwunsch!

Bist Du immer noch "absturzfrei"?

Es handelt sich bei Dir zwar um einen Laptop mit einer gänzlich anderen Konfiguration, aber sieht fast schon so aus wie hier beschrieben:
Quicksync, Virtual-Screen Abstürze und iGPU+ded. GPU mit Grafikbeschleunigung