Bug? Anomalous CPU usage when playing HDTV clips.
Ivan, I couldn't find an easy way to disable VSync in the X drivers. I'm not even sure all the configurations I tried this on have VSync capability. I'm not sure what you are referring to with regard to checking AGP tuning/speed. All systems tested are AGP 4x. I have been running some additional experiments that may shed some more light on the problem. I would say that this is some problem with X alone, but look at the last test that I run below. There is some very odd interaction that involves image size, fps, and X extensions being used that also affect mplayers cpu usage. Here's an interesting one. Double buffering extension(dbe) seems to have some odd effects. I ran a series of tests using: 1280x720 @ 30fps clip 1024x576 @ 30fps clip xv output x11 output dbe enabled dbe disabled Results ------- X CPU mplayer CPU 1280x720,xv,dbe 30 30 1280x720,x11,dbe 30 30 1280x720,xv,no-dbe 30 30 1280x720,x11,no-dbe negligible 30 1024x576,xv,dbe negligible 30 (you would think mplayer CPU should have dropped here by 50% due to smaller image size) 1024x576,x11,dbe negligible 30 1024x576,xv,no-dbe negligible 30 1024x576,x11,no-dbe negligible 5-20 (mostly under 10) HUH!?
I've just got another (simplier) idea. It could also be connected with VSync (changing picture on retrace). You can test this by increaseing monitor vertical refresh rate. Or finding option to disable VSync.
--- Ivan Kalvatchev <iive at yahoo.com> wrote:
Hmm quite interesting. My quess is that the you may have reached AGP limit. Could you check your AGP tunning/speed? Best Regards Ivan Kalvachev iive
Follow up to my last e-mail. Another variable in this is option PageFlip. It was on in the tests given in my last e-mail (speeds up glxgears). When turned off, results are like the non-dbe results below. This led me to try the gl drivers again and take a closer look. They are buggy, so I've been ignoring them until now. Using the vo gl, CPU usage actually looks pretty sane for both 1280x720 and 1024x576 @ 30fps. mplayer runs between 20% and 30%, X is negligible. But 1280 has broken video, nothing but a white display. Also, higher fps clips do not play at correct speed. Using the vo gl2, nothing plays at the correct speed. mplayer CPU usage is high, but below 60%, so its not due to pegging out the CPU. On Fri, 2004-03-19 at 16:14, John Stebbins wrote:
Ivan, I couldn't find an easy way to disable VSync in the X drivers. I'm not even sure all the configurations I tried this on have VSync capability.
I'm not sure what you are referring to with regard to checking AGP tuning/speed. All systems tested are AGP 4x.
I have been running some additional experiments that may shed some more light on the problem. I would say that this is some problem with X alone, but look at the last test that I run below. There is some very odd interaction that involves image size, fps, and X extensions being used that also affect mplayers cpu usage.
Here's an interesting one. Double buffering extension(dbe) seems to have some odd effects.
I ran a series of tests using: 1280x720 @ 30fps clip 1024x576 @ 30fps clip xv output x11 output dbe enabled dbe disabled
Results ------- X CPU mplayer CPU 1280x720,xv,dbe 30 30
1280x720,x11,dbe 30 30
1280x720,xv,no-dbe 30 30
1280x720,x11,no-dbe negligible 30
1024x576,xv,dbe negligible 30 (you would think mplayer CPU should have dropped here by 50% due to smaller image size) 1024x576,x11,dbe negligible 30
1024x576,xv,no-dbe negligible 30
1024x576,x11,no-dbe negligible 5-20 (mostly under 10) HUH!?
I've just got another (simplier) idea. It could also be connected with VSync (changing picture on retrace). You can test this by increaseing monitor vertical refresh rate. Or finding option to disable VSync.
--- Ivan Kalvatchev <iive at yahoo.com> wrote:
Hmm quite interesting. My quess is that the you may have reached AGP limit. Could you check your AGP tunning/speed? Best Regards Ivan Kalvachev iive
_______________________________________________ Mplayer-advusers mailing list Mplayer-advusers@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-advusers
Hi,
This led me to try the gl drivers again and take a closer look. They are buggy, so I've been ignoring them until now. Well, I'm the maintainer for these, so tell me if you find a bug (but be aware that some of their shortcomings are intentional)
Using the vo gl, CPU usage actually looks pretty sane for both 1280x720 and 1024x576 @ 30fps. mplayer runs between 20% and 30%, X is negligible. But 1280 has broken video, nothing but a white display. Also, higher fps clips do not play at correct speed. Don't know about those speed issues, but to play a 1280x720 video your graphics card must support 2048x2048 textures - which many notebook graphics cards probably won't.
Using the vo gl2, nothing plays at the correct speed. mplayer CPU usage is high, but below 60%, so its not due to pegging out the CPU. Assuming that your maximum texture size is 1024x1024, vo_gl2 will use _four_ textures of this size. Especially if your graphics card uses system RAM, your memory bus will be simply too slow for this.
Of course those are just guesses... Greetings, Reimar Döffinger
Hey, thanks for the reply. Do you know of a way to find out what size textures the graphics card supports? It appears that the max is 1024x1024 since mplayer reports using 2x1 1024x1024 textures for the 1280x720 size clip. So you're correct about the white screen behavior with the gl driver. Actually, this particular test was run on a desktop with an integrated intel chipset. I just re-ran on the laptop with an ATI Radeon Mobility M9 and 32MB video ram. FYI, glxgears reports about the same rate on each of these systems, about 1300fps. Both systems exhibit basically the same behavior. Both systems appear to have a max texture size of 1024x1024. To test the memory bandwidth theory, I ran some lower resolution clips. One is 1024x576, which requires a 1024x1024 texture. The other is 720x404 and requires a 1024x512 texture. Both clips are 30fps. With gl2 driver: 1024x576 clip runs slow, and does not consume all available CPU. 720x404 clip playback speed is correct. With gl driver: Both clips play back at proper speed. Hope this is useful information for you. If you would like a a copy of the 1024x576 clip to run any tests yourself, there's probably some way we can figure out to make it available. Its 14M. (Smaller than some M$ turd documents I've sent via e-mail :-P) John On Thu, 2004-04-01 at 11:47, Reimar Döffinger wrote:
Hi,
This led me to try the gl drivers again and take a closer look. They are buggy, so I've been ignoring them until now. Well, I'm the maintainer for these, so tell me if you find a bug (but be aware that some of their shortcomings are intentional)
Using the vo gl, CPU usage actually looks pretty sane for both 1280x720 and 1024x576 @ 30fps. mplayer runs between 20% and 30%, X is negligible. But 1280 has broken video, nothing but a white display. Also, higher fps clips do not play at correct speed. Don't know about those speed issues, but to play a 1280x720 video your graphics card must support 2048x2048 textures - which many notebook graphics cards probably won't.
Using the vo gl2, nothing plays at the correct speed. mplayer CPU usage is high, but below 60%, so its not due to pegging out the CPU. Assuming that your maximum texture size is 1024x1024, vo_gl2 will use _four_ textures of this size. Especially if your graphics card uses system RAM, your memory bus will be simply too slow for this.
Of course those are just guesses...
Greetings, Reimar Döffinger
_______________________________________________ Mplayer-advusers mailing list Mplayer-advusers@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-advusers
Hi,
Do you know of a way to find out what size textures the graphics card supports? It appears that the max is 1024x1024 since mplayer reports using 2x1 1024x1024 textures for the 1280x720 size clip. So you're correct about the white screen behavior with the gl driver. If you have Windows on the notebook as well, the GLinfo tool from http://www.delphi3d.net/hardware/ might help (didn't try it myself).
In addition for your original problem the output of xvinfo might be interesting as well.
To test the memory bandwidth theory, I ran some lower resolution clips. One is 1024x576, which requires a 1024x1024 texture. The other is 720x404 and requires a 1024x512 texture. Both clips are 30fps.
With gl2 driver: 1024x576 clip runs slow, and does not consume all available CPU.
What system configuration do you use (kernel version and GL driver type/version, glinfo or glxinfo might help). I tend to think that your CPU usage infomation isn't correct - I heard that especially notebooks can give you trouble here. Especially that xv and x11 vos give the same CPU usage seems very wrong to me, as the YV12->RGB conversion that is needed for x11 even a 2.4 GHz CPU can't do that easily (on my Athlon with 800Mhz it makes a difference of at least 8% CPU usage for a 352x288 clip!)
720x404 clip playback speed is correct.
With gl driver: Both clips play back at proper speed.
You might find -nosound -benchmark useful for testing.
Hope this is useful information for you. If you would like a a copy of the 1024x576 clip to run any tests yourself, there's probably some way we can figure out to make it available. Its 14M. (Smaller than some M$ turd documents I've sent via e-mail :-P)
I used -vf expand for testing - this should be even better as it puts additional load mostly onto the vo modules Greetings, Reimar Döffinger
Thanks for the tip about -benchmark. I hadn't seen that option. Very useful. I've been using various fedora releases. The laptop started out on fedora core 1. Its now got fedora 2 test 2 with kernel 2.6.3 and xorg X11. glxinfo: glx version 1.2 OpenGL version 1.3 Mesa 5.0.2 glu verion 1.3 About the YV12->RGB conversion, perhaps we were measuring the % differently. When using -benchmark, the time difference (VC) is 14s for x11 vs. 10s for xv, which would be more like 40%. But if looked at as %cpu usaged when playback is at normal speed, the difference in %cpu usaged is only a few % (like around 5). What's disturbing me is the time difference for VO. I get 7s for x11 vs. 21s for xv. Total play times are 22s for x11 vs. 32s for xv. Total time using XV is always longer than with x11 in these tests. This has been a good thought exerciser for me. I just remembered that I have been purposely excluding scaling from my tests so as to narrow the variables. I just re-ran several of the same tests, scaling to fullscreen. When I do this, x11 gets dramatically slower, while XV stays about the same. So, I think what I'm seeing could be one of 2 subtly different things. 1. XV has an overhead per frame (which is dependent on image size) that exceeds (by 4x) the amount of time mplayer can do color space conversion in. or 2. Mplayer does color conversion about 4 times faster than XV. In either case, XV scales images essentially infinitely fast. I don't see any options that would allow me to force color conversion in software by mplayer and still use XV for scaling output. Aside from hacking on the code, I don't see a way to distinguish these possibilities. Any ideas? John On Fri, 2004-04-02 at 07:56, Reimar Döffinger wrote:
Hi,
Do you know of a way to find out what size textures the graphics card supports? It appears that the max is 1024x1024 since mplayer reports using 2x1 1024x1024 textures for the 1280x720 size clip. So you're correct about the white screen behavior with the gl driver. If you have Windows on the notebook as well, the GLinfo tool from http://www.delphi3d.net/hardware/ might help (didn't try it myself).
In addition for your original problem the output of xvinfo might be interesting as well.
To test the memory bandwidth theory, I ran some lower resolution clips. One is 1024x576, which requires a 1024x1024 texture. The other is 720x404 and requires a 1024x512 texture. Both clips are 30fps.
With gl2 driver: 1024x576 clip runs slow, and does not consume all available CPU.
What system configuration do you use (kernel version and GL driver type/version, glinfo or glxinfo might help). I tend to think that your CPU usage infomation isn't correct - I heard that especially notebooks can give you trouble here. Especially that xv and x11 vos give the same CPU usage seems very wrong to me, as the YV12->RGB conversion that is needed for x11 even a 2.4 GHz CPU can't do that easily (on my Athlon with 800Mhz it makes a difference of at least 8% CPU usage for a 352x288 clip!)
720x404 clip playback speed is correct.
With gl driver: Both clips play back at proper speed.
You might find -nosound -benchmark useful for testing.
Hope this is useful information for you. If you would like a a copy of the 1024x576 clip to run any tests yourself, there's probably some way we can figure out to make it available. Its 14M. (Smaller than some M$ turd documents I've sent via e-mail :-P)
I used -vf expand for testing - this should be even better as it puts additional load mostly onto the vo modules
Greetings, Reimar Döffinger
_______________________________________________ Mplayer-advusers mailing list Mplayer-advusers@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-advusers
Hi,
glxinfo: glx version 1.2 OpenGL version 1.3 Mesa 5.0.2 glu verion 1.3
Are you sure you have hardware acclerated OpenGL? Mesa usually means you are using a software-only implemetation (and I'm not sure if there actually is true OpenGL support for your graphics cards).
This has been a good thought exerciser for me. I just remembered that I have been purposely excluding scaling from my tests so as to narrow the variables. I just re-ran several of the same tests, scaling to fullscreen. When I do this, x11 gets dramatically slower, while XV stays about the same.
So, I think what I'm seeing could be one of 2 subtly different things.
Could you please give the output of xvinfo?
2. Mplayer does color conversion about 4 times faster than XV.
If xv does it in software (which would probably be without SSE support), certainly. Have you tried any of the vidix vos (especially the ATI card might be supported)? They work only as root.
In either case, XV scales images essentially infinitely fast.
I don't see any options that would allow me to force color conversion in software by mplayer and still use XV for scaling output.
-vf format=BGR24 for example, but you should compare against e.g. -vf format=YV12, as when specifying like this, postprocessing isn't done (thus making it faster). Greetings, Reimar Döffinger
On Sat, 2004-04-03 at 01:36, Reimar Döffinger wrote:
Hi,
glxinfo: glx version 1.2 OpenGL version 1.3 Mesa 5.0.2 glu verion 1.3
Are you sure you have hardware acclerated OpenGL? Mesa usually means you are using a software-only implemetation (and I'm not sure if there actually is true OpenGL support for your graphics cards).
XFree86 integrates the direct rendering interface (DRI) with Mesa to provide hardware accelerated OpenGL. My graphics card is recognized by DRI. From: http://www.xfree86.org/4.1.0/DRI8.html <quote> glxinfo is a useful program for checking which version of libGL you're using as well as which DRI-based driver. Simply type glxinfo and examine the OpenGL vendor, renderer, and version lines. Among the output you should see something like this: OpenGL vendor string: VA Linux Systems, Inc. OpenGL renderer string: Mesa DRI Voodoo3 20000224 OpenGL version string: 1.2 Mesa 3.4 or this: OpenGL vendor string: VA Linux Systems, Inc. OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.2 Mesa 3.4 The first example indicates that the 3dfx driver is using Voodoo3 hardware. The second example indicates that no hardware driver was found and indirect, unaccelerated rendering is being used. <end quote> For me, glxinfo reports: OpenGL renderer string: Mesa DRI R200 20030328 AGP 4x x86/MMX+/SSE2 TCL That pretty much confirms it.
This has been a good thought exerciser for me. I just remembered that I have been purposely excluding scaling from my tests so as to narrow the variables. I just re-ran several of the same tests, scaling to fullscreen. When I do this, x11 gets dramatically slower, while XV stays about the same.
So, I think what I'm seeing could be one of 2 subtly different things.
Could you please give the output of xvinfo?
Here you go: X-Video Extension version 2.2 screen #0 Adaptor #0: "ATI Radeon Video Overlay" number of ports: 1 port base: 69 operations supported: PutImage supported visuals: depth 16, visualID 0x23 depth 16, visualID 0x24 depth 16, visualID 0x25 depth 16, visualID 0x26 depth 16, visualID 0x27 depth 16, visualID 0x28 depth 16, visualID 0x29 depth 16, visualID 0x2a depth 16, visualID 0x2b depth 16, visualID 0x2c depth 16, visualID 0x2d depth 16, visualID 0x2e depth 16, visualID 0x2f depth 16, visualID 0x30 depth 16, visualID 0x31 depth 16, visualID 0x32 number of attributes: 12 "XV_SET_DEFAULTS" (range 0 to 1) client settable attribute "XV_AUTOPAINT_COLORKEY" (range 0 to 1) client settable attribute client gettable attribute (current value is 1) "XV_COLORKEY" (range 0 to -1) client settable attribute client gettable attribute (current value is 30) "XV_DOUBLE_BUFFER" (range 0 to 1) client settable attribute client gettable attribute (current value is 1) "XV_BRIGHTNESS" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_CONTRAST" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_SATURATION" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_COLOR" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_HUE" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_RED_INTENSITY" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_GREEN_INTENSITY" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_BLUE_INTENSITY" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) maximum XvImage size: 2048 x 2048 Number of image formats: 4 id: 0x32595559 (YUY2) guid: 59555932-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x59565955 (UYVY) guid: 55595659-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x30323449 (I420) guid: 49343230-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar)
2. Mplayer does color conversion about 4 times faster than XV.
If xv does it in software (which would probably be without SSE support), certainly. Have you tried any of the vidix vos (especially the ATI card might be supported)? They work only as root.
vidix wasn't working because I forgot to ldconfig /usr/local/lib. It works now and vidix performs better than XV. Using my HD test file (45 second clip, 1280x720 progressive 60fps) I get the following: $mplayer -vo x11 -nosound -quiet -benchmark Alias.1280.60fps.avi BENCHMARKs: VC: 24.444s VO: 10.598s A: 0.000s Sys: 0.321s = 35.363s BENCHMARK%: VC: 69.1227% VO: 29.9702% A: 0.0000% Sys: 0.9071% = 100.0000% $mplayer -vo xvidix -nosound -quiet -benchmark Alias.1280.60fps.avi BENCHMARKs: VC: 37.587s VO: 0.069s A: 0.000s Sys: 0.380s = 38.036s BENCHMARK%: VC: 98.8192% VO: 0.1806% A: 0.0000% Sys: 1.0001% = 100.0000% $mplayer -vo xv -nosound -quiet -benchmark Alias.1280.60fps.avi BENCHMARKs: VC: 18.324s VO: 33.361s A: 0.000s Sys: 0.332s = 52.017s BENCHMARK%: VC: 35.2267% VO: 64.1343% A: 0.0000% Sys: 0.6390% = 100.0000% Reminder: this is on a 1.4Ghz Pentium-M laptop with ATI Radeon Mobility 9000 (R200) vintage graphics. Running this on a P4 2.6Ghz should shave about 8 seconds off the times for x11 and vidix. 12 seconds off XV. Note that I'm not scaling anything here. X11 is still marginally fastest. Vidix lags just a little and XV sucks wind. When I add scaling, x11 gets dramatically slower and the other 2 remain essentially the same. I don't like the idea of running my media player as root. But if thats what it takes to play a live HD stream... What bugs me is that I've always been under the impression that color space conversion and scaling were done in hardware by the XV driver. So I was expecting to see XV cpu usage well below x11 cpu usage. I guess I'm going to have to look at the code to find out whats really going on. I wonder how the proprietary nvidia driver compares.
In either case, XV scales images essentially infinitely fast.
I don't see any options that would allow me to force color conversion in software by mplayer and still use XV for scaling output.
-vf format=BGR24 for example, but you should compare against e.g. -vf format=YV12, as when specifying like this, postprocessing isn't done (thus making it faster).
After doing a little more reading, XV appears to only accept the following color formats: YUY2, UYVY, YV12, and I420. Specifying a format using -vf format=XXXX only slows things down.
Greetings, Reimar Döffinger
_______________________________________________ Mplayer-advusers mailing list Mplayer-advusers@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-advusers
On Mon, Apr 05, 2004 at 04:18:59PM -0700, John Stebbins wrote:
I don't like the idea of running my media player as root. But if thats what it takes to play a live HD stream...
Try dhahelper if you are talking about VIDIX. Diego
Cool. Thanks. On Tue, 2004-04-06 at 12:08, Diego Biurrun wrote:
On Mon, Apr 05, 2004 at 04:18:59PM -0700, John Stebbins wrote:
I don't like the idea of running my media player as root. But if thats what it takes to play a live HD stream...
Try dhahelper if you are talking about VIDIX.
Diego
_______________________________________________ Mplayer-advusers mailing list Mplayer-advusers@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-advusers
Some additional info for anyone following this thread. I got tired of groping in the dark on this, so I horked the X sources, added some uSec timing measurements and profiled whats going on for one of the drivers. I did this on my desktop machine which is a P4 2.6Ghz with intel i830 integrated graphics. The color conversion and scaling is indeed being done completely in hardware as I thought it should be. The problem turns out to be in a busy wait loop in the driver. It appears to be waiting for a vsync (as someone suggested earlier). What I see is that sometimes, the timing between mplayer & the X driver are just right so the busy wait finishes within usecs. Then other times the timing will get completely wrong and the busy wait will spin for as long as 14 msec. This is fairly modal behavior as well. When the timing gets short it tends to stay short for a while, and when it gets long it tends to stay long. The propensity for the code to get into the long wait mode seems to increase when mplayer is "working harder". So high resolutions or high frame rates exaggerates the problem. This busy wait is disastrous for 720p HD because this format runs at 60fps which is 16 ms per frame. When X chews up 14 ms per frame, that leaves just 2 ms for decoding. Ouch! I don't know yet if the radeon driver has exactly the same problem. I'll be diving into that one next. I'm not sure what to do about the busy wait. I don't see an obvious way to synchronize closely to vsync without waiting. Any ideas anyone? John
I'm not sure what to do about the busy wait. I don't see an obvious way to synchronize closely to vsync without waiting. Any ideas anyone?
This sounds like more of an interface problem than anything else. I don't know how XVideo works, but the sensible way would be to allow the caller to specify when to wait (e.g. when it's finished decoding the next frame); it sounds like either there is no such call, or MPlayer isn't using it. If the former, I guess you're stuck; if the latter, I'll leave the details to people less busy than me. ;) --Andrew Church achurch@achurch.org http://achurch.org/
Hi,
The color conversion and scaling is indeed being done completely in hardware as I thought it should be. The problem turns out to be in a busy wait loop in the driver. It appears to be waiting
I know nVidia had the same problem with their OpenGL drivers once, but improved it. No idea how they did it though... try if you can disable VSync ;-) Greetings, Reimar Döffinger
On Fri, Apr 09, 2004 at 05:37:46PM -0700, John Stebbins wrote:
Some additional info for anyone following this thread.
I got tired of groping in the dark on this, so I horked the X sources, added some uSec timing measurements and profiled whats going on for one of the drivers. I did this on my desktop machine which is a P4 2.6Ghz with intel i830 integrated graphics.
The color conversion and scaling is indeed being done completely in hardware as I thought it should be. The problem turns out to be in a busy wait loop in the driver. It appears to be waiting for a vsync (as someone suggested earlier). What I see is that sometimes, the timing between mplayer & the X driver are just right so the busy wait finishes within usecs. Then other times the timing will get completely wrong and the busy wait will spin for as long as 14 msec. This is fairly modal behavior as well. When the timing gets short it tends to stay short for a while, and when it gets long it tends to stay long. The propensity for the code to get into the long wait mode seems to increase when mplayer is "working harder". So high resolutions or high frame rates exaggerates the problem.
This busy wait is disastrous for 720p HD because this format runs at 60fps which is 16 ms per frame. When X chews up 14 ms per frame, that leaves just 2 ms for decoding. Ouch!
I don't know yet if the radeon driver has exactly the same problem. I'll be diving into that one next.
I'm not sure what to do about the busy wait. I don't see an obvious way to synchronize closely to vsync without waiting. Any ideas anyone?
Proper hardware should never require a busy loop; it just has a "switch buffers at next vblank" command you send to the card. Are you sure you're using the real backend scaler and not a stupid blitter-based xv port? Rich
A reply to Richard, and some additional timing analysis. First the analysis. I ran the same tests again, but this time on the radeon driver. It turns out its bugs are completely different than the i830 bugs. I can find no indication that the radeon driver waits for vsync as the i830 driver does. What I have found instead is that the bandwidth to the frame buffer being used for XV seems to be 5 times slower when using the radeon. With the i830, I get around 1.1 GB/s transfer rate. With the radeon, I only get about 210 MB/s transfer rate. On a P4 2.6Ghz, mplayer actually decodes a 1280x720 frame faster than XV can copy the bytes. Note that I took great pains to make sure to minimize other factors that could obscure the results. Both tests are run on the same hardware (except for the addition of the radeon card itself). I made sure that the code path followed in both drivers is as similar as possible. This meant using the YUY2 image format. In both drivers, this results in a simple memcpy call to copy the buffer. I made sure the dimensions of the region being copied are the same and thus the same number of bytes are being copied. There is a bug entered in XFree bugzilla that indicates others are seeing this problem as well. This driver seemed to undergo a drastic performance hit around the time of the XFree 4.3 release. The bug number is 414 if anyone is interested in seeing the history and other peoples efforts to analyze. Also, before I saw this bug, I entered another one (number 1292) documenting what I had seen. I will be adding comments to these bug reports soon. After seeing all this, I took a closer look at the XFree86 log file and noticed the following warning. (WW) RADEON(0): [agp] AGP not available I'm going to do some spelunking in the driver to find out what causes this warning and see if it is related. Reply to Richard below... On Sun, 2004-04-11 at 14:34, D Richard Felker III wrote:
On Fri, Apr 09, 2004 at 05:37:46PM -0700, John Stebbins wrote:
Some additional info for anyone following this thread.
I got tired of groping in the dark on this, so I horked the X sources, added some uSec timing measurements and profiled whats going on for one of the drivers. I did this on my desktop machine which is a P4 2.6Ghz with intel i830 integrated graphics.
The color conversion and scaling is indeed being done completely in hardware as I thought it should be. The problem turns out to be in a busy wait loop in the driver. It appears to be waiting for a vsync (as someone suggested earlier). What I see is that sometimes, the timing between mplayer & the X driver are just right so the busy wait finishes within usecs. Then other times the timing will get completely wrong and the busy wait will spin for as long as 14 msec. This is fairly modal behavior as well. When the timing gets short it tends to stay short for a while, and when it gets long it tends to stay long. The propensity for the code to get into the long wait mode seems to increase when mplayer is "working harder". So high resolutions or high frame rates exaggerates the problem.
This busy wait is disastrous for 720p HD because this format runs at 60fps which is 16 ms per frame. When X chews up 14 ms per frame, that leaves just 2 ms for decoding. Ouch!
I don't know yet if the radeon driver has exactly the same problem. I'll be diving into that one next.
I'm not sure what to do about the busy wait. I don't see an obvious way to synchronize closely to vsync without waiting. Any ideas anyone?
Proper hardware should never require a busy loop; it just has a "switch buffers at next vblank" command you send to the card. Are you sure you're using the real backend scaler and not a stupid blitter-based xv port?
Yes, very sure. I've become far more familiar with the XFree86 XV code than I'd like to be :-P The driver does use a command to the hardware that says "switch buffers at next vblank". But the way the driver was implemented, they are only using one buffer at a time in this code path (though 2 are allocated). Before copying data into the next buffer, they always wait for the previous buffer to become free. They sit in a busy wait loop reading a status register until the previous operation is complete. Then they switch "current" buffers, fill the "current" buffer, issue the command to refresh on vsync and return. I don't know enough about the hardware details to suggest an alternative yet. The problem they seem to be working around is that the status register they are reading to check for completion can only be used to indicate the completion of one buffer at a time. If they allowed both buffers to be in use simultaneously, they would not be able to tell if one or both buffers were complete. If they were to miss one, the status register will never update again and they would be stuck in the loop indefinitely. In fact, the loop actually has a max number of iterations defined just in case this were to happen in some unknown other scenario. Note that this problem only exhibits itself if the frame rate of content is >= the refresh rate of the monitor (or you are running a benchmark that does not meter the output frame rate). In my case, I am working with 720p HD content which is 60fps. There are several reasons why someone may use 60Hz refresh rate. To name a few: LCD, PLASMA, Projector, DVI output, and (in my case) broken XFree driver that uses a BIOS call that is not implemented on all systems to set the refresh rate (fixed in XFree 4.4 I've heard). John
On Mon, Apr 12, 2004 at 10:51:35AM -0700, John Stebbins wrote:
Proper hardware should never require a busy loop; it just has a "switch buffers at next vblank" command you send to the card. Are you sure you're using the real backend scaler and not a stupid blitter-based xv port?
Yes, very sure. I've become far more familiar with the XFree86 XV code than I'd like to be :-P
The driver does use a command to the hardware that says "switch buffers at next vblank". But the way the driver was implemented, they are only using one buffer at a time in this code path (though 2 are allocated). Before copying data into the next buffer, they always wait for the previous buffer to become free. They sit in a busy wait loop reading a status register until the previous operation is complete. Then they switch "current" buffers, fill the "current" buffer, issue the command to refresh on vsync and return.
Ah, this is brain damaged. The only correct way is triple-buffering. Can you fix the driver to triple-buffer so that it doesn't matter? Rich
On Mon, 2004-04-12 at 13:06, D Richard Felker III wrote:
The driver does use a command to the hardware that says "switch buffers at next vblank". But the way the driver was implemented, they are only using one buffer at a time in this code path (though 2 are allocated). Before copying data into the next buffer, they always wait for the previous buffer to become free. They sit in a busy wait loop reading a status register until the previous operation is complete. Then they switch "current" buffers, fill the "current" buffer, issue the command to refresh on vsync and return.
Ah, this is brain damaged. The only correct way is triple-buffering. Can you fix the driver to triple-buffer so that it doesn't matter?
Rich
Could you explain your triple-buffering idea in more detail. I'm afraid I'm not picturing what you have in mind. John
On Mon, Apr 12, 2004 at 04:29:05PM -0700, John Stebbins wrote:
On Mon, 2004-04-12 at 13:06, D Richard Felker III wrote:
The driver does use a command to the hardware that says "switch buffers at next vblank". But the way the driver was implemented, they are only using one buffer at a time in this code path (though 2 are allocated). Before copying data into the next buffer, they always wait for the previous buffer to become free. They sit in a busy wait loop reading a status register until the previous operation is complete. Then they switch "current" buffers, fill the "current" buffer, issue the command to refresh on vsync and return.
Ah, this is brain damaged. The only correct way is triple-buffering. Can you fix the driver to triple-buffer so that it doesn't matter?
Rich
Could you explain your triple-buffering idea in more detail. I'm afraid I'm not picturing what you have in mind.
Cycle between 3 different buffers instead of just 2. Then you don't have to wait for the buffer switch before drawing the next buffer. Rich
On Mon, 2004-04-12 at 22:33, D Richard Felker III wrote:
On Mon, Apr 12, 2004 at 04:29:05PM -0700, John Stebbins wrote:
On Mon, 2004-04-12 at 13:06, D Richard Felker III wrote:
The driver does use a command to the hardware that says "switch buffers at next vblank". But the way the driver was implemented, they are only using one buffer at a time in this code path (though 2 are allocated). Before copying data into the next buffer, they always wait for the previous buffer to become free. They sit in a busy wait loop reading a status register until the previous operation is complete. Then they switch "current" buffers, fill the "current" buffer, issue the command to refresh on vsync and return.
Ah, this is brain damaged. The only correct way is triple-buffering. Can you fix the driver to triple-buffer so that it doesn't matter?
Rich
Could you explain your triple-buffering idea in more detail. I'm afraid I'm not picturing what you have in mind.
Cycle between 3 different buffers instead of just 2. Then you don't have to wait for the buffer switch before drawing the next buffer.
You can't be sure of that. For example, when the -benchmark option of mplayer is used, frames are displayed as fast as they can be decoded. If decoding is fast enough you will get more than 3 display requests per vsync. John
On Tue, Apr 13, 2004 at 09:14:09AM -0700, John Stebbins wrote:
On Mon, 2004-04-12 at 22:33, D Richard Felker III wrote:
On Mon, Apr 12, 2004 at 04:29:05PM -0700, John Stebbins wrote:
On Mon, 2004-04-12 at 13:06, D Richard Felker III wrote:
The driver does use a command to the hardware that says "switch buffers at next vblank". But the way the driver was implemented, they are only using one buffer at a time in this code path (though 2 are allocated). Before copying data into the next buffer, they always wait for the previous buffer to become free. They sit in a busy wait loop reading a status register until the previous operation is complete. Then they switch "current" buffers, fill the "current" buffer, issue the command to refresh on vsync and return.
Ah, this is brain damaged. The only correct way is triple-buffering. Can you fix the driver to triple-buffer so that it doesn't matter?
Rich
Could you explain your triple-buffering idea in more detail. I'm afraid I'm not picturing what you have in mind.
Cycle between 3 different buffers instead of just 2. Then you don't have to wait for the buffer switch before drawing the next buffer.
You can't be sure of that. For example, when the -benchmark option of mplayer is used, frames are displayed as fast as they can be decoded. If decoding is fast enough you will get more than 3 display requests per vsync.
Yes, but that's stupid/irrelevant. As long as you're playing movies correctly, no special trickery is needed with triple buffering. Rich
An update for anyone following this thread. I dug into the source for the i830 driver and made changes to fix the problems I was experiencing. First, this driver would not support an XV image with HD resolutions. I had to change a #define to allow a larger number of cachelines. I also had to use VideoRam and CacheLines options in XF86Config to increase these values. I increased VideoRam to 64MB and CacheLines to 1440 (to allow for 2 720p buffers). Next, I attacked the performance issue. I eliminated the busy wait in PutImage. I modified the commands to the overlay engine so that it doesn't wait for flip completions either. This was needed to prevent the command ring from filling and eventually triggering another type of busy wait. I didn't need to resort to triple buffering. There is no image tearing as long as the content frame rate is < twice the monitor refresh rate. Using the benchmark option of mplayer, I can now play a 45 sec 720p clip in 19 sec. This is on a P4 2.6 Ghz machine. I also tested my changes using xvtest. xvtest achieves a smidgen over 7000 fps with my changes. Its interesting to note that xvtest only reaches 1600 fps when I'm using my radeon card due to the bandwidth limitation that I talked about in a previous e-mail. As I said before, if anyone has any insight (or even a wild ass guess) into this bandwidth limitation issue, please speak up. John
participants (5)
-
achurch＠achurch.org -
D Richard Felker III -
Diego Biurrun -
John Stebbins -
Reimar Döffinger