On Fri, Feb 20, 2009 at 7:10 PM, JP Fournier <jape42@gmail.com> wrote:

Here's the result from my testing:

- current git + this patch : - CPU usage back to normal when playing regular 640x480 mpeg2 xvideo in mythtv (say 5% Xorg CPU usage) - zooming in on the recording in mythtv still results in a runaway Xorg process (100% CPU - even kill -9 did not work (neat))

Since I never ran the zoom test for you in mythtv with the previous debug patch, I figured I'd give it a shot:

(normal video) wait_vline_range: start 0 stop 1079 wait_vline_range: start 0 stop 1079 wait_vline_range: start 0 stop 1079 wait_vline_range: start 0 stop 1079 (zoom in) wait_vline_range: start -90 stop 1169 (WW) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY! (WW) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY! (WW) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY! (WW) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY! (WW) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY! (WW) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY! (WW) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY! (WW) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY! (WW) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY! (WW) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY! (WW) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY! (WW) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY! (WW) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY! (WW) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY! (WW) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY! (WW) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY!

Seems like dmesg logs are getting flooded too:

[ 465.356686] [drm] wait idle failed status : 0xA0003030 0x00000003 [ 465.460908] [drm] wait idle failed status : 0xA0003030 0x00000003 [ 465.565086] [drm] wait idle failed status : 0xA0003030 0x00000003 [ 465.669180] [drm] wait idle failed status : 0xA0003030 0x00000003

Just in case I've applied your patch incorrectly, this is what my wait_vline_range function looks like:

