| Summary: | Full screen video playback choppy after git commit 78e7047c | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | AttilaN <attila123456> | ||||||||
| Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> | ||||||||
| Status: | RESOLVED INVALID | QA Contact: | Xorg Project Team <xorg-team> | ||||||||
| Severity: | normal | ||||||||||
| Priority: | medium | CC: | mgorny, suokkos | ||||||||
| Version: | 7.5 (2009.10) | ||||||||||
| Hardware: | x86 (IA32) | ||||||||||
| OS: | Linux (All) | ||||||||||
| Whiteboard: | |||||||||||
| i915 platform: | i915 features: | ||||||||||
| Attachments: |
|
||||||||||
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. 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. (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. Created attachment 35672 [details] [review] It works fine with this patch. Created attachment 35710 [details] [review] force specific domains for Xv src data Does this patch help? (In reply to comment #5) > Does this patch help? No effect, unfortunately. Attila, can you verify Pauli's theory from comment #2 by setting the XV_BICUBIC attribute to 0? Does that work around the problem? 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 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 (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. 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 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. (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 #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. 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'... xvattr -a XV_BICUBIC -v 0 (In reply to comment #16) > xvattr -a XV_BICUBIC -v 0 thx. it makes the video problem go away. Same problem with RC410 (Radeon Xpress 200M). Is there any solution planned? 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.
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.