From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel =?iso-8859-1?q?Ekl=F6f?= Subject: Re: NV50: xv fullscreen issues Date: Sat, 27 Dec 2008 12:36:37 +0100 Message-ID: <200812271236.37993.daniel@ekloef.se> References: <200812260140.38609.daniel@ekloef.se> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nouveau-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org Errors-To: nouveau-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org To: Ben Skeggs Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org List-Id: nouveau.vger.kernel.org > On 12/26/08, Daniel Ekl=F6f 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=3D, = size=3D2) at nouveau_dma.c:88 #1 0x00007f63f5f4f01d in nouveau_dma_begin (userchan=3D0x241aaf0, = grobj=3D0x241a900, method=3D4916, size=3D1, file=3D0x7f63f5f5b630 "NV50EXAPrepareComposite", line=3D695) at = nouveau_dma.h:118 #2 0x00007f63f5f509b0 in NV50EXAPrepareComposite (op=3D, = pspict=3D0x3eb9210, pmpict=3D0x3bad6c0, pdpict=3D0x3543430, pspix=3D0x2f21de0, pmpix=3D0x522f4c0, pdpix=3D0x5a39230) 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 simil= ar) = 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 h= as = reached a certain value. Two things about this: 1) the counter goes all the way up to 0xffffffff. This took ~25s on my lapt= op = 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 tak= es = 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 s= et > > in xorg.conf. The EDID output does report 1680x1050, and xrandr also se= es > > 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=3D16M] > > Memory at c0000000 (64-bit, prefetchable) [size=3D256M] > > Memory at d0000000 (64-bit, non-prefetchable) [size=3D32M] > > I/O ports at a000 [size=3D128] > > Expansion ROM at d3000000 [disabled] [size=3D128K] > > Capabilities: [60] Power Management version 2 > > Capabilities: [68] MSI: Mask- 64bit+ Count=3D1/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=F6f > > _______________________________________________ > > Nouveau mailing list > > Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org > > http://lists.freedesktop.org/mailman/listinfo/nouveau