Bug 106294 - GM204/modesetting DDX: Odd corruption (red backgrounds) introduced by Mesa
Summary: GM204/modesetting DDX: Odd corruption (red backgrounds) introduced by Mesa
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/nouveau (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Nouveau Project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-28 11:07 UTC by Sophie Hamilton
Modified: 2019-07-08 16:43 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Sophie Hamilton 2018-04-28 11:07:44 UTC
I apologise if I have selected the wrong product for this bug, as I think I probably have. If I need to open a new bug, please let me know.

I use an NVidia GeForce GTX 970, with kernel version 4.15.4-gentoo and the modesetting driver in Xorg. (More detailed descriptions of packages installed at the bottom of this description.)

My distribution (Gentoo) has packages for Mesa 17.2.8, 17.3.8, and a few other higher versions (currently marked as unstable). When I use Mesa 17.3.8 or higher, I see odd types of corruption involving red backgrounds on menus and widgets, and some checkboxes appear unticked when they should be ticked. I recorded this behaviour using OBS:

* Incorrect behaviour on 17.3.8 and higher:
    https://www.youtube.com/watch?v=puSC7a_osw0

* Expected behaviour on 17.2.8:
    https://www.youtube.com/watch?v=LbjCoIX4DKE

I dug out git and have confirmed that the bug still exists as of commit https://cgit.freedesktop.org/mesa/mesa/commit/?id=8b7358fe4376aecee0c29ea622f88f9ef07e6b11 (the latest commit on master as of an hour ago or so).

After bisection, I discovered that the bug was introduced by https://cgit.freedesktop.org/mesa/mesa/commit/?id=fcbb93e860246375d03f280f927f79d3645a8988 , which is actually *before* the 17.2.x branchpoint. It turns out that this commit was reverted in the 17.2.x branch in commit https://cgit.freedesktop.org/mesa/mesa/commit/?id=17a3e4891bf4fa09785fe9d22db5c79a949004db to fix bug #101983. This was not committed to the 'master' branch, as the fixes in master apparently would have been rather invasive. This explains why my tests of 17.2.8 worked fine.

This issue only appears when using the "modesetting" DDX drivers. When using the "nouveau" DDX drivers, the issue does not appear. (The "nouveau" DDX drivers also fix other issues for me so I'll probably switch to using that from now on for normal use, but I'm willing to switch back to help debug this issue if needed.)

System summary:

I have the following graphics card, as shown by lspci -nn:
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce GTX 970] [10de:13c2] (rev a1)

I am running Gentoo Linux with the sys-kernel/gentoo-sources-4.15.4 kernel, with the following (relevant) packages installed:

* x11-base/xorg-server-1.19.5-r1
* x11-base/xorg-drivers-1.19 (with VIDEO_CARDS="nouveau")

In my kernel configuration, CONFIG_DRM_NOUVEAU is set to "m".

Please let me know if you need any more information.
Comment 1 Sophie Hamilton 2019-07-08 16:38:25 UTC
I just realised I still have this bug open... since then I've switched graphics cards to an AMD card, so I can no longer test this bug or assist with debugging. I apologise for this.

This bug may still be relevant, so I'll leave it up to you whether to close it or not. I'm sorry for the inconvenience!
Comment 2 Ilia Mirkin 2019-07-08 16:43:36 UTC
Good choice with switching to AMD! Tell your friends, too.

There's some likelihood that this issue was fixed by a change to dealing with uniform buffer size changes on GM10x+, which could be consistent with the change you bisected to.

Given that you can't repro anymore, and the likelihood of it being fixed, I'm going to close it.

[Also, in any case, I recommend using the nouveau ddx over modesetting. You get to use a small, well-tested driver vs ... the mess that is GL.]


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.