Bug 34567

Summary:	xf86-video-ati git and drm-radeon-testing git: CS checker let mplayer / vlc to fail with xv
Product:	Mesa	Reporter:	Jan Buecken <jb.faq>
Component:	Drivers/Gallium/r600	Assignee:	Default DRI bug account <dri-devel>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	medium	CC:	jb.faq, mike
Version:	git
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Jan Buecken 2011-02-22 05:51:49 UTC

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

Comment 1 Jan Buecken 2011-02-22 05:53:57 UTC

The commit 7ac3a2e0bcdadff7c7172a9f833f526b526da16b belongs to the xf86-video-ati git. (To make clear it does not belong to the drm-radeon-testing git branch).

Comment 2 Andy Furniss 2011-02-22 07:35:34 UTC

(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.

Comment 3 Alex Deucher 2011-02-22 08:25:33 UTC

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?

Comment 4 Jan Buecken 2011-02-22 18:33:48 UTC

(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?

Comment 5 Alex Deucher 2011-02-22 18:51:02 UTC

(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.

Comment 6 Alex Deucher 2011-02-22 22:05:12 UTC

Does this commit to the ddx fix the issue?
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=91070cfd75d5607c4a72ace780f830f0ddb40e84

Comment 7 Andy Furniss 2011-02-23 02:28:40 UTC

(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.

Comment 8 Dave Airlie 2011-02-27 20:08:27 UTC

can you test with latest -ati master?

I've got a 1080p video playing here now.

Comment 9 Mike Lothian 2011-02-28 01:55:33 UTC

I quickly tested it before leaving the house this morning. Seems to be working, though it did look jerky

Comment 10 Jan Buecken 2011-02-28 05:30:17 UTC

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.

Comment 11 Andy Furniss 2011-02-28 08:17:35 UTC

(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.