Quicksync, Virtual-Screen Abstürze und iGPU+ded. GPU mit Grafikbeschleunigung

  • @armut "...Forgot that you have nvidia 1080, should be shikigva=60 of course (4 for compatible renderer, 8 for vda whitelist, 16 to fix iTunes crashes, and 32 to replace the board id)...

    Ja das was du da oben zitierst habe ich auch ganz gruendlich, vom Anfang bis Ende, durchgelesen, hier der Link, https://github.com/vit9696/Shiki/issues/12


    Danach wurde mein Entschluss, nicht mehr Lillu und seine Untertanen in meinen iMeckies zuzulassen wiedermal Bestaetigt das es der richtige Entschluss gewesen war.
    Stricksachen, von Solo Artisten, die mann selber nicht versteht was sie wann und wie im Eigenen System Anstellen, verursachen das es jedesmal ein Seiltanz Akt, oder Himmelfahrtskommando wird wenn mann irgendwas am System aendert, dazufuegt was Apple sowie Nvidia Updates Einschliesst. In anderen Foren gibt es eine Menge Beschwerden das deren Systeme, nach dem letzten Update "laggy" geworden sind, und es wird Starck auf Nvidia geschimft. Das sind alles "user" die Lilu sowie NvidiaGraphicsFixup bei sich im Einsatz haben. Es wurde sogar auch schon erkannt das diejenigen die eher AGDPfixup verwenden, nicht unter diesen Graphics lag Problem leiden. ich bin einer von denen. :-)
    Say no more.
    Gruesse aus Namibia

  • Noch mal ein Update:
    Ich habe gestern aus Neugier den Benchmark von BruceX 5K in FCPX durchgeführt.
    Überraschend ist, dass ich beim ersten Durchlauf knapp 82 Sekunden gebraucht habe und die Versuche danach alle mehr als 150 Sekunden dauerten.
    Was mir jedoch auch Auffiel, das im Intel Gadget die IGPU gar nicht angesprochen wird (außer beim ersten Durchlauf), obwohl in MacX die Intel QuickSync erkennt.


    VDADecoderChecker spuckt mir folgendes Ergebnis aus:
    GVA info: Successfully connected to the Intel plugin, offline Gen9
    Hardware acceleration is fully supported


    Scheint mir doch sehr ungewöhnlich!


    @henties
    Von den Problemen mit 10.13.3 habe ich gelesen, weswegen ich auch zur Zeit noch nicht Update.
    Allerdings habe ich auch gelesen, dass einige nach dem Update immer noch unter dem Blackscreen Problem leiden.
    Müssen wohl abwarten und schauen was demnächst passiert :)


    EDIT:
    In MacX wird die IGPU angesprochen!

    Einmal editiert, zuletzt von armut ()

  • @armut Quote "Von den Problemen mit 10.13.3 habe ich gelesen, weswegen ich auch zur Zeit noch nicht Update." Endquote


    Wenn mann das was Nvidia mit seinen Webtreiber bewirken will, bewusst nicht zulaesst das das auch "ungestoert" stattfinden kann, sondern kexte einsaetz die das Umfeld das Nvidia bemueht fuer seine Treiber zu schaffen, stoert, aendert oder schlichtweg modifiziert, dann muss mann schon mit Problemen Rechnen.


    Lilu sowie NGFUK verrichten ihre schmutzige Arbeit im AppleGraphicsControl.kext, im "Cache" und auch im Nvidia Framebuffer, soweit ich es nach gruendlichen Recherschen aus diversen Quellen, feststellen konnte. Die Probleme die Lilu sowie NGFUK womoeglich durch deren Einsatz in Systemen, verursachen, werden bestimmt niemals demnaechst geziehlt durch Nvidia mit einen Webtreiber Update geloest werden. Sowas anzunehmen waere einfach "wishfull thinking" Warten bis die "fuer Nvidia nicht eksitierenden" Webtreiber" Probleme fuer 10.13.3 geloest sind, bedeuted einfach "that one just shoots oneself in ones own foot"


    13.3.3. Laeuft einwandfrei wenn mann sich an die Grundspielregeln des Haeckens haelt:


    Haecke Planmaessig und systematisch.


    Patche nur da wo es Sinn hat, vermeide Patches einzubinden von denen mann nicht mal weiss was sie "aendern sollen.


    Verwende nur Patches wenn mann danach auch nachweisen kann das sie das bewirken was auch erwarted wurde.


    Vermeide das Planlose einsetzen nach dem Motto "the more the merrier" wird schon klappen.


    Identifiziere Probleme im System und loese diese Probleme einzeln und der Reihe nach, nie alle gleichzeitig und auf einmal.


    Akseptiere das ein Hack fuer eine gewisse Zeit ein "WIP - work in progress" sein wird und das einige Sachen nicht sofort funtionieren wie mann sich das wuenscht.


    Zeit ist die beste Medizien, denn Zeit die mann anwendet sich ueber vorhandene loesungen schwieriger Probleme zu informieren fuehrt dann auch meistens zum Erfolg.


    Mein Rat, entferne Lilu und alles was damit zu tun hat, setze AGDPfix einmalig ein um das "black screen" Problem zu loesen. Muss nach jeden Webtreiber update wiederholt werden. Vergess vorab das Abspielen von DRM "protected material" durch iTunes. Es gibt mehrere andere und einfache Moeglichkeiten wie mann Problemlos mit DRM Dateien umgehen kann, Methoden die einem wenigstens nicht auf unbekannte Art und Weise, wichtige System Funktionen beeintraechtigen. Du wirst staunen wie zuverlaessig und stabiel sich so ein iMecki, mit den obengenannten Ratsclaegen, gestallten laesst, und das nicht nur mit 10.13.3 sondern gerade mit 10.13.3.


    Probleme die mann frueher mit Lilu, NGFK und anderen Lilu Verwandten, loesen konnte, existieren Einfach Heutzutage nicht mehr, zb. das iBooks transparenz problem. Warum ueberfluessige patches also staendig als "non paying passengers" mitschleppen, begreife ich schlichtweg nicht.


    Hack wisely and sensibly.


    Gruesse aus Namibia

    3 Mal editiert, zuletzt von henties ()

  • @henties


    deinem nachvollziehbaren Rat entsprechend habe ich den lila.kext von meinem System verbannt und den AGDPfix durchgeführt.


    Nun läuft alles augenscheinlich wieder, wobei mir VDADecoderChecker eine Fehlermeldung ausspuckt. Warum auch immer. Werde mal die Funktionalität bei Gelegenheit testen.


    Danke an alle, die hier unermüdlich bereit sind zu helfen.

  • @Plebejer Ja leider spuckt der VDADecoderChecker auch bei mir eine Fehlermedung aus. Die VDADecoderChecker Fehlermeldung laesst darauf schliessen das das "harware decoding" nicht funzt. Ist das aber wirklich so ? Habe es selber noch nie geprueft aber es behaupten Hacker, in anderen Foren, das "hardware decoding" trotz der Fehlermeldung geht- also "false positive" Ich werde jedenfalls erstmals keine obskuren Patches in meine Systeme reinhaengen, von denen ich noch nicht mal weiss, wenn sie "hardware decoding" dann hinbiegen sollten, was fuer andere Schaeden dann als "unerwuenschtes Geschenk" mann noch mitgeliefert bekommt. :-) Hardware decoding bedarf noch einige Anstrenungen, von mir und vor allen Dingen Anderen, um eine astreine Loesung her zu Zaubern, von der mann weiss was mann, bei einem Einsatz solcher, zu erwarten hat.
    Wenn deine eigenen Test bezueglich "hardware decoding" oder eher die Autentitaet der VDADecoderChecker Fehlermeldung nachgewiesen ist wuerde ich mich freuen wenn du mir das mitteilen wuerdest. Bin die naechsten 2 Wochen unterwegs und werde nicht in der Lage sein um sehr viel Zeit im Forum zu verbringen.
    Gruesse aus meinen Nest

    Einmal editiert, zuletzt von henties ()

  • Nur weil ein User schlechte Erfahrungen mit bestimmter Software gemacht hat, würde ich nicht gleich alles übern Haufen werden (no offense @henties!). Stattdessen sollte jeder seine eigenen Erfahrungen und Erkenntnisse machen und daraufhin entscheiden. Dabei ist es wichtig zu wissen, dass Kexts wie Shiki, WhatEvergreen oder AppleALC vielen Usern geholfen haben und auch weiterhin tagtäglich helfen! Ebenfalls ist jedoch zu betonen, dass der Weg über Lilu Plugins bei möglichen Alternativen wohl auch nicht immer der beste zu sein scheint, wie Henties in seinem Beitrag erklärt. Es müssen beide Seiten betrachtet und sich ein persönliches Bild gemacht werden.


    Zur AGDP Problematik: Ich würde jedem dem dies möglich ist (MacPro6.1) dazu raten, weder AGDPFix noch NVGF zu verwenden, sondern per Clover Hotpatch (config/ACPI/Renames Sektion) die Nvidia GPU in GFX1 umzubenennen. Dies kann durch einen Rename von zB PEGP-->GFX1 oder GFX0-->GFX1 passieren. Was genau nötig ist, hängt vom individuellen Device ab und unter welchem Namen bei diesem die Nvidia in IOReg erkannt wird. Das ganze braucht keine Modifizierung von Kexts und ist UpdateProof.

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

    Einmal editiert, zuletzt von kuckkuck ()

  • Gibts für den Hotpatch im Clover auch eine genaue Anleitung im Forum.
    Würde die Tage mal versuchen das Ganze mit QuickSync zum Laufen zu bringen.

  • Weiß ich nicht, das ganze über Hotpatch zu lösen habe ich mir gerade nur überlegt, eventuell hat aber dazu mal jemand einen Guide geschrieben. Das ist aber echt nicht schwer, ich kanns dir erklären wenn du willst...
    Schick dafür mal einen IOReg Dump...

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

  • @kuckkuck
    @Plebejer zur Information und Hintergrund Erklaerung, um dein Umschalten auf "back to basics" mit AGDPfix auch besser verstehen zu koennen.


    ADGPfix und was er anrichtet, und auch “unbekantes” was man moeglicherweise als “unerwuenschtes Geschenk” dazu bekommt, wenn mann ihn einsetzt, benuehe ich mich hier zu demonstrieren.


    Wie im Anhang SMBIOS zu ersehen ist sind fuer meinen Skylake iMeckie unter SMBIOS die “system definition” 17.1 sowie die “Board-ID” Mac-B809C3757DA9BB8D eingestellt


    Im Anhang Mac-B809C3757DA9BB8D unter “ConfigMap” neben meiner zu erkennenden Board-ID Mac-B809C3757DA9BB8D ist die “string variable” auf Config2 an der linken Seitenhelfte des Kombo Bildes gesetzt, derweil aber dieselbe “string variable” an der rechten Bildhaelfte auf “none” gestellt ist.


    Was soll den dies alles bedeuten :-)


    Die linke Bildhaelfte ist ein “snapshot” eines durch AGDPfix UNGEPATCHTEN Eintrag in AppleGraphicsControl.kext —> Show Package Contents —> Contents —> Plugins -> AppleGraphicsDevicePolicy.kext —> Show Package Contents —> Info.plist “open with Xcode —> IOKitPersonalities —> AppleGraphicsDevicePolicy —> ConfigMap —> Mac-B809C3757DA9BB8D “String” Config2.


    Die rechte Bildhaelfte ist ein “snapshot” eines durch AGDPfix GEPATCHTEN Eintrag in AppleGraphicsControl.kext —> Show Package Contents —> Contents —> Plugins -> AppleGraphicsDevicePolicy.kext —> Show Package Contents —> Info.plist “open with Xcode —> IOKitPersonalities —> AppleGraphicsDevicePolicy —> ConfigMap —> Mac-B809C3757DA9BB8D “String” none


    Also den einzigen Eingriff den AGDPfix unternimmt ist die Aenderung von “Config2” auf none in der info.plist, wie oben geschildert, weiter nichts. Ueberraschungen die mann bei dem Anbringen dieser Aenderung zu erwarten hat sind keine. Fuer diesen sogenannten Patch benoettigt mann noch nicht mal AGDPfix, weil mann alles per hand mit Xcode abwickeln kann.


    Ein UNGEPATCHTER so wie ein GEPATCHTER AppleGraphicsControl.kext ist auch im Anhang zu finden, so das jeder das oben geschilderte selber ueberpruefen kann, wenn er denn moechte. Also alles soweit "simple and straight forward" :-)


    Ein Umbenennen von "whatever" auf GFX1 oder "whatever, kann nichts bringen, NUR eine Anenderung der "system def" kann dem entgegenwirken. Also "system defs" waehlen die in dem "ConfigMap" Auszug schon Board-Id's besitzen die nativ auf "none" gesetzt sind. Das kaeme aber bei mir nicht in frage denn ich habe bewusst eine "system def" fuer meien iMeckie gewaelt so das die bei mir eingesetzte "Hardware mit der Harware die Apple mit dieser "system dev" anwended, soweit wie moeglich uebereinstimmt. Diese Massname gestalted halt das hacken letztlich viel Einfachher.


    OH jemineh :-) mir ist gerade ein Gedanke eingefallen das ohne Aenderung der "system def" aber eine Aenderung im SMBIOS Teil von Clover die "automatisch generierte Board-ID" auf eine Board-Id setzt, die schon vorab in der ConfigMap Nativ auf "none" gschalted ist, bewirken sollte das mann auch ohne "patching" das black screen Problem umgehen koennte. iMessage sowie
    Facetime werden dann warscheinlich den Geist aufgeben. Auch anderswo koennte es zu Aerger durch aenderung, "missmatch" der Board-ID und "system def", kommen. Muss mir das alles nochmal gruendlich durch den Kopf gehen lassen. Kann das alles leider erst Pruefen wenn ich wieder in 1 bis 2 Wochen daheim bin.


    Nun wuerde ich mich aber auch RIESIG freuen wenn einer derjenigen die weiter das Anwenden von Lilu.kext und Nvidiagraphicsfixup.kext befuerworten mal erklaeren wuerden was der Einsatz dieser kexte den so im System veraendert/anrichted, so in dem Stiehl wie hier oben fuer ADDPfix getan wurde. Das koennte bestimmt ein besseres “Verstaendnis” fuer deren Einsatz bei Skeptiker, wie mich erzeugen.


    Weil ich halt kein Hacker auf “gut Glueck” sein moechte werde ich mich weiterhin auf AGDPfix verlassen sodas Nvidia’s Webtreiber ihre Arbeit ungestoert verrichten koennen, ohne das ich dem etwas dagegen setze das ich, und viele andere auch, nicht verstehen. Alles Generell nur im Sinne meiner Algemeinen “keep it simple” Einstellung.


    Hacker die Lilu.kext mit nvidiagraphicsfixup.kext anwenden und nun auf Nvidia schimpfen weil ihre Hacks “laggy” geworden sind, und selbst auf aeltere Webtreiber zureuckgreifen, um ein nicht existierendes Nvidia Problem zu loesen, sollten sich mal besinnen und Ursachen ihrer Probleme woanders suchen, aber gewiss nicht bei Nvidia, auf deren Support wir, mit Nvidia GPUs, doch sehr angewiesen sind.


    Gruesse aus Namibia wo man unter anderem auch Namlish spricht

  • @armut Bitte IOReg Dumps nicht vom Terminal, sondern über den IORegistryEditor --> Save as. Außerdem ist der Fix mit deinem SMBios leider nicht möglich, mehr dazu gleich.


    @henties Ein sehr schöner Beitrag für einige :thumbup:

    Also den einzigen Eingriff den AGDPfix unternimmt ist die Aenderung von “Config2” auf none in der info.plist


    Der fix und die Problematik ist mir komplett klar. Die configs (wie Config2) werden, wie du sicherlich weißt, ebenfalls in der Info.plist definiert. Bei none wird AppleGraphicsDevicePolicy.kext nicht geladen.


    Config1 und Config3 stellen eine "unload" Funktion zur Verfügung. Auf diese kann statt dem AGDPFix zugegriffen werden. Besitzt das ACPI Device den Namen GFX1 und Config1 wird geladen, wird für dieses ACPI Device die AppleGraphicsDevicePolicy deaktiviert. Dies ist für die zweite GPU des MacPro6.1 vorgesehen, die keine Anschlüsse besitzt und GFX1 heißt. Jeder der Mac-F60DEB81FF30ACF6 benutzt kann also durchs umbenennen des Geräts in GFX1 die AppleGraphicsDevicePolicy umgehen – aber auch nur dieser. Bei @armut ist dies nicht der Fall, er benutzt iMac17,1 (und Mac-B809C3757DA9BB8D benutzt Config2).


    Jeder, der einen der neuesten iMacs als SMBios nutzt und somit auf Config3 zugreift, könnte AGDP umgehen, indem er die GPU in IGPU umbenennt und somit wieder unload betätigt. Das ist aber wiederum nicht wirklich sinnvoll, da IGPU noch in ein paar anderen Kexts matched und dort für Probleme sorgen würde.


    Ganz generell kann AGDP auch statt dem umbenennen auf none durch das aktivieren von unload deaktiviert werden. Das ist aber gehüpft wie gesprungen, die Info.plist wird dabei so oder so von Hand oder durch Script geändert, updateproof ist dies nicht.


    Anstatt durch script und somit updategefährdet zu verändern, bestand die Idee von lvs1974 darin, die Properties per Kext zu ändern.

    Nun wuerde ich mich aber auch RIESIG freuen wenn einer derjenigen die weiter das Anwenden von Lilu.kext und Nvidiagraphicsfixup.kext befuerworten mal erklaeren wuerden was der Einsatz dieser kexte den so im System veraendert/anrichted


    Schau dir den SourceCode an... Dieses Schnipsel ist von hier und beinhaltet nicht alle dependencies, lässt sich aber trotzdem relativ einfach verstehen, wenn die Problematik bekannt ist:


    Die BoardID (Mac-...) wird über das IOKit abgefragt und mit den BoardIDs in ConfigMap abgeglichen. Je nachdem was vorhanden ist, werden Properties neu gesetzt oder der Wert auf none gesetzt (ebenfalls abhängig vom ngfxpatch bootarg. Ngfxpatch=cfgmap wäre der "none" Eintrag; =vit9696 deaktiviert den kompletten Board-ID Check und =pikera ersetzt einfach Board-ID mit Board-IX, wodurch wie bei =vit9696 Default-->none geladen wird). Der Rest sind größtenteils nur Failsafes, falls beispielsweise ConfigMap nicht in AGDP vorhanden ist. Der Mechanismus ist also praktisch identisch zu der Idee von AGDPFix, nur halt in Kext-Form.


    Ich glaube es ist klar, dass eine Kext-basierte Lösung wesentlich besser/angenehmer als ein Script ist, ganz zu schweigen davon, dass dabei keine Apple-eigenen Daten dauerhaft verändert werden. NvidiaGraphicsFixup ist OpenSource, man muss also kein "kein Hacker auf “gut Glueck” sein". "Stricksachen, von Solo Artisten, die mann selber nicht versteht" müssen das auch nicht sein, nebenbei ist Lilu und NvidiaGraphicsFixup auch von zwei verschiedenen Entwicklern ;)
    Ich glaube trotzdem nicht, dass NvidiaGraphicsFixup perfekt und 100% durchdacht ist, denn wie man sieht passieren manchmal sporadische Fehler, erst recht dann, wenn man sich aus dem allgemein bekannten rausbewegt und gerne neue Wege eingeht.
    Ich sehe aber auch keinen Sinn darin Lilu und alle seine Plugins zu verheißen und zu umgehen, denn diese sind häufig sehr nützlich und beinhalten eine menge Wissen von Entwicklern die meist wissen was sie tun. Aber das soll sich jeder selber überlegen :)

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

    3 Mal editiert, zuletzt von kuckkuck ()

  • @kuckkuck
    Dann muss ich wohl vorerst damit leben und NVGF mit Lilu benutzen.


    Ich bevorzuge dennoch ein SMBIOS zu benutzen, welches mit meiner CPU übereinstimmt, sodass ich keine all zu vielen Veränderungen aufgrund der SpeedSteps vornehmen muss.
    @henties hat mich daraufhingewiesen, dass bei mir im IOReg CPU0@0 der EIntrag PluginType fehlt, welches ich eben ergänz habe.


    Mir ist aufgefallen, dass die QuickSync beim Rendern in MacX von etwa 400Mhz auf knapp 750MHz gestiegen ist. Ich gehe mal davon aus, dass immer noch Optimierungspotenzial vorhanden ist, da die IGPU im Boost 1,15Ghz schaffen soll.
    Es ist mit allerdings immer noch nicht gelungen, QuickSync beim Export von BruceX zum Laufen zu bringen.

  • Darf ich bitte noch mal eine Frage zu shikigva stellen? Es wurde der Wert 60 genannt. Welcher Wert ist denn nun vernünftig? Ich frage ja nur, weil ich diesen ganzen Erklärungen kaum folgen kann – ich hab da einfach ein Loch im Hirn – aber mich über einfache Erklärungen wie z.B. "Frag doch mal die Maus" sehr freue.

    • FANLESS II 500/600 Watt Netzteil Platinum 0dB(A)!
    • ASRock Z370 Pro4
    • intel Core i5-8400
    • 32GB DDR4-2133 Crucial 4x8GB
    • SSD SATA3 1000GB Samsung 850 EVO
    • LG GH-24NS DVD-Brenner
    • SAPPHIRE PULSE Radeon™ RX 570 8GD5
    • onBoard HD-Sound 6/8Kanal
    • Card Reader intern
    • Dual BOOT mit WIN10 Pro
  • @armut Kleine Anmerkung: Ein SMBios, das möglichst nah an deinem Prozessor ist, muss noch nicht einmal die besten Speedsteps für deinen Prozessor haben, solltest du XCPM nutzen. Manchmal ist es auch sinnvoller das SMBios nach der GPU zu wählen. Aber das ist ein anderes Thema ;)
    Hast du mal die iGPU im BIOS deaktiviert und einen BruceX Test gemacht und die Zeit mit einem Test bei aktivierter connectorloser iGPU verglichen? Mit was misst du die iGPU Frequenz?


    @lifesupporter Es gibt da keinen pauschal vernünftigen Wert, denn sollte es so einen geben, wäre er längst Standard. Vielmehr wird das Bootarg gesetzt wenn es Probleme gibt und der Wert je nach Problem gewählt.
    Hast du zB Skylake oder Kabylake Hardware und Decoding funktioniert laut VDADecoderChecker nicht, ist =4 einen Versuch wert. Hast du hingegen iTunes Abstürze mit macOS 10.13, solltest du =16 probieren. Alle Werte findest du im Changelog oder in der Wiki zu Shiki. Brauchst du mehrere Fixes, werden die Werte addiert. Für iTunes Abstürze + Skylake wäre es dann zB einfach =20 ;)

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

  • XCPM nutze ich (soweit mir bekannt) nicht, habe mich damit auch ehrlich gesagt noch nicht beschäftigt.
    Das ist auch interessant (SMBIOS-GPU). Gibt es hierfür auch etwas zum Nachlesen, Pros vs. Contras?


    Die IGPU im BIOS deaktiviert und dann BruceX getestet habe ich noch nicht. Würde ich aber auch demnächst machen und reporten.
    Die Taktfrequenz der IGPU lese ich anhdan Intel Gadget und iStatMenus. Beide zeigen so ziemlich den selben Takt an.

  • Dann ist diese Meldung von unter "Erfolg" zu verbuchen?


    Last login: Mon Jan 29 17:29:00 on console
    Franks-iMac:~ frank$ /Users/frank/Downloads/VDADecoderChecker ; exit;
    GVA info: Successfully connected to the Intel plugin, offline Gen9
    Hardware acceleration is fully supported
    logout
    Saving session...
    ...copying shared history...
    ...saving history...truncating history files...
    ...completed.
    Deleting expired sessions...10 completed.


    [Prozess beendet]


    Aktuell hab ich die 60 drin. Sollte ich dann wohl einfach lassen?

    • FANLESS II 500/600 Watt Netzteil Platinum 0dB(A)!
    • ASRock Z370 Pro4
    • intel Core i5-8400
    • 32GB DDR4-2133 Crucial 4x8GB
    • SSD SATA3 1000GB Samsung 850 EVO
    • LG GH-24NS DVD-Brenner
    • SAPPHIRE PULSE Radeon™ RX 570 8GD5
    • onBoard HD-Sound 6/8Kanal
    • Card Reader intern
    • Dual BOOT mit WIN10 Pro
  • @armut Guide: Nicht das ich wüsste... Aber da gibt es auch so viele Abhängigkeiten, dass kann man fast garnicht in einem Guide zusammenfassen, wo das SMBios überall reinspielt.


    @lifesupporter Yes, das ist ein gutes Ergebnis. Setz keine Bootargs, die du nicht brauchst! Probiers lieber mal ohne und wenn dann Decoding nicht geht, mit der =4. Wenn damit dann alles funktioniert, belass es dabei. 60 aktiviert so ziemlich alles, das ist nicht nötig!

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

  • @lifesupporter Die "60" sind mir auch ein Rätsel. Sicherheitshalber habe ich auch andere Werte eingetragen (1,4,8) hat immer dazu geführt, dass QuickSync nicht aktiviert wurde.

  • Bestätige: 4 Passt auch.
    Allerdings haut der Checker dann diesen raus:


    Last login: Mon Jan 29 18:08:34 on ttys000
    Franks-iMac:~ frank$ /Users/frank/Downloads/VDADecoderChecker ; exit;
    GVA info: Successfully connected to the Intel plugin, offline Gen9
    AVDCreateGPUAccelerator: Error loading GPU renderer
    VDADecoderCreate failed. err: -12473
    An error was returned by the decoder layer. This may happen for example because of bitstream/data errors during a decode operation. This error may also be returned from VDADecoderCreate when hardware decoder resources are available on the system but currently in use by another process.
    VDADecoderCreate failed. err: -12473
    logout
    Saving session...
    ...copying shared history...
    ...saving history...truncating history files...
    ...completed.


    [Prozess beendet]


    Wasndas?

    • FANLESS II 500/600 Watt Netzteil Platinum 0dB(A)!
    • ASRock Z370 Pro4
    • intel Core i5-8400
    • 32GB DDR4-2133 Crucial 4x8GB
    • SSD SATA3 1000GB Samsung 850 EVO
    • LG GH-24NS DVD-Brenner
    • SAPPHIRE PULSE Radeon™ RX 570 8GD5
    • onBoard HD-Sound 6/8Kanal
    • Card Reader intern
    • Dual BOOT mit WIN10 Pro
  • Die 60 wurde auch nur in einem Issue auf Github erwähnt, bei Tests zu HW Decoding bei installierter Nvidia 1080, Kabylake und iMac18,3 SMBios... Kommt nicht auf die Idee das als Standard zu nutzen!


    @lifesupporter Dann probiers mal mit zusätzlich 8 und eventuell auch 32... Also zB mal mit nur 8 oder 4+8=12, oder 4+32=36...

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.