Recommended modesetting driver for Intel graphic cards

[Martin Flöser]

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-rendering-performance-benchmarks/

Everything written there still fully applies to the benchmark in 
question

Cheers
Martin