On Tue, Mar 19, 2013 at 3:06 AM, Ralf Jung <p...@ralfj.de> wrote: > Hi, > >> I suppose a better way of explaining why watching /proc/acpi/bbswitch >> isn't reliable is by referencing the differences between how the >> virtualgl and primus backends work. Virtualgl will always cause the >> secondary X server to be spawned (everything is rendered on the >> secondary X server before being displayed on the primary X server), >> whereas primus will only offload glx calls to bumblebee, thus the >> secondary X server will only start up when you run some sort of opengl >> application with primus. That means that "optirun bash" or "optirun >> xterm" will invariably turn on the secondary X server and the nvidia >> gpu, whereas "primusrun bash" or "primusrun xterm" (or some other >> application that doesn't use any glx calls) will not. > However, if primusrun is invoked via optirun, then the second Xserver is > spawned immediately - optirun itself does that before launching primusrun.
Ah, I was unaware that optirun would spawn a secondary X server immediately regardless of whether the virtualgl or the primus backend is used. That's certainly different from what primusrun alone seems to do (spawn secondary X server only when needed, i.e. when glx calls are passed along to the nvidia gpu). > In this scenario, primusrun has the advantage of keeping the second > Xserver "alive" even if the program forks away, since primus is injected > in each sub-process which is launched, while optirun+virtualgl monitor > only the initially executed process. Yep, no need for that "optirun bash" workaround anymore. :) Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tB=fmdh2ndea1oxrxefaypr45g7hrts10jufgqktdn...@mail.gmail.com