Bug 90932

Summary: gm107 font glitches with kernel 4.1rc
Product: xorg Reporter: Marcus Moeller <marcus.moeller>
Component: Driver/nouveauAssignee: Nouveau Project <nouveau>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: mcgregor
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
font glitches with gm107
none
Screencast showing the behavior
none
modeset - glamor NV50
none
modesetting driver with latest Xorg updates
none
serialize when vbo dirty none

Description Marcus Moeller 2015-06-11 07:02:26 UTC
Created attachment 116429 [details]
font glitches with gm107

I have tried Kernel 4.1 with gm105 (NVidia K620 graphics card) and noticed some font glitches. Some characters are not displayed at all. Sometimes those chars appear while hovering them with the mouse, sometimes not. I have attached a screenshot of Firefox. Please note that the word Firefox is sometimes displayed as 'Fire  x'
Comment 1 Ilia Mirkin 2015-06-13 16:05:34 UTC
I'm not aware of a GM105. Do you perhaps mean GM107? Avoid using xf86-video-nouveau with that, just use the modesetting ddx directly. nouveau ddx has an incorrect integration with glamor (and no EXA support for maxwell).

I also believe that there were generic level issues in GLAMOR which were fixed in Xorg 1.17 or so (at least, the font drawing got redone or something to that effect).
Comment 2 Marcus Moeller 2015-06-18 12:39:16 UTC
The strange thing is, that it works perfectly with nouveau on 4.0.
Comment 3 Marcus Moeller 2015-06-23 11:51:32 UTC
It still appears in Kernel 4.1 final.
Comment 4 Marcus Moeller 2015-06-23 11:51:58 UTC
Created attachment 116671 [details]
Screencast showing the behavior
Comment 5 Ilia Mirkin 2015-06-23 13:45:29 UTC
(In reply to Marcus Moeller from comment #3)
> It still appears in Kernel 4.1 final.

Updating Xorg to 1.17 and switching to the modesetting X ddx (instead of the nouveau X ddx) should fix this. The reason you're seeing this in 4.1 and not 4.0 is that 4.1 finally has acceleration enabled by default for GM107.
Comment 6 poma 2015-06-23 13:51:35 UTC
/etc/X11/xorg.conf.d/00-modesetting.conf
Section "Device"
    Identifier "video0"
    Driver     "modesetting"
EndSection
Comment 7 Marcus Moeller 2015-06-23 14:06:56 UTC
Shouln't this be fixed in nouveau instead of moving to another driver? Or is this just a suggestion for a workaround?
Comment 8 Ilia Mirkin 2015-06-23 14:17:16 UTC
(In reply to Marcus Moeller from comment #7)
> Shouln't this be fixed in nouveau instead of moving to another driver? Or is
> this just a suggestion for a workaround?

The fix in nouveau will be "remove glamor integration" and "fail to load for GM107+". But we haven't fully decided on that *quite* yet. And I have an EXA impl in the works for GM107, so perhaps we'll use that. TBD.

The problem that you're seeing is with glamor, and they changed the way font rendering was done in X 1.17, which is why I'm suggesting you use that.

Separate from that, nouveau's integration with glamor is totally fubar'd and should be removed, as per the above, but that has nothing to do with any misrendering you might see. For example perhaps you might observe the lack of a GLX_ARB_create_context_profile. This is a symptom of DRI2 support basically missing, which is going to cause major problems.

Since nouveau's integration with glamor would be no different from modesetting's integration with glamor, might as well just use that directly... [There are one or two things nouveau can still do that modesetting can't, but those differences are in the process of being eliminated.]
Comment 9 Marcus Moeller 2015-06-24 06:03:25 UTC
Thanks for the explanation. For me the exa sounds like a great option. Besides that we have tried the modesetting driver with the K620 card and noticed a much higher CPU load on gnome-shell (even on inactivity).
Comment 10 Ilia Mirkin 2015-06-24 15:06:00 UTC
(In reply to Marcus Moeller from comment #9)
> Thanks for the explanation. For me the exa sounds like a great option.
> Besides that we have tried the modesetting driver with the K620 card and
> noticed a much higher CPU load on gnome-shell (even on inactivity).

I wonder if it's using llvmpipe or something... should be ~same perf.
Comment 11 Marcus Moeller 2015-06-26 13:21:29 UTC
Yes that might be the case. Is there any way to check this?
Comment 12 poma 2015-06-29 03:55:20 UTC
(In reply to Marcus Moeller from comment #11)
> Yes that might be the case. Is there any way to check this?

# journalctl -b | grep -i 'foo\|bar'
Comment 13 poma 2015-06-29 03:56:43 UTC
Created attachment 116778 [details]
modeset - glamor NV50

For comparison.
Comment 14 Marcus Moeller 2015-06-29 08:41:01 UTC
Created attachment 116784 [details]
modesetting driver with latest Xorg updates

Latest test with vmlinuz-4.1.0-1, updated xorg-x11-server-Xorg to 1.17.2-1 and modesetting driver makes it even worse (though there is no high CPU load anymore)
Comment 15 Ilia Mirkin 2015-06-29 19:43:14 UTC
(In reply to Marcus Moeller from comment #14)
> Created attachment 116784 [details]
> modesetting driver with latest Xorg updates
> 
> Latest test with vmlinuz-4.1.0-1, updated xorg-x11-server-Xorg to 1.17.2-1
> and modesetting driver makes it even worse (though there is no high CPU load
> anymore)

First it wasn't enough characters... now it's too many. Make up your mind! :)

I need to re-run piglit against a GM107 to see if I've accidentally the whole thing. Martin has made one available for me remotely, but I haven't had time to actually do the run. But this look like a regular ol' bug in the 3d driver somewhere.

Does this always happen? Windows of all sizes, or just huge ones? Anything else you could tell me that'll help me debug this?
Comment 16 Marcus Moeller 2015-06-30 08:05:08 UTC
This happened after scrolling through the page buffer in gnome terminal using Shift+PgUP.

I have also re-checked 4.1 final without latest Xorg updates and modesetting driver and can confirm that the font glitches are also there. llvmpipe is not used in this case (only when nomodeset is active/vesa is used).
Comment 17 Marcus Moeller 2015-09-01 11:45:15 UTC
Still present on 4.2. Are there any plans on how to proceed?
Comment 18 Ben Skeggs 2015-09-01 12:26:21 UTC
(In reply to Marcus Moeller from comment #17)
> Still present on 4.2. Are there any plans on how to proceed?

That's not surprising because it's not a kernel issue.  It's either a 3D driver bug, or a glamor bug.
Comment 19 Marcus Moeller 2015-09-01 12:29:52 UTC
As nouveau is a kernel driver I suspected that it's somewhat related to the kernel.
Comment 20 Ilia Mirkin 2015-10-15 07:24:46 UTC
Created attachment 118882 [details] [review]
serialize when vbo dirty

This (mesa) patch seems to help Ben when using GLAMOR on Kepler chips. Could give it a shot to see if it improves the Maxwell situation as well. Doubtful that it's the "right" thing though.
Comment 21 jamesstewartmiller 2015-12-22 15:35:39 UTC
Hi, I don't know if this will help, but I have a gm107 (gtx 750 ti) and I experience the font glitches on new installs of wily, which is 4.2.0-22

The issue disappears when I uncheck 'enable anti-alias' in fontsettings (settings->appearance->fonts)

I have an xfce desktop (ubuntu studio).

Thanks for your time (and please, please, please get acceleration working on nouveau on the gm107 - I can't run my games! and I'd rather use the nouveau driver so that I can use a realtime kernel for audio).

Many thanks, and if there is anything I can do to contribute/help then let me know.
Comment 22 Roman Elshin 2016-01-15 16:21:52 UTC
(In reply to Ilia Mirkin from comment #20)
> This (mesa) patch seems to help Ben when using GLAMOR on Kepler chips. Could
> give it a shot to see if it improves the Maxwell situation as well. Doubtful
> that it's the "right" thing though.

This patch helps with 750ti too (at least at first sight).
Comment 23 Marcus Moeller 2016-02-02 14:33:30 UTC
I have upgraded to 4.3.4 and latest Xorg and cannot reproduce this behaviour anymore. Everything seems fine now.
Comment 24 Martin Peres 2019-12-04 09:00:31 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/195.

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.