On Tue, Feb 06, 2018 at 05:06:02PM +0100, Cyrille Chépélov wrote: > Hi Jonas, > > responding slightly out of order (both below an inline); plus we've pretty > much already started to bring this onto the issue tracker where this > belongs:
Thanks for filing those issues. > > > It'd also be good if you used the top of the master branch instead of > > 3.27.1 (both mutter and gnome-shell), as otherwise you might hit a set > > of bugs fixed during the development cycle. > > Now rebuilding to work top-of-master for Mesa, mutter & gnome-shell: > > * mesa: master at a5053ba27e > * mutter: master at 70fcf745 > * gnome-shell: master at 0b51ead00 > * gnome-shell-extensions: master at ae65a82 /(not strictly necessary > but to keep dpkg happy)/ > ... snip ... > > > > > * When /un/pluggin an external display through HDMI, the machine keeps > > > working, and could withstand an unlimited number of plug/unplug > > > cycles. > > This is also indeed expected to work. > > > > Note that when I did this work, I hit a nouveau bug that triggered > > freezes. I have not checked whether those have been fixed. > > Noted. As an aside, I noticed that when shutting down gnome-session + the > gdm3 service (going back to text mode), the "nouveau" kernel module remains > "used" (it increases by 1 each time gdm starts), which makes difficult > removing it for the purpose of powering down the GPU. Would eventually > report it on > https://bugs.freedesktop.org/buglist.cgi?component=Drivers%2FDRI%2Fnouveau&list_id=636975&product=Mesa&resolution=--- Should probably double check that we close nouveau KMS fd when terminating, but either way, the driver should be able to handle a process with a KMS fd open crashing either way. > ... snip ... > > > FWIW, when rendering the content for your nouveau connected monitor, we > > do so using the Intel GPU. After eglSwapBuffers(), we take the result, > > blit it onto a buffer on the nvidia GPU using nouveau, and hand that > > over to the monitor. > Ah, I wasn't aware of this. So basically for now 'hybrid mode' is > effectively using the iGPU for most tasks, while the dGPU is used as > effectively a PCI-to-HDMI bitmap-shipping dongle. > > So perhaps there may be an interesting alternative to GPU hotplug, if there > is a way to start nouveau (and the GPU) permanently but shut down most of > the engines (https://nouveau.freedesktop.org/wiki/KernelModuleParameters/ # > grep for "list of engines). Paying a /few /watts at idle to gain easy enough > monitor plug&play might be a good enough option for a while (I'll > investigate separately) FWIW, we still use OpenGL etc for the bitmap-shipping as long as the driver for the dedicated GPU supports the GLES 3 features we depend on. > ... snip ... > > > > 3. I had once a crash in native code called by javascript code, but > > > lost the backtrace before I could save it > > If it was a segmentation fault, you could set the SHELL_DEBUG env > > variable to "backtrace-segfaults" (in a way that gnome-shell will see it > > when starting). This will make gnome-shell to print Javascript > > backtraces to the journal when it hits a segmentation fault. > It was a segfault indeed. Added SHELL_DEBUG=backtrace-segfaults for next > time > > > * I once managed to move a Firefox (Quantum) window with a moving > > YouTube video from the main (i915) to the external (nouveau) screen, > > without an obvious causality on the crash that happens seconds later. > > FWIW, this wouldn't cause Firefox to switch to using the nvidia GPU for > > rendering, as we don't have a way to tell applications to change what to > > render with yet. > Makes sense. Again, the iGPU is plenty adequate for my needs, I really wish > GTX 1060 didn't omit the hardware muxer (or Gigabyte provided a no-nonsense > option without unnecessary hardware). You can still use the dGPU for rendering application content. IIRC using "DRI_PRIME=1 some-egl-application" worked as expected. There are optimizations to be done (e.g. skip going via the iGPU driver when possible) but should at least be possible to use it. Jonas _______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
