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'
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).
The strange thing is, that it works perfectly with nouveau on 4.0.
It still appears in Kernel 4.1 final.
Created attachment 116671 [details]
Screencast showing the behavior
(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.
Shouln't this be fixed in nouveau instead of moving to another driver? Or is this just a suggestion for a workaround?
(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.]
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).
(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.
Yes that might be the case. Is there any way to check this?
(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'
Created attachment 116778 [details]
modeset - glamor NV50
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)
(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
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?
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).
Still present on 4.2. Are there any plans on how to proceed?
(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.
As nouveau is a kernel driver I suspected that it's somewhat related to the kernel.
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.
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.
(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).
I have upgraded to 4.3.4 and latest Xorg and cannot reproduce this behaviour anymore. Everything seems fine now.
-- 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.