staging.inyokaproject.org

Hy, da mich die Nvidia-Treiber zunehmend nerven (Insbesondere dass man sich abmelden muss, um zwischen Intel- und Nvidia-Grafik zu wechseln) habe ich meine Quadro K5000M gegen eine AMD Fire Pro M6100 getauscht. Leider ist die mit meinem Dell M6700 nicht 100% kompatibel. Das BIOS kennt die Karte nicht und deaktiviert Enduro. Das heißt, die Intel-Grafik wird per lspci nicht angezeigt. Außerdem gibt es Probleme mit Blackscreens, insbesondere nach dem Standby.

Ich müsste also noch mal auf das Vorgängermodell M6000 downgraden - aber kann Linux (Ubuntu 18.04) inzwischen zufriedenstellend gut mit Enduro umgehen?

Wenn ich mich da auch jedes Mal abmelden muss, kann ich auch bei Nvidia bleiben... Wer hat ein AMD-Hybridgrafik-System und kann berichten?

Für welche Anwendungen benötigst du diese speziellen CAD Karten?

Prime an sich funktioniert, aber ...

Wenn Nvidia stabil läuft, würde ich erst mal dabei bleiben und auf die AMD APUs warten.

Naja - ich brauche nur eine einigermaßen flotte Grafikkarte. Video Encoding, Spiele, etc.

Das Workstation-Laptop brauche ich wegen der Ausstattung. Für Unterwegs will ich schon gerne die Intel-Grafik nutzen. Auf Windows war das mit meiner K5000M auch überhaupt kein Problem, aber auf Linux... AMD hat ja die Treiber Open-Source gemacht. Deswegen läuft damit auch HDMI-Audio sofort problemlos. Hatte ich mit Nvidia nie hinbekommen.

Der Witz ist, dass ich extra eine Veranstaltung belegt hatte, um Cuda zu lernen, und jetzt, wo ich's kann, will ich's nicht mehr^^ Der Nouveau-Treiber unterstützt offenbar das nahtlose Umschalten der Grafikkarte, aber man merkt halt nichts davon, weil die Nvidia-Karte damit genau so langsam ist, wie die Intel-Grafik. Und Cuda kann der sowieso nicht. Prime ist halt in Sachen Usability ein Witz.

Wenn ich Enduro unter Linux bekommen kann, werde ich zu Gunsten von AMD gerne auf etwas Grafik-Leistung verzichten. So lange es für meine Uralt-Games reicht... Vielleicht wird es Zeit mal auf die neuste Generation Intel CPUs mit AMD-Vega-Grafik umzusteigen und halt keine dedizierte GPU mehr zu haben. Ist zwar cool, aber wenn Nvidia es nicht für nötig hält, ordentliche Treiber zu machen und man sowieso nicht auf neuere Grafikkarten umsteigen kann, weil die Laptophersteller es nicht für nötig halten, neue BIOSSe zu machen und man Jahr um Jahr 'n Haufen Geld für Schrott zahlt, der schon nach monaten wieder outdated ist, dann halt nicht 👿

MitjaStachowiak schrieb:

Insbesondere dass man sich abmelden muss, um zwischen Intel- und Nvidia-Grafik zu wechseln

"Wechseln" ist das falsche Wort, denn zum Wechseln musst du immer den X Server neustarten. Der Unterschied liegt darin, dass du bei den freien Treibern gar nicht wechseln musst um die 3D Beschleunigung für bestimmte Programme von einem anderen Chip zu beziehen, du teilst den zuständigen Bibliotheken beim Programmstart einfach via Umgebungsvariable mit welchen Grafikchip er stattdessen benutzten nehmen soll.

MitjaStachowiak schrieb:

Das BIOS kennt die Karte nicht und deaktiviert Enduro.

