Hallo mtron!

mtron schrieb:

Schön dass sich jemand dieser Sache annimmt. So einen Artikel zu supporten wird eine menge Arbeit

Nur zu

Erstmal ist es wichtig auf die verschiedenen Hardware Gegebenheiten hinzuweisen:

- Dual-GPU Laptops der ersten Generation: Diese Laptops verfügen über einen im Prozessor integrierten GPU der standardmäßig aktiv ist und einen dezidierten GPU. Solche Laptops der ersten Generation haben einen Schalter im BIOS mit dem man einstellen kann welcher GPU Modus aktiv sein soll. Hardwareseitig sind beide GPU's mit dem Bildschirm verkabelt und können diesen verwenden

- Dual-GPU Laptops der zweiten Generation: Diese Laptops haben keinen eigenen Schalter im Bios mit dem man den VGA Chip wählen kann, sondern der im CPU integrierte Grafik Chip ist standardmäßig aktiv und der dezidierte Chip fristet ein parasitäres Dasein, da er nur Strom frisst und (ohne Bumblebee) unter Linux keine weitere Funktion hat. Hardwaremäßig verfügen diese dezidierten Chips über keinen eigenen Mux zum Display sondern können nur über einen Framebuffer des im CPU integrierten GPU's auf den Bildschirm malen (das klingt jetzt ziemlich blöd auf deutsch, im english ist es logischer: 'Those dedicated GPU's can only draw to the screen via the framebuffer of the primary device').

- Dual GPU Laptops der dritten Generation: Diese Klasse hat auch keinen eigenen Schalter im Bios, jedoch kann man via einem acpi-call den Grafik Modus für den nächsten Boot wählen. Es stehen hier drei Grafik Modi zur Verfügung: Nur der im CPU integrierte GPU, Nur der dezidierte GPU und ein Dual-GPU Modus (Dies ist der eigentliche 'Optimus' Modus). Solche Laptops der dritten Generation erkannte man daran dass diese einen HDMI Ausgang haben (bevor die intel Sandybridge CPU's eingeführt wurden konnten die im CPU integrierten GPU's kein HDMI Device ansteuern), Die dezidierten Chips dieser Generation haben einen Hardware mux der es erlaubt direkt auf das Display- Device zuzugreifen und verwalten den HDMI Port exklusiv.

Könnte man so ähnlich übernehmen.Wenn es nicht zu viel Information ist. (?)

Nun zu Bumblebee:

Bei den Geräten der zweiten Generation hat der User die Wahl: 1) den dezidierten Chip mittels eines acpi_calls auszuschalten um so Energie zu sparen 2) einen weiteren X-Server am dezidierten GPU zu starten dessen Fenster sich in den primären Xserver "einnisten". Für Geräte dieser Generation bietet Bumblebee momentan die einzige Möglichkeit den dezidierten GPU zu verwenden/abzuschalten.

Bei den Geräten der dritten Generation hat der User die Möglichkeiten:

1. ) den Grafik Modus selbst zu wählen (also nur der im CPU integrierte Chip ist aktiv oder nur der dezidierte Chip ist aktiv oder beide Chips sind aktiv)

2.) wenn beide Chips aktiv sind wird standardmäßig der im CPU integrierte Chip verwendet und der dezidierte Chip kann mittels eines acpi_calls ausgeschaltet werden 3.) wenn beide Chips aktiv sind wird standardmäßig der im CPU integrierte Chip verwendet und mittels Bumblebee kann ein weiterer X-Server am dezidierten GPU zugeschaltet werden dessen Fenster sich in den primären Xserver "einnisten".

Ist die Unterscheidung 2./3. Generation relevant für die Funktionsweise/Installation von bumblebee (im Wiki) ?

- Bumblebee erzeugt durch den weiteren Xserver einen recht großen overhead. Dies wirkt sich negativ auf die Performance des dezidierten GPU's aus, der mit Bumblebee weniger Leistung bringt als im "Exklusiven" Modus.

Soll man das erwähnen ? Liegt ja in der Natur der Sache

Nun zu den Problemen von Bumblebee (Mein Netbook ist ein Protagonist der dritten Generation, also bezieht sich alles weitere auf diese Geräteklasse): - Es gibt von Seiten der Hersteller keine öffentliche Dokumentation über die acpi Funktionen der Hardware. Die Acpi-Calls zum ausschalten der dezidierten GPU's sind deshalb im 'trial & error' Verfahren aus dsdl dumps extrahiert (sprich erraten) und können sehr unangenehme Nebenwirkungen (lockups ect.) haben.

Ja ,die acpi_call Problematik wurde schon "diskutiert", steht auch im Wiki...