void wait_vline_range(ScrnInfoPtr pScrn, drmBufPtr ib, int crtc, int start, int stop) { RHDPtr rhdPtr = RHDPTR(pScrn);

ErrorF("wait_vline_range: start %d stop %d\n", start, stop);

if ((crtc < 0) || (crtc > 1)) return;

if(!rhdPtr->Crtc[crtc]->Active) return;

start = max(start, 0); stop = min(stop, rhdPtr->Crtc[crtc]->Height);

if (stop <= start) return;

/* set the VLINE range */ if(crtc == 0) ereg(ib, D1MODE_VLINE_START_END, start | (stop << 16)); else ereg(ib, D2MODE_VLINE_START_END, start | (stop << 16));

/* tell the CP to poll the VLINE state register */ pack3 (ib, IT_WAIT_REG_MEM, 6); e32 (ib, WAIT_REG | WAIT_EQ); if(crtc == 0) e32 (ib, D1MODE_VLINE_STATUS >> 2); else e32 (ib, D2MODE_VLINE_STATUS >> 2); e32 (ib, 0); e32 (ib, 0); // Ref value e32 (ib, 0x1000); // Mask e32 (ib, 10); // Wait interval }

regards,

jp

On Friday 20 February 2009 12:16:46 Christian König wrote:

...

Hi,

attached is a patch that should fix the problem with the runaway process. Please do a git reset before applying this patch.

Thanks for testing, Christian.

Similar story here. I recently updated my mplayer, and now the pan/zoom doesn't crash anymore, however, it doesn't zoom evenly on the video; the video is shifted as it zooms so the left edge stays stationary. The excess video goes off the right edge with no problem. Now my X.org.0.log says the following on crashing in Mythtv when zooming: (Xorg.0.log) wait_vline_range: start 0 stop 1023 wait_vline_range: start 0 stop 1023 wait_vline_range: start 0 stop 1023 wait_vline_range: start 0 stop 1108 (WW) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY! (WW) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY! (WW) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY! (message) Feb 20 22:05:16 killbot kernel: [drm] wait idle failed status : 0xA0003030 0x00000003 Feb 20 22:05:19 killbot last message repeated 25 times Feb 20 22:05:19 killbot kernel: [drm] wait idle failed status : 0xA00030B0 0x00000003 Feb 20 22:05:19 killbot kernel: [drm] wait idle failed status : 0xA0003030 0x00000003 Feb 20 22:05:20 killbot last message repeated 15 times Feb 20 22:05:21 killbot kernel: [drm] wait idle failed status : 0xA00030F0 0x00000003 Feb 20 22:05:21 killbot kernel: [drm] wait idle failed status : 0xA0003030 0x00000003 Feb 20 22:05:29 killbot last message repeated 83 times Feb 20 22:05:29 killbot kernel: [drm] wait idle failed status : 0xA00030B0 0x00000003 Feb 20 22:05:29 killbot kernel: [drm] wait idle failed status : 0xA0003030 0x00000003 Feb 20 22:05:32 killbot last message repeated 24 times This is on the machine with the HD 2600. I can test the HD3300 machine also if you would like. I hope this helps, Patrick -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

This worked for me in mythtv. No runaway process while zooming in. CPU usage is light too. Thanks. jp On Saturday 21 February 2009 20:58:26 Christian König wrote:

Hi,

ok second try, the hight stored in the crtc structure was the virtual size of the framebuffer not the vertical display size of the crtc. After adjusting the virtual size to something bigger than the crtc size i could reproduce the problem, the attached patch should fix it.

Just to make it clear: What mplayer/mythtv do here is absolutely braindead. We copy around parts of the picture, scale it and make colour space conversion just to realize in the very end that we don't actually need it, which is something the player could have checked in the first place.

Thanks again for the help, Christian.

-- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

2009/2/22 Christian König <deathsimple@vodafone.de>:

Just to make it clear: What mplayer/mythtv do here is absolutely braindead. We copy around parts of the picture, scale it and make colour space conversion just to realize in the very end that we don't actually need it, which is something the player could have checked in the first place.

Could you report this to MPlayer bugzilla? -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Am Mittwoch, den 25.02.2009, 15:29 +0100 schrieb Matthias Hopf:

On Feb 22, 09 10:31:49 +0100, Rafał Miłecki wrote:

...

2009/2/22 Christian König <deathsimple@vodafone.de>:

...

Just to make it clear: What mplayer/mythtv do here is absolutely braindead. We copy around parts of the picture, scale it and make colour space conversion just to realize in the very end that we don't actually need it, which is something the player could have checked in the first place.

Could you report this to MPlayer bugzilla?

It's not exactly braindead - the current order just fits best into the data flow. For only partially working / filtering / converting an image you would need to backprobagate the coordinates to the previous steps (which is not necessarily linear), and it's a quite academic issue anyway. just to sum up what's happening here (this is just an example how i can reproduce the problem):

1. I revive a DVB-S stream from a German television station. This tv station decides to send the MPEG stream not as 16:9 but as 4:3. I don't know why they do this, most probably because their recording is in 4:3 or some compatibility reasons with their current hardware... Anyway they add black borders to the top and bottom of the picture to make it fit into 4:3. 2. I have a 16:9 television so displaying this 4:3 picture with the black borders just look ugly. So i enable cropping the black borders from the 4:3 picture to get (again) a 16:9 picture. 3. The cropping plugin of my player starts scanning the Y plane of the I frames if there is any brightness in the first and last lines of the picture. 4. The player then tells Xv to scale the picture outside of the scanout are of the crtc so the black borders aren't visible any more. 5. RHD now copies the (whole) picture information from system to video ram and tells the hardware to render the picture information to the framebuffer. 6. Correct me if i'm wrong but AFAIK the video hardware scales the picture and makes colour space conversion, just to realize that we can throw away 25% of the picture because it just contains black borders which are outside of the screen. Sorry for blaming the player to be braindead, it's a little bit over sized, i should have blamed the television station in the first place. :/ And i 100% akk with you that backpropagating if parts of the displaying area are visible is like killing a fly with an atomic bomb, but hey from what i know about MPEG2 i would put an cropping feature between the VLD and iDCT stage, so every stage after this one doesn't even sees the black borders (ok doing MC at the picture border must be quite tricky then). I don't know if what i have in my mind how this is supposed to work is really doable, since i never implemented an mpeg decoder/player myself. I will think about it some more, and take a look into the mplayer/ffmpeg source and make a bug report if its really looks like an possible improvement. Bye, Christian. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org