Nouveau - Feb 2011 - [Bug 33977] New: X core font rendering is "laggy"

https://bugs.freedesktop.org/show_bug.cgi?id=33977

           Summary: X core font rendering is "laggy"
           Product: xorg
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Driver/nouveau
        AssignedTo: nouveau at lists.freedesktop.org
        ReportedBy: abrasive at axdf.net
         QAContact: xorg-team at lists.x.org


I'm having trouble with terminals under X after updating xf86-video-nouveau
and
libdrm.
When entering characters (in urxvt), the cursor in the previous cell is only
cleared after some delay, and lines printed in the terminal are often not
displayed until I generate more output or update some other part of the screen.
 There are also remnants of text visible in the fractional row under the last
terminal row. This seems to be an issue only with X core fonts, and not with
Xft ones.

I have an NV50 card, and the issue appeared after updating xf86-video-nouveau
from a git snapshot on 2010-08-19 to one from 2010-12-17. The issue is still
present on 2011-02-06. The upgrade necessitated upgrading libdrm from 2.4.21 to
2.4.23.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=33977

James Laird <abrasive at axdf.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Platform|Other                       |x86-64 (AMD64)
         OS/Version|All                         |Linux (All)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=33977

--- Comment #1 from James Laird <abrasive at axdf.net> 2011-02-06 19:57:03
PST ---
git bisect reveals the culprit:
9a5142fae6e1a0a470352f511427916e6fa01b9c is the first bad commit
commit 9a5142fae6e1a0a470352f511427916e6fa01b9c
Author: Maarten Maathuis <madman2003 at gmail.com>
Date:   Fri Aug 27 21:11:59 2010 +0200

    nv50/exa: Stop using wfb by default, but add an option to enable it.

    - Some scenarios, such as those heavy in core font rendering might prefer
wfb.
    - Other (modern) situations are better of with wfb disabled.

    Signed-off-by: Maarten Maathuis <madman2003 at gmail.com>

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=33977

