Bug 6260

Created attachment 4933 [details]
Sample conky configuration file

Sample conky (http://conky.sourceforge.net/) configuration file to reproduce
problem. This one is with doublebuffering enabled to disable it edit the
double_buffer section in this file.

Created attachment 4934 [details]
xorg.conf

My system xorg configuration file.

I think profiler output would be nice too. But I am not sure how to make it. Is
there any guide about that on the net ?

It seems this is not related to Radeon or PPC only. I am currently in front of a
x86 machine and I can perfectly reproduce this problem here.

This is P4 2.8GHz with 512MB of memory and Via Unichrome VM800. This machine has
the same Xorg version as me (7.0) with today OpenChrome SVN snapshot.

Playing video on mplayer using xv output and gl2 output gives same glitches
here. The same for glxgears. I also test it using plain x11 output driver and
the video is jumpy too.
This is not visible all the time, mainly with large moving scenes but using
glxgears it's easy to notice.

conky probably triggers a software fallback in the X server. There's not much
that can be done about that causing glitches.

For profiling, I can recommend oprofile, or sysprof (on x86*).

The same on SuperKaramba. I wonder this is problem related to Xorg or 
Conky/SuperKaramba ? Can you explain a bit more about that ? I will try to 
recompile xorg-server and profile it, but only if it has some sense ? This 
would a quite long time for my system.

A software fallback is ultimately a missing feature (or possibly even a bug) in
the X server, but it's possible that the applications could do better as well.
It might be hard to get useful profiling data as the problem is usually caused
by relatively short bursts of activity. At the very least, you'll probably need
to restrict the profiling to the X server. On the bright side, the profiling
tools I mentioned don't require a rebuild unless the binaries don't have any
useful symbols.

I see. I will try to profile it as soon as possible and we will see, but IMHO 
this is not software fallback. My conclusion comes from ... why I can easily 
reproduce it on machine like P4 2.8GHz ? It's realy fast machine and propably 
any software part of code won't cause so heavy display glitch on simple glxgears 
window. Have I right ? I am not an expert here then I can be wrong of coz.

The CPU speed isn't necessarily very important for the effect of software
fallbacks. For one, software rendering is usually limited by the access to video
RAM, which is much slower than access to system RAM. More importantly though,
software fallbacks require draining the graphics card command queue and caches,
etc. The effect is probably particularly noticeable with glxgears as it renders
so many frames that even just a short delay is a noticeable irregularity.
Similarly, with video playback, you probably notice very quickly when a single
frame is delayed slightly.

Another one point for you. It's realy hard to trace what cause thich small
lockups (glitches) But I did'a a small profile of EXA here. I reported that long
time ago (EXA is terrible slow here) and it's seems when EXA is enabled the Xorg
spents almost 50% time in fbBlt() function in libfb.

fbBlt is a software fallback. It would be interesting if you could find out what
triggers it, e.g. if you could get call traces from the profile data.

Is this still an issue with EXA and the radeon driver from CVS HEAD?

BTW, is there a reason why you disable DMAForXv? Does the Xv behaviour improve
if you enable it?

Also, does not enabling ColorTiling help? With it and the DRI enabled, the
radeon driver currently has to do expensive calls into the kernel to set up
hardware surfaces for byte swapping with software fallbacks on big endian machines.

Hmmm, sorry about the delay. I have no ideas why but I didn't get any emial
notification about your reply.

Anyway I am compiling the today CVS snap of xorg-server, mesa and ati drivers
and we will see it's still present or no. I will give a try to disable
ColorTiling too.

The DMAforXv is disabled for a reason. I read it should speedup the XVideo, but
on my machine this option cause a speed loose on files with a high resolution
(For example DVD movies) The image is jumpy and generaly this looks similar to
problem caused by superkaramba/conki in doublebuffer mode. Anyway as far I know
DMA for GFX memory on Pegasos II is a bit slow then maybe this is a reason.

The problem is still reproduceable with today CVS snap too and disabling
ColorTiling didn't help at last for this problem.

Anyway if CT is slower on bigendian machines maybe there is a good idea to add a
information about that to the man page ? What do you think ?

OK, finaly found a free time to recompile xog-server && mesa && xf86-video-ati
with debug symbols a do a small profile session with oprofile.

It seems this still is a problem as I can see ~65% of Xorg CPU time is spend in
libfb.so/fbBlt24() function on my system.

CPU: CPU with timer interrupt, speed 0 MHz (estimated)
Profiling through timer interrupt
samples  %        image name               symbol name
50587    62.0357  libfb.so                 fbBlt24
15530    19.0447  libc-2.4.so              (no symbols)
2075      2.5446  libfb.so                 fbBresFillDash
768       0.9418  libexa.so                ExaOffscreenMarkUsed
577       0.7076  libfb.so                 fbCompositeSolidMask_nx8x0565
371       0.4550  libexa.so                exaOffscreenAlloc
357       0.4378  Xorg                     _fini
272       0.3336  libexa.so                exaOffscreenFree
237       0.2906  libexa.so                exaPixmapIsOffscreen
228       0.2796  libfb.so                 fbBltOne
207       0.2538  Xorg                     miRegionOp
165       0.2023  libexa.so                exaPixmapIsPinned
163       0.1999  libexa.so                exaDoMigration
155       0.1901  radeon_drv.so            RADEONDRISwapContext
138       0.1692  Xorg                     miComputeCompositeRegion
136       0.1668  libexa.so                exaComposite
135       0.1656  radeon_drv.so            R200PrepareCompositeCP
131       0.1606  radeon_drv.so            RADEONDRIGetVersion
127       0.1557  libexa.so                exaCopyArea
126       0.1545  radeon_drv.so            RADEONCopyCP
125       0.1533  libexa.so                exaFillRegionTiled
124       0.1521  libexa.so                exaGetOffscreenPixmap
116       0.1423  libfb.so                 fbBresSolid32
110       0.1349  libexa.so                exaGlyphs
105       0.1288  libexa.so                exaGetDrawablePixmap
103       0.1263  radeon_drv.so            RADEONDRIScreenInit
100       0.1226  libexa.so                exaCopyNtoN
100       0.1226  libexa.so                exaCreatePixmap

Created attachment 5913 [details]
Full oprofile log

Created attachment 5914 [details]
Current xorg.conf

I guess there is good idea to find what calls this function here. I looked at
oprofile documentation but was unable to find anything about call traces. How to
produce such information ?

I still have unstripped versions of Xorg components then I think I can try to help.

opreport -c will include call graph information, but this requires that the
oprofile kernel module can actually record it, which it traditionally couldn't
on PPC.

Looking at the profile, it's most likely related to fbBresFillDash, i.e. dashed
lines. These are typically used by legacy apps, and it's unlikely that EXA will
ever accelerate them. So your best bet might be to configure or change conky not
to use dashed lines and/or to update its display less frequently.

Stupid me I forgot I am using -fommit-frame-pointer by default and now I am
forced to recompile the xorg again. Anyway in this time I take a short look at
xorg sources and generaly there is not so many places where fbBlt() is used.

exa/exa_accel.c/exaPutImage():224 But I think it's not this point because radeon
have a accelerated UploadToScreen then propably this wont happend.

miext/rootless/rootlessWindow.c/StartFrameResize():919 Hmmmm, this seems to
fallback to fbBlt() if:

            if (copy_rect_width * copy_rect_height >
                        rootless_CopyBytes_threshold &&
                SCREENREC(pScreen)->imp->CopyBytes)

Fail. We will see soon I hope. This hardware is slow enough to compile Xorg more
than 1.5h ...

You could rebuild only fb and maybe exa for a start... the Xorg server doesn't
use the rootless code, and fbBresFillDash also uses fbBlt indirectly, which is
why I suspect it's related to that.

Hmmmm, weird. The opreport -cl --demangle=smart `which X` doesn't show me
anything usefull, but xorg is compiled with frame pointers.

CPU: CPU with timer interrupt, speed 0 MHz (estimated)
Profiling through timer interrupt
samples  %        image name               symbol name
-------------------------------------------------------------------------------
50587    31.6699  libfb.so                 fbBlt24
  50587    100.000  libfb.so                 fbBlt24 [self]
-------------------------------------------------------------------------------
......

I wonder what I miss this time.

See the first paragraph of comment #19.

Hmmm, ThX for information, I miss this comment. I guess then we can close this
bug now. Is that true ?

Changing the summary and moving this down to enhancement.  I could imagine us
doing acceleration for horizontal/vertical dashed lines, which is what I assume
the app is using, so I'm not just closing it outright.

Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

Any update? Is this still an issue?

No response.  Closing.