[Bug 34567] New: xf86-video-ati git and drm-radeon-testing git: CS checker leads mplayer / vlc to fail with xv
https://bugs.freedesktop.org/show_bug.cgi?id=34567
Summary: xf86-video-ati git and drm-radeon-testing git: CS checker leads mplayer / vlc to fail with xv Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: jb.faq@gmx.de
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
https://bugs.freedesktop.org/show_bug.cgi?id=34567
--- Comment #1 from Jan Buecken jb.faq@gmx.de 2011-02-22 05:53:57 PST --- The commit 7ac3a2e0bcdadff7c7172a9f833f526b526da16b belongs to the xf86-video-ati git. (To make clear it does not belong to the drm-radeon-testing git branch).
https://bugs.freedesktop.org/show_bug.cgi?id=34567
Jan Buecken jb.faq@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|xf86-video-ati git and |xf86-video-ati git and |drm-radeon-testing git: CS |drm-radeon-testing git: CS |checker leads mplayer / vlc |checker let mplayer / vlc |to fail with xv |to fail with xv
https://bugs.freedesktop.org/show_bug.cgi?id=34567
--- Comment #2 from Andy Furniss lists@andyfurniss.entadsl.com 2011-02-22 07:35:34 PST --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=34567
--- Comment #3 from Alex Deucher agd5f@yahoo.com 2011-02-22 08:25:33 PST --- 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...). Does 2.6.38-rc6 or drm-fixes work ok?
https://bugs.freedesktop.org/show_bug.cgi?id=34567
--- Comment #4 from Jan Buecken jb.faq@gmx.de 2011-02-22 18:33:48 PST --- (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...).
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...) 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?
https://bugs.freedesktop.org/show_bug.cgi?id=34567
--- Comment #5 from Alex Deucher agd5f@yahoo.com 2011-02-22 18:51:02 PST --- (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...) 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.
https://bugs.freedesktop.org/show_bug.cgi?id=34567
--- Comment #6 from Alex Deucher agd5f@yahoo.com 2011-02-22 22:05:12 PST --- Does this commit to the ddx fix the issue? http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=91070cfd75...
https://bugs.freedesktop.org/show_bug.cgi?id=34567
--- Comment #7 from Andy Furniss lists@andyfurniss.entadsl.com 2011-02-23 02:28:40 PST --- (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=91070cfd75...
No.
https://bugs.freedesktop.org/show_bug.cgi?id=34567
--- Comment #8 from Dave Airlie airlied@freedesktop.org 2011-02-27 20:08:27 PST --- can you test with latest -ati master?
I've got a 1080p video playing here now.
https://bugs.freedesktop.org/show_bug.cgi?id=34567
--- Comment #9 from Michael Lothian mike@fireburn.co.uk 2011-02-28 01:55:33 PST --- I quickly tested it before leaving the house this morning. Seems to be working, though it did look jerky
https://bugs.freedesktop.org/show_bug.cgi?id=34567
Jan Buecken jb.faq@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #10 from Jan Buecken jb.faq@gmx.de 2011-02-28 05:30:17 PST --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=34567
--- Comment #11 from Andy Furniss lists@andyfurniss.entadsl.com 2011-02-28 08:17:35 PST --- (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.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org