[Nouveau] NV50: xv fullscreen issues

[Daniel Eklöf]

> On 12/26/08, Daniel Eklöf <daniel at ekloef.se> wrote:
> > Hi,
> >
> > I've been trying out nouveau for a while now and I must say I'm
> > impressed. Performance in KDE4 in general seems better than the nvidia
> > blob; way to go!
> >
> > There are a couple of annoyances though:
> >
> > XV in fullscreen doesn't work. I'm running in composite mode, and non
> > fullscreen video works well enough. Going fullscreen in e.g gmplayer
> > gives me:
> >
> > [ws] Error in display. -0.005 ct: -0.000  25/ 25 30% 23%  0.8% 3 6
> >
> > [ws]  Error code: 8 ( BadMatch (invalid parameter attributes) )
> >
> > [ws]  Request code: 140
> >
> > [ws]  Minor code: 19
> >
> > [ws]  Modules: flip_page
> >
> > xine crashes in a similar way. mplayer (non GUI version) doesn't crash,
> > but all I get is a black screen with "BadMatch" errors spamming the
> > console.
> >
> > The BadMatch is from nv50_xv.c:54
> >
> >        if (exaGetPixmapOffset(ppix) < pNv->EXADriverPtr->offScreenBase)
> >                 return FALSE;
> >
> > commenting out those lines stops the players from crashing, but I still
> > get just a black screen.
>
> I'm typing this from a mobile phone so answers will be brief sorry!

No problem! I'm grateful for any kind of answers :)

> Your composite manager is probably unredirecting fullscreen windows.
> We can't currently render directly to the scanout buffer with the 3D
> engine, which is what the above code checks for.

Ok, good to know, thanks.

> > After having crashed gmplayer (with the code lines above re-enabled), I
> > also notice that screen updates are a bit shaky - sometimes the screen
> > isn't updated until I press a key or move the mouse (e.g. typing 'ls'
> > doesn't list any files until I press another key, web pages aren't
> > displayed until I move the mouse and so on). At this point, I sometimes
> > also see an unusually high CPU load from X (around 75%). Sometimes X
> > freezes, sometimes not.
>
> I don't see this on my systems, but i'll look into it when i'm back in
> action.

After some more testing, I can say for sure that this isn't really related to 
the xv fullscreen issue. xv in fullscreen was just a way to trigger it. I'm 
not sure exactly what triggers it though - starting certain GUI programs 
triggers it, while other programs do not. In any case, I'm pretty sure the 
high CPU load is always there when I see the screen update issue. When this 
happens, X is stuck inside nouveau_dma_wait:

(gdb) bt
#0  0x00007f63f5f18df8 in nouveau_dma_wait (userchan=<value optimized out>, 
size=2) at nouveau_dma.c:88
#1  0x00007f63f5f4f01d in nouveau_dma_begin (userchan=0x241aaf0, 
grobj=0x241a900, method=4916, size=1,
    file=0x7f63f5f5b630 "NV50EXAPrepareComposite", line=695) at 
nouveau_dma.h:118
#2  0x00007f63f5f509b0 in NV50EXAPrepareComposite (op=<value optimized out>, 
pspict=0x3eb9210, pmpict=0x3bad6c0, pdpict=0x3543430,
    pspix=0x2f21de0, pmpix=0x522f4c0, pdpix=0x5a39230) at nv50_exa.c:695
#3  0x00007f63f457de6a in ?? () from /usr/lib64/X11/modules//libexa.so
#4  0x00007f63f457f097 in exaComposite () from 
/usr/lib64/X11/modules//libexa.so
#5  0x000000000053029f in ?? ()
#6  0x000000000051f0ad in ?? ()
#7  0x0000000000447ef6 in Dispatch ()
#8  0x000000000042d82d in main ()

On a side note, out of curiousity I took a look at the dma_wait code; and I 
found myself wondering if the CHECK_TIMEOUT macro is really ok. My 
understanding is that it tries to avoid an expensive gettimeofday (or similar) 
in the normal case where the DMA doesn't timeout. It does this by first 
incrementing a counter, and only checks the actual time after the counter has 
reached a certain value.

Two things about this:

1) the counter goes all the way up to 0xffffffff. This took ~25s on my laptop 
and ~13s on my main. As a comparison, the DMA timeout value is 2s

2) It doesn't assign a value to t_start until after the counter has reached 
0xffffffff. Again, I guess this is to avoid an expensive gettimeofday. 
However, it also means that the actual timeout value now is the time it takes 
to increment the counter _plus_ the DMA timeout value.

This may all be by design, but it did strike me as a bit suspiouses.

> > One more odd thing is that I don't get any interrupts on the NV50 during
> > "normal use" (as reported by /proc/interrupts). I sometimes get an
> > interrupt storm when starting X, then nothing. I sometimes see a number
> > of interrupts after having crashed gmplayer when trying to play a video
> > fullscreen. But other than that, no interrupts what so ever.
>
> Completely normal, we don't currently make use of interrupts from the
> gpu save for error reporting.

Ok, I thought it may be something like that. The nvidia blob does generate 
interrupts occasionally, so I guess I was expecting nouveau to behave in a 
similar way.

> > One last question, and this may not even be nouveau related since I also
> > see this with the nv driver (so please feel free to yell RTFM! or just
> > ignore it
> >
> > :) ). If I start X as a non-root user, it choses 1280x1024 as default
> >
> > resolution (the panel's native resolution is 1680x1050). I dont't see
> > this in KDM, or when starting as root (so, I can for example start kdm in
> > the correct resolution, but then when I log in, as non-root, the
> > resolution is changed to 1280x1024). It doesn't seem to matter what I set
> > in xorg.conf. The EDID output does report 1680x1050, and xrandr also sees
> > it. In fact, just opening the "Display" settings in KDE's control panel
> > causes a switch to 1680x1050. Needless to say, the binary nvidia driver
> > doesn't have this problem.
> >
> > Random system info:
> >
> > Linux tiny 2.6.28 #1 SMP Thu Dec 25 12:45:15 CET 2008 x86_64 AMD
> > Athlon(tm) 64 X2 Dual Core Processor 4400+ AuthenticAMD GNU/Linux
> >
> > 01:00.0 VGA compatible controller: nVidia Corporation GeForce 8600 GTS
> > (rev a1) (prog-if 00 [VGA controller])
> >         Subsystem: ASUSTeK Computer Inc. Device 8241
> >         Flags: bus master, fast devsel, latency 0, IRQ 18
> >         Memory at d2000000 (32-bit, non-prefetchable) [size=16M]
> >         Memory at c0000000 (64-bit, prefetchable) [size=256M]
> >         Memory at d0000000 (64-bit, non-prefetchable) [size=32M]
> >         I/O ports at a000 [size=128]
> >         Expansion ROM at d3000000 [disabled] [size=128K]
> >         Capabilities: [60] Power Management version 2
> >         Capabilities: [68] MSI: Mask- 64bit+ Count=1/1 Enable-
> >         Capabilities: [78] Express Endpoint, MSI 00
> >         Capabilities: [100] Virtual Channel <?>
> >         Capabilities: [128] Power Budgeting <?>
> >         Capabilities: [600] Vendor Specific Information <?>
> >
> > Using latest git libdrm and nouveau sources, xorg-7.4 (server-1.5.3). If
> > there's any other info you need, just let me know.
> >
> > Regards,
> > Daniel Eklöf
> > _______________________________________________
> > Nouveau mailing list
> > Nouveau at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/nouveau