Bug 28114 - Full screen video playback choppy after git commit 78e7047c
Summary: Full screen video playback choppy after git commit 78e7047c
Status: RESOLVED INVALID
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 7.5 (2009.10)
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-14 13:21 UTC by AttilaN
Modified: 2018-06-12 19:07 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
untested idea for problem. (477 bytes, patch)
2010-05-14 23:01 UTC, Pauli
no flags Details | Splinter Review
It works fine with this patch. (721 bytes, patch)
2010-05-15 07:01 UTC, AttilaN
no flags Details | Splinter Review
force specific domains for Xv src data (3.64 KB, patch)
2010-05-17 07:39 UTC, Alex Deucher
no flags Details | Splinter Review

Description AttilaN 2010-05-14 13:21:07 UTC
After upgrading my ubuntu to lucid I noticed that some videos didn't play well on full screen anymore, it's slow and choppy. 720p movies play fine, but a simple 512x336 one doesn't. CPU usage is minimal.

Tried a git bisect on the radeon driver and found that the issue seems to be caused by the above commit ('Allocate Xv buffers to GTT'). Reverting that one on the master branch results in smooth playback.

Dell laptop, mobility X1300 card, Core2Duo CPU. Same on kernels 2.6.32,33 & 34. Problem persists after an update from the xorg-edgers PPA too.
Comment 1 AttilaN 2010-05-14 13:46:07 UTC
Uploaded a short (2MB) sample video that seems to be badly affected by this bug: http://is.gd/c9cUS

Would also mention that Xorg.0.log and dmesg are identical with and without the 78e7047c commit.
Comment 2 Pauli 2010-05-14 23:01:17 UTC
Created attachment 35667 [details] [review]
untested idea for problem.

Thinking about the problem. Maybe problem is some how related to bicubic scaling that is only applied to 2x+ scaling.

