Bug 16845 - Radeon 9200 PRO (RV280) with EXA acceleration displays random colour patterns for Xv overlays
Summary: Radeon 9200 PRO (RV280) with EXA acceleration displays random colour patterns...
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-25 02:02 UTC by Tom Hughes
Modified: 2008-08-31 16:44 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Attachments
Photo of corrupt display (124.22 KB, image/jpeg)
2008-07-25 02:02 UTC, Tom Hughes 		no flags Details
Photo of corrupt display (93.31 KB, image/jpeg)
2008-07-25 02:03 UTC, Tom Hughes 		no flags Details
xorg.conf configuration file (2.13 KB, text/plain)
2008-07-25 06:46 UTC, Tom Hughes 		no flags Details
Xorg log file (46.85 KB, text/plain)
2008-07-25 06:52 UTC, Tom Hughes 		no flags Details
updated xorg.conf configuration file with cruft removed (614 bytes, text/plain)
2008-07-25 10:44 UTC, Tom Hughes 		no flags Details
updated Xorg log file (74.29 KB, text/plain)
2008-07-25 10:45 UTC, Tom Hughes 		no flags Details
check offset fix (1.67 KB, patch)
2008-08-06 13:17 UTC, Alex Deucher 		no flags Details | Splinter Review
Possible fix (2.08 KB, patch)
2008-08-07 02:47 UTC, Michel Dänzer 		no flags Details | Splinter Review
Possible fix, take 2 (2.19 KB, patch)
2008-08-08 03:42 UTC, Michel Dänzer 		no flags Details | Splinter Review
Show Obsolete (3) View All

Description Tom Hughes 2008-07-25 02:02:58 UTC 
Created attachment 17879 [details]
Photo of corrupt display

I have a Radeon 9200 PRO card (RV280 based) and used with EXA acceleration it fails to display video using Xv. This has been observed both with MythTV and with mplayer (using "-vo xv" as the output driver). The card is:

01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01)

I have tried both the Fedora 8 build of version 6.8.0 of the radeon driver and a build of version 6.9.0 from the source and both give the same results.

Using XAA acceleration makes Xv works but unfortunately MythTV's menus are very slow when using XAA acceleration which is why I would like to get EXA acceleration working.

I have attached a couple of photos of the random colour pattern that appears in place of the video - one of the whole screen and one close up of a corner of the screen.
Comment 1 Tom Hughes 2008-07-25 02:03:27 UTC 
Created attachment 17880 [details]
Photo of corrupt display
Comment 2 Alex Deucher 2008-07-25 06:32:32 UTC 
please attach your xorg log and config.
Comment 3 Tom Hughes 2008-07-25 06:46:54 UTC 
Created attachment 17891 [details]
xorg.conf configuration file
Comment 4 Tom Hughes 2008-07-25 06:52:51 UTC 
Created attachment 17893 [details]
Xorg log file