Enduro ist erst einmal nur Marketing Geblubber, dahinter steckt keine konkrete technische Lösung, bei Optimus sieht es nicht anders aus. Es gibt keinen großen technischen Unterschied zu zwei Desktop Karten die parallel in einem PC betrieben werden, man hat im wesentlichen nur die Möglichkeit eingebaut dass sich diese Chips komplett abschalten lassen. Die große Besonderheit liegt eher in dem was gerade nicht explizit zu Enduro und Optimus zählt, weil dieser Ansatz von den Chipherstellern bereits früh aufgrund der hohen Zusatzkosten verworfen wurde: Der Multiplexer, der dir erlaubt, dass du ohne die Intel GPU überhaupt ein Bild bekommst. Das Ding sollte normalerweise im BIOS konfigurierbar sein - üblicherweise ohne dass einer dieser Marketingbezeichnungen dafür verwendet wird.

MitjaStachowiak schrieb:

Außerdem gibt es Probleme mit Blackscreens, insbesondere nach dem Standby.

Versuch's mal mit Suspend-to-Disk anstelle von Suspend-to-RAM. Das System kann dabei einen regulären Start vollziehen und ist nicht darauf angewiesen, dass Hardware und Firmware auch kooperieren - dafür braucht es halt ein klein wenig länger. Alternativ kannst du auch dein Glück mit dem amdgpu Modul versuchen, wenn du mehr wie OpenGL benötigst kommst du da ohnehin nicht drumherum.

MitjaStachowiak schrieb:

Der Nouveau-Treiber unterstützt offenbar das nahtlose Umschalten der Grafikkarte

Konzeptioneller Fehler: Es gibt kein "nahtloses Umschalten", da es nicht möglich ist ein Programm einfach so auf einen anderen Grafikchip zu migrieren. Hier wird auch unter Windows nur mit Whitelists gearbeitet, die dem Treiber vor dem Start mitteilen, auf welchen Chip das Ding umgebogen werden muss. Diese Funktionalität wird unter Linux von niemanden gepflegt, man kann zwar theoretisch über DRIconf sowas selbst einrichten, aber die Option dafür ist schlecht dokumentiert und nicht Bestandteil der GUI, das müsste man von Hand in die Konfigurationsdatei eintragen.

Der Multiplexer, der dir erlaubt, dass du ohne die Intel GPU überhaupt ein Bild bekommst. Das Ding sollte normalerweise im BIOS konfigurierbar sein - üblicherweise ohne dass einer dieser Marketingbezeichnungen dafür verwendet wird.

Ja, mein Dell hat glücklicher/ärgerlicher Weise so einen Multiplexer. Der lässt sich im Bios unter Video->"Optimus Aktivieren" einschalten und dann habe ich beide Grafikkarten. Naja - mit der AMD-Karte ist diese Option nun verschwunden und die Intel Grafik ist nicht sichtbar. Ich vermute, wenn das BIOS die Karte kennt, würde dort "Enduro Aktivieren" stehen.

Also der Open Source-Treiber von AMD erlaubt es, einzelne Programme auf der dedizierten Karte zu starten und kann die AMD-Karte dann per Enduro abschalten, wenn sie nicht benötigt wird?

Nicht mehr und nicht weniger möchte ich erreichen 😉 Habe per Google aber noch nichts aktuelles gefunden, was eine klare Aussage hierzu liefert.

Ich vermute, ich muss dann diese 3D-Anwendungen mit ein paar extra-Commands per Terminal/individueller .desktop-Datei starten?

Open Source-Treiber von AMD erlaubt es, einzelne Programme auf der dedizierten Karte zu starten und kann die AMD-Karte dann per Enduro abschalten, wenn sie nicht benötigt wird?

Äh, wie bitte du schmeißt hier mit Cuda, OpenCL und Workstation Spezialkarten rum und hast dir noch nicht den Prime Mechanismus angesehen? 😲

Jetzt aber los ...

https://wiki.ubuntuusers.de/Hybrid-Grafikkarten/PRIME/

Deswegen läuft damit auch HDMI-Audio sofort problemlos. Hatte ich mit Nvidia nie hinbekommen.

Das kann andere Gründe haben, je nachdem wie das hardwareseitig beim Laptop verdrahtet ist. Dazu gibt es viele schöne Threads hier.

Ist zwar cool, aber wenn Nvidia es nicht für nötig hält, ordentliche Treiber zu machen

Der Nvidia Treiber ist O.K., die Linux Leute hatten immer Probleme mit Hybrid und Optimus. Bei Enduro lief sehr lange gar nix, gab es bei Nvidia immerhin Bumblebee.