Above patch restores bicubic code back to same that it was before the patch.
Comment 3 AttilaN 2010-05-15 01:31:53 UTC
(In reply to comment #2)
> Above patch restores bicubic code back to same that it was before the patch.
Thanks - I tested the patch, it didn't seem to solve the problem, though.
Comment 4 AttilaN 2010-05-15 07:01:41 UTC
Created attachment 35672 [details] [review]
It works fine with this patch.
Comment 5 Alex Deucher 2010-05-17 07:39:19 UTC
Created attachment 35710 [details] [review]
force specific domains for Xv src data

Does this patch help?
Comment 6 AttilaN 2010-05-17 09:06:11 UTC
(In reply to comment #5)
> Does this patch help?

No effect, unfortunately.
Comment 7 Michel Dänzer 2010-05-18 00:27:21 UTC
Attila, can you verify Pauli's theory from comment #2 by setting the XV_BICUBIC attribute to 0? Does that work around the problem?
Comment 8 Pauli 2010-05-18 08:27:25 UTC
On Tue, May 18, 2010 at 10:27 AM,  <bugzilla-daemon@freedesktop.org> wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=28114
>
> --- Comment #7 from Michel Dänzer <michel@daenzer.net> 2010-05-18 00:27:21 PDT ---
> Attila, can you verify Pauli's theory from comment #2 by setting the XV_BICUBIC
> attribute to 0? Does that work around the problem?
>
> --
> Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.

I realy don't know what is real problem because the Attila's patch
that fixes the problem is practicaly moving the XV buffer to VRAM that
should be very slow for everyone. I can later today upload a test
application to see how fast memory access is to VRAM. But I still
don't understand why GPU reading from GTT is very slow for X1300
(laptop card?).

Pauli
Comment 9 Pauli 2010-05-18 08:28:18 UTC
On Tue, May 18, 2010 at 10:27 AM,  <bugzilla-daemon@freedesktop.org> wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=28114
>
> --- Comment #7 from Michel Dänzer <michel@daenzer.net> 2010-05-18 00:27:21 PDT ---
> Attila, can you verify Pauli's theory from comment #2 by setting the XV_BICUBIC
> attribute to 0? Does that work around the problem?
>
> --
> Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.

I realy don't know what is real problem because the Attila's patch
that fixes the problem is practicaly moving the XV buffer to VRAM that
should be very slow for everyone. I can later today upload a test
application to see how fast memory access is to VRAM. But I still
don't understand why GPU reading from GTT is very slow for X1300
(laptop card?).

Pauli
Comment 10 Michel Dänzer 2010-05-18 08:34:04 UTC
(In reply to comment #9)
> I realy don't know what is real problem because the Attila's patch
> that fixes the problem is practicaly moving the XV buffer to VRAM that
> should be very slow for everyone.

Actually it seems rather unusually slow on your system. Even this PowerBook (which doesn't even have write combining) manages more than 100 MB/s for CPU writes to VRAM.

> I can later today upload a test application to see how fast memory access is to
> VRAM. But I still don't understand why GPU reading from GTT is very slow for
> X1300 (laptop card?).

I'm not sure either, but I guess the bicubic filtering could require quite a lot of bandwidth for texture sampling.
Comment 11 AttilaN 2010-05-18 09:29:45 UTC
Any idea why only some videos are affected? 720p HD plays fine, as well as other, smaller ones with various aspect ratios/codecs. does the linked test video play smoothly on your computer?
Comment 12 AttilaN 2010-05-18 09:33:17 UTC
(In reply to comment #11)
> Any idea why only some videos are affected? 720p HD plays fine, as well as
> other, smaller ones with various aspect ratios/codecs. does the linked test
> video play smoothly on your computer?

in fullscreen mode I mean.
Comment 13 Michel Dänzer 2010-05-18 09:41:28 UTC
(In reply to comment #11)
> Any idea why only some videos are affected? 720p HD plays fine, as well as
> other, smaller ones with various aspect ratios/codecs.

At least part of it may be explained by Pauli's theory in comment #2: The default value 2 of XV_BICUBIC means that bicubic filtering is only used if the video is scaled by at least 2x. So 720p probably doesn't use bicubic filtering, but the test video may for you.

> does the linked test video play smoothly on your computer?

It does here.
Comment 14 Pauli 2010-05-18 09:57:36 UTC
> --- Comment #10 from Michel Dänzer <michel@daenzer.net> 2010-05-18 08:34:04 PDT ---
> (In reply to comment #9)
>> I realy don't know what is real problem because the Attila's patch
>> that fixes the problem is practicaly moving the XV buffer to VRAM that
>> should be very slow for everyone.
>
> Actually it seems rather unusually slow on your system. Even this PowerBook
> (which doesn't even have write combining) manages more than 100 MB/s for CPU
> writes to VRAM.
>

Yes. My hw is the lowest that I have seen but I have seen results that
writes to vram even in some r600/r700 cards are slower than 20MB/s.

>> I can later today upload a test application to see how fast memory access is to
>> VRAM. But I still don't understand why GPU reading from GTT is very slow for
>> X1300 (laptop card?).
>
> I'm not sure either, but I guess the bicubic filtering could require quite a
> lot of bandwidth for texture sampling.
>

I guess it might be that bicubic filtering may need to read same
memory area multiple times causing extra bandwidth use. So with
bicubic fragment shader (or similar) actual video should be first
uploaded to VRAM before doing the bicubic scaling.

> --- Comment #11 from AttilaN <attila123456@gmail.com> 2010-05-18 09:29:45 PDT ---
> Any idea why only some videos are affected? 720p HD plays fine, as well as
> other, smaller ones with various aspect ratios/codecs. does the linked test
> video play smoothly on your computer?
>

Yes. It plays smoothly in fullscreen (1024x768). But bicubic filtering
is not implemented for my hw.
Comment 15 AttilaN 2010-05-19 11:08:39 UTC
I took a video that plays well, converted it to half its size, then it produced the same bad symptoms, so I guess it must have something to do with 2x+ scaling. I'm not sure how to set the 'XV_BICUBIC attribute to 0'...
Comment 16 Alex Deucher 2010-05-19 12:13:23 UTC
xvattr -a XV_BICUBIC -v 0
Comment 17 AttilaN 2010-05-19 12:28:20 UTC
(In reply to comment #16)
> xvattr -a XV_BICUBIC -v 0

thx. it makes the video problem go away.
Comment 18 Michał Górny 2010-06-03 00:51:58 UTC
Same problem with RC410 (Radeon Xpress 200M). Is there any solution planned?
Comment 19 Adam Jackson 2018-06-12 19:07:05 UTC
Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.


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.