This log covers X startup and an attempt to play video with mplayer (though I don't believe that produced any extra messages).
Comment 5 Tom Hughes 2008-07-25 10:44:14 UTC 
Created attachment 17894 [details]
updated xorg.conf configuration file with cruft removed
Comment 6 Tom Hughes 2008-07-25 10:45:54 UTC 
Created attachment 17895 [details]
updated Xorg log file 

Updated log file - the previous one was done without the TV turned on so didn't have the monitor being detected properly.
Comment 7 Alex Deucher 2008-07-28 08:22:51 UTC 
What should the original image look like?  what format is the src image?

Does this option help:
Option "ColorTiling" "FALSE"
Comment 8 Tom Hughes 2008-07-28 08:44:20 UTC 
Setting ColorTiling to false doesn't appear to help, no.

The image is a TV program - an MPEG-2 stream recorded from a DVB-T card.
Comment 9 Tom Hughes 2008-07-28 09:34:05 UTC 
This is what mplayer says about the format when playing:

Starting playback...
VDec: vo config request - 720 x 576 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [xv] 720x576 => 1024x576 Planar YV12
Comment 10 Tom Hughes 2008-08-04 05:39:12 UTC 
Is there anything more I can do to try and debug this? Any extra debugging I can turn on when compiling the driver perhaps?
Comment 11 Alex Deucher 2008-08-04 07:04:04 UTC 
Does the following option help?
Option "DMAForXv" "FALSE"
Comment 12 Tom Hughes 2008-08-04 08:48:22 UTC 
No, that doesn't make any difference I'm afraid.
Comment 13 Alex Deucher 2008-08-04 08:56:22 UTC 
Does disabling the DRI help?
Option "DRI" "FALSE"
Comment 14 Tom Hughes 2008-08-04 09:08:19 UTC 
No, I'm afraid that doesn't seem to help either.
Comment 15 Alex Deucher 2008-08-04 09:45:45 UTC 
Can you try another video app or video format and see if you get similar behavior?
Comment 16 Tom Hughes 2008-08-05 16:36:54 UTC 
I have now tried totem, xine, mplayer and MythTV and all have the same problem. Pretty much every video I tried uses YV12 as the image format though.

I have also tried using xvtest to display a fixed test pattern, which is YUYV by default, and that fails. I also tried modifying it to use YV12 and a 24 bit RGB format and both of those fails.

You get various different patterns depending on exactly why format you use and what colour pattern you try and display, but it goes wrong with all three formats I have tried.
Comment 17 Michel Dänzer 2008-08-06 02:34:45 UTC 
Does limiting the amount of video RAM with

    VideoRam    131072

(or halving further) work around the problem? Unless I'm missing something, the OV0_VID_BUFx_BASE_ADRS registers only take 27 bits for the offset, and the EXA offscreen memory area starts beyond that for you...
Comment 18 Tom Hughes 2008-08-06 09:02:57 UTC 
Bingo! That fixes it.
Comment 19 Alex Deucher 2008-08-06 13:17:51 UTC 
Created attachment 18164 [details] [review]
check offset fix

The attached patch checks the offset of the allocation and returns BadAlloc if it's beyond the range of the overlay.  This doesn't really help though other than providing an error message.  I suppose the proper fix would be to adjust OV0_BASE_ADDR to start wherever your offscreen mem pool is.  However, you'd then have to subtract out the offset when setting up the overlay.
Comment 20 Michel Dänzer 2008-08-07 02:47:39 UTC 
Created attachment 18171 [details] [review]
Possible fix

How about this one instead? Description inside.
Comment 21 Michel Dänzer 2008-08-07 02:48:54 UTC 
Forgot to mention I've verified it doesn't break the overlay here...
Comment 22 Tom Hughes 2008-08-07 02:50:52 UTC 
I'm just building with that patch now and I'll test it this evening.
Comment 23 Alex Deucher 2008-08-07 07:15:23 UTC 
We should probably wait for the MC to be idle before updating OV0_BASE_ADDR.  I'm not sure how sensitive that register is.
Comment 24 Tom Hughes 2008-08-07 09:11:41 UTC 
That patch almost works - sometimes I get a good picture and sometimes a (variably sized) chunk of the bottom of the picture is covered with flickery vertical lines.

How do I modify the code to wait for MC to be idle before setting that register?
Comment 25 Michel Dänzer 2008-08-08 03:42:33 UTC 
Created attachment 18181 [details] [review]
Possible fix, take 2

Does this patch work better? If not, apparently the base address is changing while playing a video clip, so disabling the overlay or even waiting for MC idle before updating the base address register would probably cause overlay/display blinking, making this approach infeasible. In that case, another possibility would be to statically move the base address as close as possible to the beginning of the EXA offscreen area and to limit its size to 128 MB on cards which have an overlay.
Comment 26 Tom Hughes 2008-08-08 10:54:34 UTC 
That patch seems to work, yes.
Comment 27 Alex Deucher 2008-08-14 12:23:27 UTC 
Fix pushed: a55e85f742d1334bf88e4681e553f025d2de38df
Comment 28 Tormod Volden 2008-08-31 14:31:22 UTC 
The commit has the opposite effect when using XAA: without the commit it works fine, with the commit I see coloured stripes/flashing. This is when watching DVB-T with the "me-tv" program.

You might ask why I use XAA, but I would like to ask why is EXA not default yet?
Comment 29 Michel Dänzer 2008-08-31 14:43:10 UTC 
(In reply to comment #28)
> The commit has the opposite effect when using XAA: without the commit it works
> fine, with the commit I see coloured stripes/flashing.

See bug 17254. Please try the patch attached there.
Comment 30 Tormod Volden 2008-08-31 16:44:54 UTC 
Thanks, the patch in that bug seems to fix it. BTW, I did the testing against 1cf7a5494fa94e8d9f30f9b2905dfbe6d4faa445, before the commit flow a week ago.

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.