On 12/27/2008 12:36 PM, Daniel Eklöf wrote: >> On 12/26/08, Daniel Eklöf<[email protected]> 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 >>> [email protected] >>> http://lists.freedesktop.org/mailman/listinfo/nouveau >>> > > _______________________________________________ > Nouveau mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/nouveau > _______________________________________________ Nouveau mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/nouveau
