Bug 33977

git bisect reveals the culprit:
9a5142fae6e1a0a470352f511427916e6fa01b9c is the first bad commit
commit 9a5142fae6e1a0a470352f511427916e6fa01b9c
Author: Maarten Maathuis <madman2003@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@gmail.com>

(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.

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.

(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?

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.

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.

(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).

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?

(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.

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.

(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.

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.

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.

That should be "instead of a call".

(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.

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

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

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.