With xf86-video-ati git and Dave Airlieds drm-radeon-testing branch I get a black or no image with some videos using mplayer (using xv and not gl). The cs checker breaks it. I can reproduce this problem with 1080p (not 720p) HD videos. This problem does not appear with the 2.6.37 kernel. This bug was introduced with 7ac3a2e0bcdadff7c7172a9f833f526b526da16b (I bisected this) I did the following: ################################ $mplayer -vo xv 1080pvideo.mp4 MPlayer SVN-r32624-4.4.4 (C) 2000-2010 MPlayer Team Spiele 1080pvideo.mp4. libavformat-Dateiformat erkannt! [lavf] stream 0: video (h264), -vid 0 [lavf] stream 1: audio (aac), -aid 0, -alang und VIDEO: [H264] 1920x1080 24bpp 25.000 fps 3710.3 kbps (452.9 kbyte/s) Clip-Info: major_brand: mp42 minor_version: 0 compatible_brands: isommp42 ========================================================================== Öffne Videodecoder: [ffmpeg] FFmpeg's libavcodec codec family Ausgewählter Videocodec: [ffh264] vfm: ffmpeg (FFmpeg H.264) ========================================================================== ========================================================================== Öffne Audiodecoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 15999->176400) Ausgewählter Audiocodec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio)) ========================================================================== AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) Starte Wiedergabe... Film-Aspekt ist 1.78:1 - Vorskalierung zur Korrektur der Seitenverhältnisse. VO: [xv] 1920x1080 => 1920x1080 Planar YV12 A: 1.9 V: 1.9 A-V: -0.000 ct: 0.000 0/ 0 73% 6% 1.9% 23 0 Beenden... (Ende) ################################ $tail /var/log/kernel/current Feb 22 12:48:02 [kernel] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! Feb 22 12:48:02 [kernel] radeon 0000:01:00.0: texture bo too small (960 540 1 2764800 -> 557056 have 3317760) Feb 22 12:48:02 [kernel] radeon 0000:01:00.0: alignments 1024 256 8 256 Feb 22 12:48:02 [kernel] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! Feb 22 12:48:02 [kernel] radeon 0000:01:00.0: texture bo too small (960 540 1 2764800 -> 557056 have 3317760) Feb 22 12:48:02 [kernel] radeon 0000:01:00.0: alignments 1024 256 8 256 Feb 22 12:48:02 [kernel] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! Feb 22 12:48:02 [kernel] radeon 0000:01:00.0: texture bo too small (960 540 1 2764800 -> 557056 have 3317760) Feb 22 12:48:02 [kernel] radeon 0000:01:00.0: alignments 1024 256 8 256 Feb 22 12:48:02 [kernel] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! ################################ 7ac3a2e0bcdadff7c7172a9f833f526b526da16b is the first bad commit commit 7ac3a2e0bcdadff7c7172a9f833f526b526da16b Author: Alex Deucher <alexdeucher@gmail.com> Date: Thu Feb 10 14:24:50 2011 -0500 6xx+: switch to linear aligned rather than linear general linear aligned is supposedly more performant, but more importantly, linear general only works on the CB without slices. The texture blocks technically don't support linear general although, I think linear general gets upgraded to linear aligned in the hw which is why it currently works. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> :040000 040000 8f830d90157a00f05dc79cd48b4daded8831119a 9fb173e14af75e2a88b2982d0925ab1da2d56671 M src ################################ $git bisect log git bisect start # good: [0a1a0513a61f392580bde39cca4880f2c19abc8d] bump version for release git bisect good 0a1a0513a61f392580bde39cca4880f2c19abc8d # bad: [3d10278ce511f5dabb68ed86ee43eaaf43585983] Xv: fix textured video alignment harder git bisect bad 3d10278ce511f5dabb68ed86ee43eaaf43585983 # good: [be67ded05621aff9c85525372fd119071d3278ec] 6xx/7xx: consolidate spi setup git bisect good be67ded05621aff9c85525372fd119071d3278ec # bad: [39104c6e8461cf49c1bb03a18858ad75a9d98b46] remove EVERGREENSetAccelState() git bisect bad 39104c6e8461cf49c1bb03a18858ad75a9d98b46 # bad: [7ac3a2e0bcdadff7c7172a9f833f526b526da16b] 6xx+: switch to linear aligned rather than linear general git bisect bad 7ac3a2e0bcdadff7c7172a9f833f526b526da16b # good: [e3145801b80fd4be4cf770128876e86e89bda66f] evergreen/NI: consolidate spi setup git bisect good e3145801b80fd4be4cf770128876e86e89bda66f
The commit 7ac3a2e0bcdadff7c7172a9f833f526b526da16b belongs to the xf86-video-ati git. (To make clear it does not belong to the drm-radeon-testing git branch).
(In reply to comment #1) > The commit 7ac3a2e0bcdadff7c7172a9f833f526b526da16b belongs to the > xf86-video-ati git. (To make clear it does not belong to the drm-radeon-testing > git branch). I also see this bug with on my rv790 32bit build. I notice that using d-r-t from January works OK with current git ddx.
Is this still an issue with the latest commits in xf86-video-ati? This is probably be related to the CS block size checking changes in d-r-t (http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=6ee3727feedf15da9c776efca3c65519cf7bb10b). Does 2.6.38-rc6 or drm-fixes work ok?
(In reply to comment #3) > Is this still an issue with the latest commits in xf86-video-ati? Yes. Sorry, my git bisect log is misunderstanding: Ofcourse I tested xf86-video-ati from today, but I began with the bisect at the XV patches (I first thought they are the first failing patches, but after the problem holds without these patches, I began bisecting from the stable release). > This is > probably be related to the CS block size checking changes in d-r-t > (http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=6ee3727feedf15da9c776efca3c65519cf7bb10b). Yes. > Does 2.6.38-rc6 or drm-fixes work ok? I don't test this yet, but is it necessary? Because it is maybe more important that I just reverted (http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=6ee3727feedf15da9c776efca3c65519cf7bb10b) and testet this d-r-t. And this kernel works ok. Thus this is the failing patch at the kernel side. But which patch / branch is wrong in reality?
(In reply to comment #4) > > I don't test this yet, but is it necessary? Because it is maybe more important > that I just reverted > (http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=6ee3727feedf15da9c776efca3c65519cf7bb10b) > and testet this d-r-t. And this kernel works ok. Thus this is the failing patch > at the kernel side. > > But which patch / branch is wrong in reality? The d-r-t branch needs to be fixed up to not reject the linear aligned buffers from the ddx.
Does this commit to the ddx fix the issue? http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=91070cfd75d5607c4a72ace780f830f0ddb40e84
(In reply to comment #6) > Does this commit to the ddx fix the issue? > http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=91070cfd75d5607c4a72ace780f830f0ddb40e84 No.
can you test with latest -ati master? I've got a 1080p video playing here now.
I quickly tested it before leaving the house this morning. Seems to be working, though it did look jerky
Thanks, works with newest xf86-video-ati git (and d-r-t) on my rv630. Cannot confirm that it looks jerky... Greetings Jan Bücken.
(In reply to comment #8) > can you test with latest -ati master? > > I've got a 1080p video playing here now. Fixed for me on rv790. Can't see any jerkyness that isn't also present with old d-r-t + ddx without the fix. AFAIK no linux player will vsync properly so nothing is ever perfect. Generally xv wait for vline is much worse than gl unless full height of the screen is used (and then it will fall apart in the case of fps = refresh unless mplayer -nodouble is used). I've also found that cpufreq on_demand does not play well with mplayer and HD.
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.