--- Comment #2 from James Laird <abrasive at axdf.net> 2011-02-06 20:10:14
PST ---
(In reply to comment #1)
> commit 9a5142fae6e1a0a470352f511427916e6fa01b9c
>     nv50/exa: Stop using wfb by default, but add an option to enable it.
And setting WrappedFB to True in the xorg.conf makes it work again.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=33977

--- Comment #3 from Maarten Maathuis <madman2003 at gmail.com> 2011-02-07
01:15:43 PST ---
This is an xserver issue which i recently fixed.

http://cgit.freedesktop.org/xorg/xserver/commit/?id=541b25038a5de74411a094570b407c5ae018c2ba

I have asked for it to be also put in the next 1.9 release, will have to wait
how this goes.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Le 07/02/2011 10:15, bugzilla-daemon at freedesktop.org a ?crit
:
> https://bugs.freedesktop.org/show_bug.cgi?id=33977
>
> --- Comment #3 from Maarten Maathuis<madman2003 at gmail.com> 
2011-02-07 01:15:43 PST ---
> This is an xserver issue which i recently fixed.
>
>
http://cgit.freedesktop.org/xorg/xserver/commit/?id=541b25038a5de74411a094570b407c5ae018c2ba
>
> I have asked for it to be also put in the next 1.9 release, will have to
wait
> how this goes.
>
The bug is tagged as x86-64 (AMD64) Linux (All) but it occurs here as well
(i686).

And during a few seconds sometimes I see only half of the last row of text
displayed (vertically cut).

https://bugs.freedesktop.org/show_bug.cgi?id=33977

--- Comment #4 from Michel D?nzer <michel at daenzer.net> 2011-02-07
08:05:24 PST ---
(In reply to comment #3)
> This is an xserver issue which i recently fixed.
> 
>
http://cgit.freedesktop.org/xorg/xserver/commit/?id=541b25038a5de74411a094570b407c5ae018c2ba
During the review of that patch, I got the impression the problem you were
trying to solve was output being delayed somewhat, but appearing on its own
eventually. However, this bug report talks about some output not appearing
until further user action. That sounds like maybe the driver flushes the
command stream to the hardware in the block handler before EXA gets a chance to
upload deferred software rendering?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=33977

--- Comment #5 from Maarten Maathuis <madman2003 at gmail.com> 2011-02-07
09:23:29 PST ---
In all my testing the output does appear regardless of further actions. It was
just a delay issue for me. But indeed, it's possible this is a flush issue
(i
thought i checked that, but now I'm not sure). I'll have a look at it,
including the xserver side of it.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=33977

--- Comment #6 from Maarten Maathuis <madman2003 at gmail.com> 2011-02-07
10:09:27 PST ---
The "gaps in text" problem at high throughput isn't fixed by
adding a flush in
the driver, for that the original solution is still needed. Even flushing every
10 ms isn't enough to get the same result. The latency issues at low
throughput
(typing for example) is pretty much solved with an extra driver flush after
small uploads to the screen pixmap.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=33977

--- Comment #7 from Michel D?nzer <michel at daenzer.net> 2011-02-09
01:32:04 PST ---
(In reply to comment #6)
> The "gaps in text" problem at high throughput isn't fixed by
adding a flush in
> the driver, for that the original solution is still needed. Even flushing
every
> 10 ms isn't enough to get the same result.
I'm still not 100% convinced this problem is severe enough to justify the
throughput penalty of the patch though... Since the radeon driver recently
switched to always using DownloadFrom/UploadToScreen to access tiled GPU
pixmaps, I've been looking for it but haven't really noticed it yet (my
xserver
checkout doesn't have your patch yet).

> The latency issues at low throughput (typing for example) is pretty much
solved
> with an extra driver flush after small uploads to the screen pixmap.
Not sure why you'd need any 'extra flushes' besides the flush in
your
BlockHandler, which has always been necessary. Just make sure this flush
happens after ExaBlockHandler (i.e. after calling down the wrapper chain).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=33977

--- Comment #8 from Maarten Maathuis <madman2003 at gmail.com> 2011-02-09
03:11:32 PST ---
I'm openminded to a revert, considering it's only an esthetical issue. I
just
don't know what will happen on high cpu loads (outside xorg). Will the
BlockHandler still be called every 50ms?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=33977

--- Comment #9 from Michel D?nzer <michel at daenzer.net> 2011-02-09
03:24:27 PST ---
(In reply to comment #8)
> I just don't know what will happen on high cpu loads (outside xorg).
Will the
> BlockHandler still be called every 50ms?
The BlockHandler is only called before the X server blocks waiting for input or
client requests. This may never happen if clients send rendering requests more
quickly than the server can process them (e.g. x11perf), but in that case
you'll probably flush to the hardware regularly anyway due to running out of
command stream space. If that's not the case, the driver needs another
mechanism to ensure flushes occur at appropriate intervals.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=33977

--- Comment #10 from Maarten Maathuis <madman2003 at gmail.com> 2011-02-09
03:30:37 PST ---
I was more worried about the xserver-exa side latency. It would be nice to have
some kind of maximum latency. The driver can't do anything if the pixmap
isn't
anywhere in the driver.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=33977

--- Comment #11 from Michel D?nzer <michel at daenzer.net> 2011-02-09
03:54:42 PST ---
(In reply to comment #10)
> I was more worried about the xserver-exa side latency. It would be nice to
have
> some kind of maximum latency. The driver can't do anything if the
pixmap isn't
> anywhere in the driver.
Hmm, that's a good point. So if you've double-checked that the driver is
flushing properly in the BlockHandler, and there's still no timeout interval
in
exaDamageReport_mixed which provides a better tradeoff between latency and
throughput, let's leave it at that for now.


However, then the question remains what is the cause of the '[...] not
displayed until I generate more output or update some other part of the
screen'
in this report. That doesn't sound like something your EXA change would help
with.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=33977

--- Comment #12 from Marcin Slusarz <marcin.slusarz at gmail.com>
2011-02-09 12:22:00 PST ---
Maarten: your latest ddx patch (exa: Flush (S)IFC to the frontbuffer
immediately) fixed this bug for me. I had very similar effects in xterm as the
reporter.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=33977

--- Comment #13 from Maarten Maathuis <madman2003 at gmail.com> 2011-02-09
12:28:36 PST ---
Just to be clear, nouveau uses a "FlushCallback" instead a call in the
BlockHandler. This should apparently cover more cases than the BlockHandler,
but I don't know the specifics.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=33977

--- Comment #14 from Maarten Maathuis <madman2003 at gmail.com> 2011-02-09
12:29:17 PST ---
That should be "instead of a call".

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=33977

--- Comment #15 from Michel D?nzer <michel at daenzer.net> 2011-02-09
22:37:50 PST ---
(In reply to comment #13)
> Just to be clear, nouveau uses a "FlushCallback" instead a call
in the
> BlockHandler. This should apparently cover more cases than the
BlockHandler,
> but I don't know the specifics.
Neither place alone is sufficient. Flushing in the FlushCallback is necessary
for DRI2 texture-from-pixmap and flushing in the BlockHandler is necessary to
avoid GPU commands being delayed indefinitely when the server goes idle.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=33977

Ilia Mirkin <imirkin at alum.mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #16 from Ilia Mirkin <imirkin at alum.mit.edu> ---
It appears that this bug report has laid dormant for quite a while. Sorry we
haven't gotten to it. Since we fix bugs all the time, chances are pretty
good
that your issue has been fixed with the latest software. Please give it a shot.
(Linux kernel 3.10.7, xf86-video-nouveau 1.0.9, mesa 9.1.6, or their git
versions.) If upgrading to the latest isn't an option for you, your
distro's
bugzilla is probably the right destination for your bug report.

In an effort to clean up our bug list, we're pre-emptively closing all bugs
that haven't seen updates since 2011. If the original issue remains, please
make sure to provide fresh info, see http://nouveau.freedesktop.org/wiki/Bugs/
for what we need to see, and re-open this one.

Thanks,

The Nouveau Team

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130819/31d27d80/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=33977

--- Comment #17 from Vincent Lefevre <vincent-fdt at vinc17.net> ---
It would be better to close this bug as FIXED, since it was really fixed,
apparent around 2011-02-24 and two months later in Debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614938

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130819/8c458743/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=33977

Ilia Mirkin <imirkin at alum.mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |FIXED

--- Comment #18 from Ilia Mirkin <imirkin at alum.mit.edu> ---
It was probably apparent, but it was a bulk message, I didn't really look at
each item too carefully but rather used the date of comments as the closing
criteria. Updating the status to FIXED instead of INVALID.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130819/2b7d033a/attachment.html>