Da du die die GPU für Videobearbeitung nutzen willst, benötigst du im übrigen den amdgpu pro. Wobei ich jetzt natürlich nicht weiß, welche Schnittstelle deine Anwendung nutzt. Ist auch nicht mein Ding, ich höre immer nur, daß GPU an dieser Stelle überhaupt keine gute Idee ist, weil da nur Müll/miese Qualität produziert wird.

Ich verstehe auch immer noch nicht, warum du diese Spezi Karten nutzt. Das ist doch Masochismus. Diese Karten sind für zertifizierte Windows Anwendungen gedacht, die damit eine maximale Unterstützung garantieren. Unter Linux gibt das Bruch.

Das sind unheimlich viele Baustellen, ich bin da wirklich etwas ratlos. Letalis hat sich ja viel Mühe gegeben, die technische Seite zu erläutern, aber was ist nun der Rat für die Praxis.

Fazit: Nvidia nutzen/leiden und dann irgendwann mal eine APU. Aber vorher die amdgpu pro Kiste checken!

hakel schrieb:

Ist auch nicht mein Ding, ich höre immer nur, daß GPU an dieser Stelle überhaupt keine gute Idee ist, weil da nur Müll/miese Qualität produziert wird.

Das kommt daher, dass nicht die GPU sondern zusätzlich verbaute Co-Prozessoren zum Einsatz kommen. Die GPU selbst ist für Videocodecs nicht zu gebrauchen, alles was nicht mit reiner Mathematik gelöst wird ist ein Performance Killer, logische Verzweigungen sind unerwünscht und müssen durch das Ausnutzen von mathematischen Synergien in eine Formel umformuliert werden - da bringt einem OpenCL auch nicht mehr weiter, das macht nur für die Bearbeitung von Rohdaten Sinn. Jene Co-Prozessoren sind wiederum auf Echtzeit-Fähigkeit hin optimiert und gehen bei aufwändigeren Rechenpfaden eher faule Kompromisse ein.

Wer bei der Videobearbeitung keine aufwändigen Filter benötigt und mehr Wert auf Qualität legt, der lässt die CPU schuften.

In Sachen VDPAU/VA-API/OpenMAX kann man sich das Pro Zeugs sparen, das ist der gleiche Software Stack der schon beim radeon benutzt wird.

hakel schrieb:

Ich verstehe auch immer noch nicht, warum du diese Spezi Karten nutzt. Das ist doch Masochismus.

Viel Spaß dabei eine vergleichbare Consumer Karte auf einem kompatiblen MXM Modul zu finden...

hakel schrieb:

Diese Karten sind für zertifizierte Windows Anwendungen gedacht, die damit eine maximale Unterstützung garantieren. Unter Linux gibt das Bruch.

Die ~10 Jahre alte FireGL in meinem Notebook hat mir jedenfalls noch nie Probleme bereitet, ganz im Gegenteil. Mit ihrem überdurchschnittlich großem VRAM war sie sehr lange noch durchaus zum Zocken mit dem Pinguin geeignet...

Sieht so aus als würde der Dell Enduro überhaupt nicht unterstützen. Kein Bug, sondern Feature. ☹

Recherchier mal selber ...

Dann können wir uns die Diskussion sparen.

@Letalis

Um VAAPI/VDPAU,OpenGl Gaming und Probleme geht es ja nicht. Frage ist, ob Enduro/Prime Mechanismus ohne Neuanmeldung, aber bitte mit OpenCL eine gute Idee , bzw. überhaupt möglich ist. Daß Nvidia proprietär nervt, kann man nachvollziehen.

So hatte ich den TS verstanden.

hakel schrieb:

Sieht so aus als würde der Dell Enduro überhaupt nicht unterstützen. Kein Bug, sondern Feature. ☹

Dieses Modell ist auch direkt mit einer FirePro M6000 erhältlich, die Quadro kam erst ein halbes Jahr später überhaupt ins Sortiment. Daher auch der Kommentar dass er es mit diesem Chip versuchen würde.

