I've been using the modesetting driver for over a year and a half now - on Sandy Bridge, Ivy Bridge, Broadwell and now Kaby Lake hardware. I've *never* come across a bug all this while (in fact, I was forced to switch due to GPU lockups on Sandy Bridge with xf86-video-intel).
I haven't had a perceptible difference in performance, everything is tear-free by default (I had to tinker with xorg.conf to enable sync-to-vblank with SNA on the Intel DDX) - overall a much smoother out of the box experience with the modesetting driver than the intel one. My 2c, experience on Arch Linux. Thanks, Boudhayan Gupta KDE e.V. - Community Working Group +49 151 71032970 On 21 November 2017 at 00:27, Milian Wolff <m...@milianw.de> wrote: > On Montag, 20. November 2017 23:40:38 CET Milian Wolff wrote: >> On Montag, 20. November 2017 17:28:06 CET Martin Flöser wrote: >> > Am 2017-11-20 11:59, schrieb Milian Wolff: >> > > On Samstag, 18. November 2017 15:34:16 CET Friedrich W. H. Kossebau >> > > >> > > wrote: >> > >> Am Donnerstag, 16. November 2017, 23:24:52 CET schrieb Ingo Klöcker: >> > >> > On Dienstag, 7. November 2017 20:55:57 CET Martin Flöser wrote: >> > >> > > Am 2017-11-07 20:08, schrieb Martin Koller: >> > >> > > >> Are you aware that KWin uses QtQuick for all its UI elements, >> > >> > > >> such >> > >> > > >> as >> > >> > > >> Alt+TAB? >> > >> > > > >> > >> > > > I have deactivated the compositor since sadly it simply does not >> > >> > > > work >> > >> > > > on my laptop (the intel graphics driver just freezes the whole >> > >> > > > machine). >> > >> > > >> > >> > > I did not talk about compositor, I talked about QtQuick! Yes, KWin >> > >> > > uses >> > >> > > QtQuick for rendering it's UI, that is unrelated to compositing. >> > >> > > >> > >> > > Now you mention that your intel graphics driver freezes the whole >> > >> > > system. I'm using Intel on all my systems and it's the most used >> > >> > > driver >> > >> > > out there. We get many, many, many bug reports in KWin about >> > >> > > issues. >> > >> > > Freezing systems has not been in the list for now something like >> > >> > > two >> > >> > > years. >> > >> > > >> > >> > > Given that I am very certain that you have a hardware issue where >> > >> > > people >> > >> > > can help you with. Intel GPUs are good enough to run the Plasma >> > >> > > session >> > >> > > without any negative impact. >> > >> > > >> > >> > > So let us help you fix your issues that you can enjoy our work >> > >> > > without >> > >> > > having to spend time on writing your own shell. >> > >> > > >> > >> > > First thing: are you using the xorg-modesettings driver? If not: >> > >> > > install >> > >> > > it, problems solved. Do not (I repeat) do not use the xorg-intel >> > >> > > driver. >> > >> > > >> > >> > > For kernel I recommend at least version 4.13 as this comes with the >> > >> > > atomic modesettings driver stack enabled by default. If you do not >> > >> > > have >> > >> > > such a kernel version yet I highly recommend to give it a try. >> > >> > >> > >> > Martin, thanks a lot for your advice! >> > >> > >> > >> > I've suffered from freezes since I updated my openSUSE 13.2 to >> > >> > Tumbleweed >> > >> > some time ago (and much longer on my laptop where I've switched to >> > >> > Leap >> > >> > and >> > >> > later Tumbleweed much earlier). >> > >> >> > >> Same here, happy to finally see someone with correlated experience. I >> > >> never >> > >> got any useful hints in the log files, so was close to consider my >> > >> hardware >> > >> broken. Strange enough all freezes seemed to happen while moving the >> > >> mouse >> > >> though, which kept the hope alive it was something software-related. >> > >> >> > >> Curious to see if my daily freeze will now be a thing of the past now >> > >> that I >> > >> changed the driver. Though I am on a 2nd gen 915 device, while all the >> > >> modesettings driver talk I came across on a quick search seemed to be >> > >> only >> > >> about gen4 and later? No issues seen for one hour so far, hope grows >> > >> >> > >> :) >> > >> : >> > >> > The switch to the modesetting driver seems >> > >> > to have fixed those issues. It took me some time to find out how to >> > >> > enable >> > >> > the modesetting driver. To save others the time here's how to do it: >> > >> > Write >> > >> > #===== >> > >> > Section "Device" >> > >> > >> > >> > Identifier "Intel Graphics" >> > >> > Driver "modesetting" >> > >> > >> > >> > EndSection >> > >> > #===== >> > >> > to a file in /etc/X11/xorg.conf.d/, e.g. 50-device.conf. Make sure >> > >> > that >> > >> > this is the only (or at least the first) "Device" section in any of >> > >> > the >> > >> > files in /etc/X11/xorg.conf.d/. >> > >> >> > >> Another approach seems to be to uninstall xf86-video-intel, that way >> > >> the >> > >> seemingly hardcoded driver-auto-match logic will skip forward to the >> > >> modesetting driver: >> > >> >> > >> [ 12.125] (==) Matched intel as autoconfigured driver 0 >> > >> [ 12.125] (==) Matched intel as autoconfigured driver 1 >> > >> [ 12.125] (==) Matched modesetting as autoconfigured driver 2 >> > >> [ 12.125] (==) Matched fbdev as autoconfigured driver 3 >> > >> [ 12.125] (==) Matched vesa as autoconfigured driver 4 >> > >> [ 12.125] (==) Assigned the driver to the xf86ConfigLayout >> > >> [ 12.125] (II) LoadModule: "intel" >> > >> [ 12.127] (WW) Warning, couldn't open module intel >> > >> [ 12.127] (II) UnloadModule: "intel" >> > >> [ 12.127] (II) Unloading intel >> > >> [ 12.127] (EE) Failed to load module "intel" (module does not >> > >> exist, 0) >> > >> [ 12.127] (II) LoadModule: "modesetting" >> > >> [ 12.127] (II) Loading >> > >> /usr/lib64/xorg/modules/drivers/modesetting_drv.so >> > > >> > > I've also recently come across this. According to [1] the performance >> > > is >> > > supposedly much worse. Is this still true for more recent mesa/kernel >> > > versions? >> > >> > You quoted Phoronix. I hope you don't expect Phoronix to be able to get >> > proper measurements. That's something Phoronix still hasn't succeeded >> > after all those years. Just for fun I clicked that link and the first >> > graph shows a benchmark showing a game one running at 22.15, the other >> > at 22.13 fps. This difference is kernel sneezing. So much to that. But >> > the real issue is that a game running at 22 fps is unplayable. It has >> > nothing to do in the benchmark, the setup is broken. This has been the >> > issue as long as I followed Phoronix benchmarking. From an academic >> > point of view - which you understand as much as I do - it's just all >> > extremely horrible. >> > >> > Don't take any numbers serious. Michael doesn't understand how to do >> > benchmarking. He just runs his tools. He doesn't think about what a >> > benchmark should show, what he wants to show. And he doesn't interpret >> > the numbers. He just gives numbers. Do they matter? Who knows. You >> > derived from his numbers that the "performance is much worse". Is that >> > the case? I don't know because I don't see this in the benchmark. I just >> > see numbers. We would have to ask someone understanding the system >> > whether it makes sense. I assume there are not many people who might be >> > able to answer the question. Maybe the authors of GtkPerf, maybe Keith >> > Packard as the author of glamor, but certainly not Michael from >> > Phoronix. >> > >> > Hadn't done a Phoronix benchmarking rant for years ;-) Sad that it still >> > is needed. >> > >> > For reference I point to a blog post from 2012 where I discuss Phoronix >> > benchmarking in detail: >> > http://blog.martin-graesslin.com/blog/2012/09/why-i-dont-like-game-renderi >> > ng -performance-benchmarks/ >> > >> > Everything written there still fully applies to the benchmark in >> > question >> >> Thanks for the rant :) I rarely look at graphic related Phoronix stuff since >> I don't know the tools and what they measure. For some I/O and CPU stuff, >> the tools are useful and thus the numbers reported are, too. >> >> So since the tools used here are apparently useless, could you or someone >> else please answer the actual question: Is there any perceived performance >> difference between modesetting driver and intel driver? I assume it isn't >> from the way you respond. Just wanted to make sure. > > Well, I tried it out myself now that tosky said it works for him. Indeed, it > does for me too - and some glaring bugs are resolved on top! Most notably I'm > finally able to launch secondary X sessions, nice :) > > Thanks everyone for recommending this. I bet more people have this old driver > installed out of habit (like I did), without a clear understanding of what > they are doing. > > Cheers > > -- > Milian Wolff > m...@milianw.de > http://milianw.de