[Nouveau] NV50: xv fullscreen issues

Sat Dec 27 04:18:14 PST 2008

On 12/27/2008 12:36 PM, Daniel Eklöf wrote:
>> 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.
>    

I made that change for one simple reason, to easily expose that dma wait 
is happening. I'll have a look at it soon'ish again and make changes 
where necessary. Thanks for pointing that out, I hadn't realised that 
the counter takes that long.

>    
>>> 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
>>>        
>
> _______________________________________________
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
>    