Dell kann hier auch schlicht und ergreifend wie zu guten alten Thinkpad Zeiten einfach eine HW Whitelist in die Firmware eingepflanzt haben, an die dieser Funktionsumfang gekoppelt wurde. Unschön wird es dann, wenn der überprüfte Teil ein von Dell selbst eingepflanztes Detail wie die Subvendor-ID ist...

Wenn ich mir mal das hier durchlese dann scheint die Firmware schlicht und ergreifend eine Karte mit einer ihr unbekannten ID nicht zuordnen zu können. Es dürfte weniger daran liegen dass das Board Enduro mit dieser Karte nicht unterstützt, sondern dass der Firmware schlichtweg nicht bekannt ist das dieser Chip dementsprechend angesteuert werden kann. Der abenteuerliche und kundige Hacker könnte dies wahrscheinlich direkt im BIOS Code anpassen oder gar gegen einen Hersteller-ID Check ersetzen um es bei allen kompatiblen MXM Modulen zu aktivieren, diesbezüglich war man bei den alten Thinkpads auch noch sehr erfinderisch.

hakel schrieb:

Frage ist, ob Enduro/Prime Mechanismus ohne Neuanmeldung, aber bitte mit OpenCL eine gute Idee , bzw. überhaupt möglich ist.

Erst einmal stellt sich die Frage, ob OpenCL überhaupt nötig oder sinnvoll ist. Wie schon angesprochen ist das auch bei der Videobearbeitung nicht unbedingt der Fall. Wenn es nicht gebraucht wird, kann einem das herzlich egal sein.

Mit der FirePro sollte das Treiber-seitig über amdgpu kein Problem sein. Wenn man das Pro Paket installiert werden die Komponenten die für den Betrieb der Intel GPU benötigt werden höchstens aktualisiert, nicht durch proprietäre inkompatible Blobs ersetzt - die OpenCL Komponente müsste sich sogar separat installieren lassen. Zukünftig steht mit ROCm auch noch eine andere komplett freie (und im Gegensatz zu Clover auch vollständige) Implementierung zur Verfügung, diese hat bisher nur eine sehr eingeschränkte Auswahl an unterstützten GPUs, da man den heterogenen Einsatz angestrebt hat sowie allgemein deutlich näher an der Hardware arbeitet als es bisher bei OpenCL üblich war.

Nvidia hat ihr CUDA Backend weitgehend vom Rest des Treiberpakets isoliert, aber ob sich dieses ohne weiteres isoliert nutzen lässt ist immer noch fragwürdig...

Nachtrag: Es ist tatsächlich so, dass das ältere Modell mit der FirePro M6000 die Intel GPU überhaupt nicht verwendet und totschaltet - es wurde als Single-GPU System verkauft. Diesen Umstand hat man anscheinend bei der Modellpflege nicht geändert sondern nur an das Vorhandensein einer Nvidia GPU gekoppelt. Stellt sich nur die Frage, ob sich dies möglicherweise durch ein modifiziertes BIOS ohne weiteres ändern lässt, oder ob es sich hier möglicherweise um eine sehr frühe Optimus Implementierung handelt, die noch sehr viel spezieller ausfällt als das was man heute von der Stange kriegt.

Ich erkläre mich noch mal präziser: Mit meiner Nvidia-Karte habe ich viel Erfahrung gesammelt. Mit dem Nouveau-Treiber kann man einzelne Anwendungen auf der Nvidia-Karte starten, wären der Desktop von intel gerendert wird. Der Nouveau-Treiber kann die Nvidia-Karte dann auch per Optimus abschalten. ABER: Die Grafikleistung meiner Quadro K5000M mit Nouveau ist etwa gleich auf, wie die der Intel-Grafik. PC-Games kann man damit vergessen. Das liegt eben daran, dass die Entwickler von Nouveau NULL Unterstützung von Nvidia bekommen.

