Nouveau - Jun 2008 - [Bug 16231] New: Xv tearing after upgrade to Fedora 9

http://bugs.freedesktop.org/show_bug.cgi?id=16231

           Summary: Xv tearing after upgrade to Fedora 9
           Product: xorg
           Version: git
          Platform: x86-64 (AMD64)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Driver/nouveau
        AssignedTo: nouveau at lists.freedesktop.org
        ReportedBy: drzeus-bugzilla at drzeus.cx
         QAContact: xorg-team at lists.x.org


I upgraded my machine to Fedora 9 yesterday to get access to the new X server.
Unfortunately, nouveau stopped syncing the video properly during the upgrade.
:/

I reinstalled the machine with an x86_64 arch (from i386), so unfortunately I
do not know if it's the new system or the new arch that caused the problem.

All three backends (both texture and overlay) are affected. The card is a NV40
one. Problem even with one CRTC running (I normally have both active).

I haven't done any deep debugging yet, but if anyone has any ideas then it
would be helpful. I couldn't see any changes in the git history for quite
some
time.


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

http://bugs.freedesktop.org/show_bug.cgi?id=16231





--- Comment #1 from Pierre Ossman <drzeus-bugzilla at drzeus.cx> 
2008-06-04 13:28:36 PST ---
I should probably clarify that when I say it "stopped syncing
properly", that
it hasn't stopped syncing completely. I can see that the driver is limiting
Xv
frames to the refresh rate, but it still manages to miss the blanking period.
The tear is frequent, and all over the place.

I have experimented with making a test application but have so far been unable
to provoke the issue outside of mplayer.


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

http://bugs.freedesktop.org/show_bug.cgi?id=16231





--- Comment #2 from Pierre Ossman <drzeus-bugzilla at drzeus.cx> 
2008-06-13 13:35:46 PST ---
After some debugging and discussion on #nouveau, it was determined that this is
caused by mplayer creating its windows with backing store enabled. The newer
Xorg in F9 makes these windows end up off screen, which makes nouveau ignore
syncing (rightfully so).

So the question is how/why this worked in the Xorg in F8 and if that behaviour
can be moved over to the new server. It might also simply be that mplayer
shouldn't be requesting backing store.

Btw, the log says that backing store is disabled which I'd expect to give
the
effect that windows are always created without it.


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

http://bugs.freedesktop.org/show_bug.cgi?id=16231





--- Comment #3 from Pierre Ossman <drzeus-bugzilla at drzeus.cx> 
2008-06-13 13:52:47 PST ---
One solution is also to make sure things are vsync:ed when they are transferred
on screen by the X server. I did a quick hack in NVExaCopy() that solved the
issue:

        if (NVExaPixmapIsOnscreen(pDstPixmap)) {
                uint8_t crtcs = nv_window_belongs_to_crtc(pScrn, dstX, dstY,
width, height);

                FIRE_RING();
                if (crtcs & 0x1)
                        NVWaitVSync(pScrn, 0);
                else if (crtcs & 0x2)
                        NVWaitVSync(pScrn, 1);
        }

It slows down a whole bunch of operations though, so it would need to be a bit
more clever.


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

http://bugs.freedesktop.org/show_bug.cgi?id=16231





--- Comment #4 from Pierre Ossman <drzeus-bugzilla at drzeus.cx> 
2008-06-13 14:48:26 PST ---
For reference, here's the diff that causes this:

http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=blobdiff;h=c557eebc4de017e2bd266b7fe0bb9e5d1c791038;hp=630f1042c103cc1e7525f621cce9c84367774c3c;hb=ae7f71a8b3d6756161e55d998d6eec37d2695c98;f=composite/compinit.c

It causes an implicit redirect whenever backing store is enabled. So one
"solution" is simply to disable the composite extension.


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

http://bugs.freedesktop.org/show_bug.cgi?id=16231





--- Comment #5 from Maarten Maathuis <madman2003 at gmail.com>  2008-06-13
14:54:31 PST ---
NVWaitVSync stalls everything, this is not useful for generic rendering. Better
solutions involve a lot more effort (and i'm certainly not the one to judge
what is the right way). The problem you want solved is a lot larger then you
might think.


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

http://bugs.freedesktop.org/show_bug.cgi?id=16231


Pierre Ossman <drzeus-bugzilla at drzeus.cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ajax at nwnk.net
            Summary|Xv tearing after upgrade to |Xv vsync and backing store
                   |Fedora 9                    |don't mix in new Xorg




--- Comment #6 from Pierre Ossman <drzeus-bugzilla at drzeus.cx> 
2008-06-14 02:38:46 PST ---
The problem I want solved is to get mplayer to start working with vsync again.
That doesn't have to mean that backing store gets vsync behaviour. Altough
turning of composite works for my use case, it's probably not a good long
term
solution.

I'm adding ajax as a cc here as he was the one that reimplemented the
backing
store.

How did the backing store work before the rewrite? Did it track the damage of
the framebuffer and had a backup copy? If so, was the change of behaviour in
the new version fully realised?

If the easiest route is to get applications to change, then some arguments are
needed why this isn't a bug/regression in Xorg, but applications relying on
something they were never supposed to have.


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

http://bugs.freedesktop.org/show_bug.cgi?id=16231