- Bumblebee selbst setzt die GPU Mode für den nächsten Boot automatisch in den Dual-GPU Modus und macht das jedes mal wenn der dezidierte Chip aktiviert wird. Dies geht auf meinem Gerät genau einmal gut. Wird optirun während eines Boot Cycles ein zweites mal verwendet (und damit der Vga Modus für den nächsten Boot ein weiteres mal gesetzt) endet das bei mir in 99% der Fälle in einem kompletten System Lockup. Also vom "Problem Solved", von dem Martin Juhl spricht, kann momentan leider noch keine Rede sein

Nur um kein Mißverständnis aufkommen zu lassen:
..Artikel ist über bumblebee/stable, nicht bumblebee(Mr Meee) oder Ironhide.Hier werden keine vagen Calls ausgeführt, es sei denn, man aktiviert das auf eigene Gefahr, worauf im Wiki hingewiesen wird.

- Der HDMI Port kann im Dual-GPU Modus mit Bumblebee nicht verwendet werden da er wie oben erwähnt direkt mit dem dezidierten GPU verkabelt ist.

Ja, sollten wir erwähnen...

- Hardware-beschleunigte Video wiedergabe mittels vdpau soll bei einigen Modellen mit Bumblebee funktionieren, jedoch hab ich es nicht geschafft das meinem Gerät zu entlocken.

Ich auch nicht.Ist vielleicht erstmal wegzulassen...
Danke schonmal zippy

Hallo mtron, .....hoffe, Du bist noch nicht über alle Berge.Habe ein paar Fragen,z.B. zu: "Bei den Geräten der dritten Generation hat der User die Möglichkeiten: .... den Grafik Modus selbst zu wählen (also nur der im CPU integrierte Chip ist aktiv oder nur der dezidierte Chip ist aktiv oder beide Chips sind aktiv)" ...aber doch nicht mit bumblebee,oder ? Wie geht man vor, um "kompletten Desktop" auf der Nvidia GPU zu fahren? ...ist der HDMI port dann erreichbar ? Und ein paar mehr.Freue mich zum qualifizierten Input für die Baustelle... zippy

realzippy schrieb:

"Bei den Geräten der dritten Generation hat der User die Möglichkeiten:
.... den Grafik Modus selbst zu wählen (also nur der im CPU integrierte Chip ist aktiv oder nur der dezidierte Chip ist aktiv oder beide Chips sind aktiv)"
...aber doch nicht mit bumblebee,oder ?

Nein, mit Bumblebee geht das nicht, da es wie gesagt immer VGa Mode 3 (also die Optimus Mode) für den nächsten boot aktiviert.

Wie geht man vor, um "kompletten Desktop" auf der Nvidia GPU zu fahren?

Eigentlich recht einfach, wenn du den ACPI-Call weisst. In meinem Fall (Asus EeePC1015PN) reicht es den call

echo "\OSGS 0x02" > /proc/acpi/call

zu schicken, xorg.conf anzupassen und ein wenig mit den glx libraries herumzufummeln. Genauer habe ich den Prozess hier beschreiben: http://mtron.co.nr/howtos/eeepc-1015pn (vor allem der Abschnitt 'Alternative: Set the VGA Mode manually' ist in dem Fall für dich interessant.

...ist der HDMI port dann erreichbar ?

Ja. Ich brauche mein Netbook vor allem für Präsentationen und zum video schauen auf dem Fernseher (via HDMI), also ist bumblebee für mich momentan leider nicht wirklich nützlich, deshalb habe ich mir selbst was zusammengebastelt was meinen Anforderungen entspricht. Siehe http://ubuntuforums.org/showthread.php?t=1677780 Aber natürlich funktioniert das ausschließlich auf dem besagten Modell, da acpi_calls von modell zu modell unterschiedlich sind.

Woher bekäme man den acpi call zum Auschalten der intel GPU?
Wäre ja nicht unwichtig, falls man das in den wiki artikel aufnimmt....ich z.b. habe leider nur die calls für die Nvidia GPU.

indem du die dsdt tables (acpi calls) deines system dumpst.

 sudo apt-get install acpidump iasl
 mkdir ~/acpiinfo ; cd ~/acpiinfo
 sudo acpidump > acpidump.txt
 sudo acpixtract acpidump.txt

damit bekommst du einige hundert mögliche acpi_calls deiner hardware. Was der richtige für die von dir gewünschte Funktion ist musst du im trial & error verfahren herausfinden, weil die Hardware Hersteller keine dokumentation zu den acpi Funkionen herausgeben.