Ich habe stattdessen also immer den proprietären Treiber installiert. Damit kann man entweder nur die Intel- oder nur die Nvidia-Grafik nutzen und muss sich zum Umschalten abmelden. Ich hatte es auch erlebt, dass es dabei auf einmal einen Fehler gab und der Bildschirm nach der Anmeldung schwarz blieb. In diesem Fall musste ich dann Optimus im BIOS deaktivieren, konnte so wieder auf die Intel umschalten und dann nurnoch die nutzen. Per Treiberneuinstallation konnte ich dieses Problem nicht lösen und musste Linux neu machen. Mit 18.04 gab es wieder ähnliche Probleme. Das meine ich mit "Der Nvidia-Treiber nervt".

Wer einen PC mit Nvidia-Karte hat, oder Optimus nicht nutzen möchte, kann mit diesem Treiber glücklich werden. Der mobile Nutzer nicht. Bumblebee hatte ich auch mal versucht, aber schon unter 17.10 nicht mehr zum Laufen gebracht.

Jetzt zu AMD. AMD hat, wie Intel auch, die Grafiktreiber Open Source gemacht. Deswegen kann ich mit dem linuxeigenen Treiber auch die volle Leistung dieser Karte nutzen. Ich möchte hier einfach mal Fragen, ob jemand ein Hybrid-System mit Intel und AMD-Grafik hat und bestätigen kann, dass man damit einzelne Anwendungen auf die AMD-Karte bringen kann UND Linux diese Karte über Enduro abschalten kann.

Ob mein Dell dann mit der "voll unterstützten" Fire Pro M6000 Enduro anbietet, oder man faul war und nur für Nvidia die Hybrid-Lösung umgesetzt hat, ist dann die nächte Frage. @Letalis:

Es ist tatsächlich so, dass das ältere Modell mit der FirePro M6000 die Intel GPU überhaupt nicht verwendet und totschaltet - es wurde als Single-GPU System verkauft.

Vermutlich hast du Recht :-/ Muss mich wohl erstmal wieder mit Nvidia 'rum plagen. Erfahrungsgemäß ist im Dell-Bios einfach eine Whitelist, die das Featureset steuert. Wenn ich mit meiner M6100 jetzt das TPM aktiviere, wird das Laptop vermutlich gar nicht erst booten. Das ist halt das Leidige an professionellen Laptops. Für die üblichen Gaming-Kübel gibt es Communities, wo ein paar (V)BIOS-Modder noch neuere Grafikkarten "freischalten". Für Alienware macht Dell das sogar selbst. Für mich sind diese Gaming-Laptops aber einfach nicht das richtige.

Und 'ne GTX oder Radeon-Karte in eine Workstation zu kloppen ist wegen BIOS-Problemen auch meist keine gute Idee. Würde die Treiberprobleme mit Hybridgrafik ja auch nicht lösen.

Video-Encoding: Ja, die Qualli der GPU-Encoder ist nicht soo gut, wie die der CPU. Aber es ist schnell, energiesparsam und für Urlaubsvideos oder TV-Aufnahmen durchaus brauchbar. Auf Windows war der Asieesoft-Converter das einzige Programm, mit dem ich auf der Nvidia-Karte codieren konnte. Die GPU-Auslastung lag dabei bei 5% und das Encoding war genau so schnell, wie mit der Intel-Grafik. Es gibt dabei offenbar einfach nicht genug Parallelität auf hinreichend kleinen Datenmengen um Tausend oder mehr ALUs im SIMD-Betrieb auszulasten.

Für die Intel-Encoder gibt es deutlich mehr Programmunterstützung. Auch deswegen will ich eigentlich gerne ein Hybrid-System haben.

Ich habe wie gesagt mal eine (sehr) einfache Volume Data Compression mit Cuda geschrieben und mehr als 20% GPU-Auslastung wären äußerst schwer erreichbar gewesen. Dafür hätte ich gemäß Profiler wohl Latency-Hiding zwischen Global Memory und L1-Cache betreiben müssen... GPU-Programming macht zwar spaß, aber auch das scheitert für mich an zu geringer Auswahl an Compilern und Programmiersprachen, keiner einheitlichen Entwicklungsumgebung für Windows und Linux, sowie keiner Möglichkeit, wenigstens einfache Programme von Cuda aus auch nach Open CL oder Vulcan zu übersetzen. Cuda ist halt eine Insel, die ausschließlich für Forschung und ein paar Medizin-Tools interessant ist. Für Firmen, die Anwendersoftware entwickeln wäre das der finanzielle Ruin. Deswegen gibt es für Anwender bestenfalls Open CL.

