Bug 1193 - xv slow under some circumstances
Summary: xv slow under some circumstances
Status: RESOLVED INVALID
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: highest major
Assignee: Xorg Project Team
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-08-26 10:15 UTC by Jasmin Buchert
Modified: 2006-04-02 01:50 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Jasmin Buchert 2004-08-26 10:15:06 UTC
If I run tvtime or kdetv the X process takes 100% CPU and the video is  
skipping. I believe its an issue with Xorg & XFree and perhaps related to the  
following bug reports:  
http://bugs.xfree86.org/show_bug.cgi?id=414 
http://sourceforge.net/tracker/index.php?func=detail&aid=759804&group_id=64301&atid=506987 
  
I've tested tvtime with XIG's Accelerated X Summit DX (www.xig.com) and it's  
working perfectly with full framerate and only takes 15-30% CPU.  
  
I'm using the radeon driver with a Sapphire ATI Radeon 9200.
Comment 1 Alex Deucher 2004-12-19 12:01:55 UTC
please try again with xorg from cvs.
Comment 2 Jasmin Buchert 2004-12-20 11:26:53 UTC
The recently added Xv DMA support made things better with tvtime (~30% cpu are 
now idle and the X process takes about ~48% CPU). But I somehow think that's 
slower than it should be. 
 
I'm observing the following issues that are maybe linked to this: 
Some SDL applications display so slow that I can see them redrawing. 
A strange thing is, that sometimes when X is freshly running, the speed is a 
lot slower than normal. Then running glxinfo helps. 
I believe it has something to do with glxinfo (and other apps) "hanging" X for 
some seconds when X has just started up and its the first GL app running. It 
seems the driver is loading the R200 microcode then. 
 
Also strange things happend with xcompmgr: 
- Starting xcompmgr -c in an Eterm on Desktop 1 (running KDE): 
  Eterm's move around fast - no problems. 
- Switch to Desktop 2: 
  Here's a fullscreen Konqueror window. I move it around and speed is good. 
- Swiching back to Desktop 1: 
  Things are okay 
- Switch again to Desktop 2 (switching takes alot longer): 
  Konqueror window rendering & moving is slow now 
 
If I continue this, the speed of the Eterm's stays good, but switching 
desktops/the Konqueror window are slow. Running 'glxinfo' now makes things 
extremely slower. 
 
Comment 3 Jana Saout 2005-08-30 17:15:34 UTC
This (or at least the last thing you reported) is not an Xv bug. I am also
seeing this one.

Sometimes a simple XRender operation with PictOpOver which is just a simple copy
operation in an offscreen buffer, like when GTK+ is copying a background image
for the desktop, or when xcompmgr is compositing, is awfully slow.

And real slow. 1024x768 takes nearly half a second on a 1,5 GHz machine.
Sometimes  later it's fast again (so fast that no delay is noticeable at all.

Every time I interrupt gdb it is in fbCopyAreammx and I don't see anything
special about it. And I don't really know what makes the X server go slow and
what makes it go fast again. Heavy use of offscreen buffers seems to trigger
changes between expected and awfully slow mode or something... (?)

I'm seeing this with the latest CVS (modular xorg-server) on a Radeon 8500 and
on a Radeon Mobility M7 (7500).

There seem to be some bugs here which seem to describe symptoms of the same
basic problem. Someone could refile a bug with the correct description if he
figures out what's going wrong. It's really very annoying.
Comment 4 Erik Andren 2006-03-12 23:56:07 UTC
Whats the status of this bug using a current version of xorg?
Comment 5 Erik Andren 2006-04-02 19:50:26 UTC
I'm closing this bug due to the lack of activity, if the problem persists with a
current release of xorg, please reopen. 


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.