Meistens geht das nur via call senden, dmesg output anschauen, falls kein error rebooten und schauen was passiert. Diese Vorgehensweise ist bei einigen hundert möglichen calls natürlich unglaublich zeitaufwendig... und auch falls du mit viel Geduld und Glück einen call findest, heißt das noch nicht, dass es ohne eventuelle Nebenwirkungen funktioniert. => Das ist momentan das Hauptproblem von bumblebee. Es wird einfach darauf losgeraten ohne Details zu kennen. Die Folgen können bis zu einem Hardwareschaden reichen...

ich habe noch was vergessen:

Im Falle des EeePc-1015PN sind wir ziemlich sicher das die acpi-calls zum wechseln der Hardware richtig und gefahrlos einsetzbar sind, weil sie aus der von Asus geschriebenen Windows binary zum Grafik Mode umschalten reverse-engineered worden sind. Der Prozess des Reverse-Engineering einer binary ist noch viel komplexer und sprengt das Umfeld dieses Threads bei weitem.

Zu beachten ist außerdem noch: Ich kenne jetzt nicht die genaue Rechtslage in Deutschland, aber in den USA ist das reverse-Engineering einer closed-source binary aufgrund des DMCA sogar strafbar, also werde ich hier nicht erklären wie man sowas macht. Bitte auch keine diesbezüglichen PNs.

mtron schrieb:

Es wird einfach darauf losgeraten ohne Details zu kennen.

Sonst keine Möglichkeit?
Ich z.B. habe meine Acpi calls direct von den bumblebee/stable Entwicklern, die ja zu den ironhide calls keine gute Meinung zu haben scheinen, ganz zu schweigen von jenen, die das berüchtigte test.sh script ausspuckt.Ich habe ihnen meine Acpiinfo geschickt und bekam postwendend funktionierende calls zurück.Kann mir nicht vorstellen, daß sie meine Hardware simulieren und stundenlang im trial & error Verfahren für mich calls ausprobieren ... ?

doch, genau so ist es. Die calls wurden von usern die genau dieses von mir beschriebene trial & error verfahren genutzt haben an die hybrid-graphics-linux mailing liste geschickt und daher kommen die vorhandenen calls in der Regel.

..also ist das für den Optimus Wiki Artikel nicht relevant (die Möglichkeit zu beschreiben, "nvidia only" zu fahren)......(?)

nein. Die Möglichkeit gibt es nur bei den Optimus geräten der 3. Generation und mit Bumblebee kann man das nicht machen.

Aber auch die calls zum gpu abschalten sind mit größter Vorsicht zu genießen. Bevor man einen potentiellen User empfiehlt die bumblebee Energiespar - Funktionen zu aktivieren (die von den bumblebee Entwicklern aus genau diesem Grund wieder entfernt wurden) sollte man die user auf die hier erörterten möglichen Gefahren hinweisen.

Ironhide würde ich nicht einsetzen / empfehlen.

Habe mich auch gegen ironhide im Laufe dieses threads ausgesprochen, und es aus dem Artikel entfernt.
Vor den Calls -im allgemeinen- wird bereits gewarnt im Artikel.
Also, was sollte noch rein? (in den Artikel..)

Hi,

vll interessiert Dich noch diese Seite der Launchpad-Gruppe "Hybrid-Graphics-Linux"? Es ist sehr umfangreich. z.B. FF-Suchbegriff: < ### ACPI Calls > Dort wird z.B. auf den Feedback im 752542 eingegangen (Vorsicht, ist ein langer "Fehler"-bericht, bis heute 370 Meldungen). Man erkennt so eigentlich erst, dass viele Benutzer ein Feedback geben können, um langsam "Licht ins Dunkel" zu bekommen. Den Link auf's Arch-Linux Wiki würde ich wieder entfernen. Ich finde ihn zu distributionsabhängig. Wenn er Dir beim Erstellen des Artikels geholfen hat, hat er seinen Sinn ja eigentlich erfüllt... Auch wenn ich die Warnbox dort am Artikelanfang sinnvoll finde.

Warning: Bumblebee is a work in progress and may not work properly on your machine

So, habe den Arch Link entfernt.Außerdem Hinweis gegeben, nvidia und xorg.conf zu entfernen, da dies in der Praxis öfters für Irritationen sorgte. Des weiteren "powermanagement" in Warnbox gesetzt....ok?

Hallo,

also vom Syntax und Verständlichkeit des Inhalts ist der Artikel IMHO ok.

Kann also ins Wiki?

Gruß, noisefloor

Hi

dann könnte der Hinweis auf das bumblebee-ppa in nvidia#Installation aus ppa bitte entfernt werden, da er dort, ohne Hintergründe zu kennen, eher Schaden anrichten kann. mMn.