MitjaStachowiak schrieb:

Ich möchte hier einfach mal Fragen, ob jemand ein Hybrid-System mit Intel und AMD-Grafik hat und bestätigen kann, dass man damit einzelne Anwendungen auf die AMD-Karte bringen kann UND Linux diese Karte über Enduro abschalten kann.

Funktioniert genau wie bei nouveau, sind die gleichen Frameworks die im Hintergrund dafür zuständig sind. Nur läuft es halt im Gegesatz zu nouveau deutlich problemfreier und vor allem mit ordentlich Leistung.

Die Treiber beschränken sich auf die konkrete Ansteuerung des Chips - alles was zwischen den Treibern geteilt werden kann, wird auch geteilt und dafür in separate Treiber-unabhängige Komponenten isoliert.

MitjaStachowiak schrieb:

Es gibt dabei offenbar einfach nicht genug Parallelität auf hinreichend kleinen Datenmengen um Tausend oder mehr ALUs im SIMD-Betrieb auszulasten.

Parallelität alleine reicht nicht. Logische Verzweigungen sind zwar auch auf Shadern möglich, aber mit einem geradezu apokalyptischen Leistungseinbruch - Branch Prediction etc gibt es hier schlichtweg nicht, man will einen absolut linearen Programmablauf.

Wenn du zB den Programmablauf davon abhängig machst, ob eine Variable den Wert 0 annimmt, dann kannst du hier, wenn dir die Leistung wichtig ist, keine if() Bedingung einbauen sondern musst die darauf folgende Berechnungsformel so formulieren, dass du diese Variable genau so einbaust, dass sich dieser Effekt mathematisch ergibt, zB indem du gezielt über die Multiplikation mit dieser Variable einen Summanden neutralisierst (statt boolescher Werte werden dann eben direkt in den Formeln die jeweils sinnvollen neutralen bzw absorbierenden Elemente verwendet) - das wird bei komplexeren Bedingungen extrem schwierig bis unmöglich.

Wenn der Workload dazu nicht passt, dann hat man eben auch bei entsprechender Parallelität keine Vorteile.

MitjaStachowiak schrieb:

Für die Intel-Encoder gibt es deutlich mehr Programmunterstützung. Auch deswegen will ich eigentlich gerne ein Hybrid-System haben.

Läuft das dort nicht einfach über VA-API? Kannst du mit radeon/amdgpu ebenfalls nutzen, sowohl die UVD als auch die VCE. Zusammen mit OpenMAX sind alle gängigen Schnittstellen verfügbar, sowohl fürs Encoding als auch fürs Decoding. Diesbezüglich sind die Treiber allen anderen voraus.

Hier fällt mir als einziger Ausreißer nur NVENC ein, was Nvidia als Eigenbrötlerei fürs Encoding eingeführt hat anstelle VDPAU um die Encoding Fähigkeit zu erweitern.

MitjaStachowiak schrieb:

Cuda ist halt eine Insel, die ausschließlich für Forschung und ein paar Medizin-Tools interessant ist. Für Firmen, die Anwendersoftware entwickeln wäre das der finanzielle Ruin. Deswegen gibt es für Anwender bestenfalls Open CL.

Nö, ist im wesentlichen nur das gleiche in grün, die Schnittstellen stehen durchaus in direkter Konkurrenz. OpenCL kam schlichtweg erst ziemlich spät in Fahrt und Nvidia hat es systematisch vernachlässigt, damit man mit CUDA einen schönen Vendor Lock-in errichten kann. OpenCL 2.0 ist bis heute in Nvidia's Treiber nur "available for Evaluation purposes", und selbst diese eingeschränkte Unterstützung gibt es erst seit etwa einem Jahr - bei AMD kriegst du OpenCL 2.0 ganz offiziell seit 2014.

AMD hat übrigens im Rahmen der OpenCompute Initiative reichlich Tools für eine Interoperabilität entwickelt, davon auch einiges zum Thema CUDA.

Deine Hardware unterstützt Enduro nicht, daher läuft nur die dedizierte "stromfressende" Karte.