--- Comment #7 from ajax at nwnk dot net <ajax at nwnk.net>  2008-06-23
11:33:50 PST ---
(In reply to comment #6)
> The problem I want solved is to get mplayer to start working with vsync
again.
> That doesn't have to mean that backing store gets vsync behaviour.
Altough
> turning of composite works for my use case, it's probably not a good
long term
> solution.
> 
> I'm adding ajax as a cc here as he was the one that reimplemented the
backing
> store.
> 
> How did the backing store work before the rewrite? Did it track the damage
of
> the framebuffer and had a backup copy? If so, was the change of behaviour
in
> the new version fully realised?
> 
> If the easiest route is to get applications to change, then some arguments
are
> needed why this isn't a bug/regression in Xorg, but applications
relying on
> something they were never supposed to have.
I'm completely at a loss to understand why a) mplayer needs backing store at
all, b) how it manages to interact with vsync.  It's not like you ever had
control over when drawing happened in X relative to vsync...


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

http://bugs.freedesktop.org/show_bug.cgi?id=16231





--- Comment #7 from ajax at nwnk dot net <ajax at nwnk.net>  2008-06-23
11:33:50 PST ---
(In reply to comment #6)
> The problem I want solved is to get mplayer to start working with vsync
again.
> That doesn't have to mean that backing store gets vsync behaviour.
Altough
> turning of composite works for my use case, it's probably not a good
long term
> solution.
> 
> I'm adding ajax as a cc here as he was the one that reimplemented the
backing
> store.
> 
> How did the backing store work before the rewrite? Did it track the damage
of
> the framebuffer and had a backup copy? If so, was the change of behaviour
in
> the new version fully realised?
> 
> If the easiest route is to get applications to change, then some arguments
are
> needed why this isn't a bug/regression in Xorg, but applications
relying on
> something they were never supposed to have.
I'm completely at a loss to understand why a) mplayer needs backing store at
all, b) how it manages to interact with vsync.  It's not like you ever had
control over when drawing happened in X relative to vsync...


--- Comment #8 from Maarten Maathuis <madman2003 at gmail.com>  2008-06-23
11:57:34 PST ---
(In reply to comment #7)
> (In reply to comment #6)
> > The problem I want solved is to get mplayer to start working with
vsync again.
> > That doesn't have to mean that backing store gets vsync behaviour.
Altough
> > turning of composite works for my use case, it's probably not a
good long term
> > solution.
> > 
> > I'm adding ajax as a cc here as he was the one that reimplemented
the backing
> > store.
> > 
> > How did the backing store work before the rewrite? Did it track the
damage of
> > the framebuffer and had a backup copy? If so, was the change of
behaviour in
> > the new version fully realised?
> > 
> > If the easiest route is to get applications to change, then some
arguments are
> > needed why this isn't a bug/regression in Xorg, but applications
relying on
> > something they were never supposed to have.
> 
> I'm completely at a loss to understand why a) mplayer needs backing
store at
> all, b) how it manages to interact with vsync.  It's not like you ever
had
> control over when drawing happened in X relative to vsync...
> 
As a special case, when composite isn't used, we stall the rendering engine
so
xvideo looks good. This was a quick way to get reasonable results.


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

http://bugs.freedesktop.org/show_bug.cgi?id=16231





--- Comment #9 from Pierre Ossman <drzeus-bugzilla at drzeus.cx> 
2008-06-23 12:48:25 PST ---
(In reply to comment #7)
> 
> I'm completely at a loss to understand why a) mplayer needs backing
store at
> all, b) how it manages to interact with vsync.  It's not like you ever
had
> control over when drawing happened in X relative to vsync...
> 
a) If I'd guess, I'd say it was a quick way to avoid having to deal with
keeping the color key updated, and it has worked just fine up til now.

b) As Maarten said, the rendering (specifically, the PutImage operations) is
stalled until vsync blanking, but only if the target Xv window is on screen.
The new backing store code moved the window off screen.


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

http://bugs.freedesktop.org/show_bug.cgi?id=16231


Pekka Paalanen <pq at iki.fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pq at iki.fi




--- Comment #10 from Pekka Paalanen <pq at iki.fi>  2008-06-23 14:36:22
PST ---
I have nv20, and both the overlay and blitter work the same: I have a static
horizontal tearing line, location depending on window size.

Section "Extensions"
        Option "Composite" "off"
EndSection

With Composite disabled with the above config, blitter now works fine. Overlay
on the other hand does not, video appears jerky and there is occasional tearing
at random places. I'll file a separate bug report on this.

I do not have a texture adapter. Xorg-server is from git.

I've posted a comment to the mplayer-users list.
http://article.gmane.org/gmane.comp.video.mplayer.user/57029


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

http://bugs.freedesktop.org/show_bug.cgi?id=16231





--- Comment #11 from Danny <obiwan at mailmij.org>  2008-06-29 19:13:37
PST ---
I also cannot use the overlay any longer with git xorg (nv34 on powerpc, but I
do not experience the overlay problem without composite as in the last comment,
this seems to be a separate bug).

I agree that this problem is probably in mplayer, but there is however at least
one bug in X here: it says in the log that the backingstore is disabled, but it
is not. And all disabling it at commandline or in xorg.conf does not have any
effect.

d.


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

http://bugs.freedesktop.org/show_bug.cgi?id=16231





--- Comment #12 from Pierre Ossman <drzeus-bugzilla at drzeus.cx> 
2008-12-04 03:57:23 PST ---
Mplayer has been fixed to not use backing store.


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

http://bugs.freedesktop.org/show_bug.cgi?id=16231


Younes Manton <younes.m at gmail.com> changed:

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




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