Wenn ich Enduro unter Linux bekommen kann, werde ich zu Gunsten von AMD gerne auf etwas Grafik-Leistung verzichten.

War für dich doch ein K.O. Kriterium, oder? Diskussion beendet ...

Linux ist unschuldig! 😀

P.S. Möglicherweise kannst du den Ärger mit Nvidia etwas reduzieren mit einem simplen 2D Desktop wie Mate oder Xubuntu.

Ok, gut zu wissen, dass AMD und Intel in Sachen GPU-Encoder im Prinzip die gleiche Schnittstelle verwenden. Alles andere hätte mich im Bezug auf die neuen AMD Vega-Chips auch gewundert... Hatte halt für den Nvidia-Encoder kaum Software gefunden.

Ich glaube ehrlichgesagt nicht, dass es hier an der Verzweigung liegt. Verlustbehaftete Encoder würde ich als eher verzweigungsarm in den Algorithmen einstufen, aber vielleicht ist das bei H.264 auch anders. Man hat halt nur sehr wenig Speicher als Register oder L1/Shared-Memory. Alles andere ist zum aktiven rechnen einfach zu langsam. Wenn man auf den wenigen Daten in L1 nicht genug Rechnungen ausführen kann, ist die GPU halt langsam. Man kann in Cuda glaube ich durchaus auch mit einem kompletten Multiprozessor branchen. Branch Prediction gibt es nicht - der Compiler soll hier möglichst guten Code ausspucken. Da dieser immer für eine bestimmte GPU-Generation compiliert wird, ist das auch besser möglich, als bei CPUs.

Da mein Laptop offenbar kein Enduro kann, werde ich mir die M6000 nicht holen und habe jetzt die K5000M wieder 'rein geschraubt. Vermutlich wird mein nächstes Laptop dann ein AMD-Vega System ohne dedizierte Grafikkarte. Auch wenn ich dann vermutlich genug Geld für die neuste Nvidia-Karte haben werde. Aber der Treiber ist einfach ein Ausschlusskriterium. Gerade darf ich mich wieder freuen, dass es in Firefox beim Scrollen ruckelt, die Systemschriftarten zu klein sind und der Desktop nach dem Hochfahren Darstellungsfehler hat. Passiert mit Nouveau alles nicht. 🙄

Dann man einen neuen Thread auf und löse das Problem mit Nvidia.

Zur Zeit gibt es offfenbar eine Menge Ärger mit Bionic und dem proprietären Treiber.

Weiche dem Problem aus mit einem 2D Desktop.

Letalis ist zwar begeistert von diesen CAD Karten, aber es gab auch Leute mit Problemen hier.

P.S. war schon mal schlimmer ... 👍

Ich öffne mal wieder dieses alte Thema. Also inzwischen hat Nvidia auch nachgebessert und das prime-switching mitels DRI_PRIME=1 Umgebungsvariable funktioniert. ABER: Das geht auf Linux nur mit neueren GPUs. Mit meinem K5000M-System ging zwar Optimus auf Windows, aber auf Linux weiterhin nur mit Neustart.

Hatte mir ein Dell 7720 gebraucht geholt, glaube mit Nvidia P3000 und da ging das starten von einzelnen Anwendungen auf der Nvidia-GPU plötzlich. Irgendwo in einem Artikel hatte ich auch gelesen, dass bei den neueren Generationen das Abschalten etwas anders funktioniert.

Nun, ich habe mir dann trotzdem eine AMD-Karte eingebaut. Ich würde gefühlt aber sagen, dass der Linux-Support für dedizierte AMD-Karten doch eher mäßig weiterentwickelt wurde. Aktuell zieht mein Laptop wieder mehr Strom - da beim 7720 CPU und GPU an der selben Heatpipe hängen, kann ich nicht sagen ob diese Strom zeiht. Was mich zur der Frage führt, wie man bei Linux die GPU-Auslastung von AMD-Karten abfragen kann. Ggf. auch eine Liste aller Programme, die mit DRI_PRIME=1 laufen...

sudo DRI_PRIME=1 radeontop liefert nur ein Cannot access GPU registers, are you root?