Bug 505152 - KMS: Textured video is not always an adequate replacement for overlay
KMS: Textured video is not always an adequate replacement for overlay
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Jérôme Glisse
Fedora Extras Quality Assurance
: FutureFeature, Triaged
: 476418 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-10 15:59 EDT by Martin Decky
Modified: 2014-06-18 05:17 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 476418
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Martin Decky 2009-06-10 15:59:34 EDT
+++ This bug was initially created as a clone of Bug #476418 +++

Description of problem:
If you enable KMS on Radeon RV280 (Radeon 9200 PRO) or similar older Radeon card, video overlay is disabled in X.org. The XVideo functionality is implemented via textured video, but this has more strict limitations on older Radeon hardware than the overlay (the 3D engine is limited by hardware to a resolution of 2048x2048, while the overlay has a higher limit of 4096x4096). This complicates video playback especially in dual-head configurations (if the video output exceeds the 2048x2048 region, just a black box is shown).

The overlay was disabled by this change in radeon-modeset.patch in the source RPM:

diff -up xf86-video-ati-6.12.2/src/radeon_video.c.modeset xf86-video-ati-6.12.2/src/radeon_video.c
--- xf86-video-ati-6.12.2/src/radeon_video.c.modeset    2009-04-07 11:31:32.000000000 -0400
+++ xf86-video-ati-6.12.2/src/radeon_video.c    2009-05-21 11:01:45.000000000 -0400
@@ -284,7 +284,7 @@ void RADEONInitVideo(ScreenPtr pScreen)
     memcpy(newAdaptors, adaptors, num_adaptors * sizeof(XF86VideoAdaptorPtr));
     adaptors = newAdaptors;

-    if (!IS_AVIVO_VARIANT) {
+    if (!IS_AVIVO_VARIANT && !info->drm_mode_setting) {
        overlayAdaptor = RADEONSetupImageVideo(pScreen);
        if (overlayAdaptor != NULL) {
            adaptors[num_adaptors++] = overlayAdaptor;


Version-Release number of selected component (if applicable):
xorg-x11-drv-ati-6.12.2-15.fc11

How reproducible:
Always

Steps to Reproduce:
1. Configure a total display resolution (possibly in dual-head configuration) which exceeds 2048 pixels in any dimension.
2. Play a video using XVideo.
3. Move the video output so that it exceeds the 2048x2048 region in any direction.
  
Actual results:
No output can be visible if you exceed the 2048x2048 region because textured video is used instead of overlay.

Expected results:
The video should be visible at least within the 4096x4096 region using overlay.

Additional info:
I understand that this is a duplicate to #476418, but that was reported agains Fedora 10. The bug is still present in Fedora 11.
Comment 1 Jérôme Glisse 2009-09-14 06:16:58 EDT
I don't think we will implement overlay under KMS as we don't think it brings any real improvement over textured video beside avoiding the size limit. Also i am quite surprise that people use such old hardware to drive new screen with such big resolution when 9200Pro came out i am pretty sure 1280x1024 was among the biggest resolution you could think of, this also reflect in the hw as i am pretty sure that beyond 2048x2048 you are reaching hw bandwidth limit. If one can come up with a clean patch which add overlay support to KMS we might consider adding it.
Comment 2 Martin Decky 2009-09-14 07:34:50 EDT
First let me just say that I simply don't understand this negative attitude. Overlay has been supported by various XFree86/X.org drivers (if the hardware has the capability) since at least the year 2000. It is a working technology for accelerating the color space conversion and scaling of video output. It has many limitations (usually only a single output, hard-wired scaling algorithm, some issues with multiple CRTs), it is not supported by the newest chips anymore, but it also has many advantages such as low overhead and power consumption (you don't have to power up the whole 3D engine just to play video). It simply works for the most common use case.

Now, if KMS is supposed to be the new evolution step in Linux graphics experience, why breaking things which had "always" worked? Is it really right then to call KMS a progress if it is actually prohibits me to do basic things which worked perfectly two years ago (like placing the Xv output on my second display)? I understand that it was not an easy task to design the KMS architecture, cleanup and/or rewrite the Radeon driver code, port it partially to the kernel, etc. I do appreciate that somebody took the time to read the ATI/AMD specs and spent countless hours with debugging and figuring out the hidden catches (everybody who did some low-level programming should know ..).

At the same time I understand that it might have been fun to implement all the cool features like flicker-free transition from the boot screen to the login screen, textured video and so on. But stopping there, cutting off the legacy features and saying that there are not cool, so why bother .. that is, pardon me, just lame. Refactoring a piece of software is not just about implementing the cool new features, but also about implementing the boring stuff to keep the original functionality.

If you don't care about users with older hardware like R2xx, why is it supported by Radeon KMS driver in the first place? Yeah, I can turn KMS off for now and have overlay again. But sooner or later there will no no-KMS mode anymore (I suppose that maintaining two similar code fragments, one in kernel and the other one in user space, is not the right way to go).

To the note about old hardware and big resolutions: Well, my 9250 drives both of my 1920x1080 displays without any problems. The performance might be not breathtaking, but it's OK for most of my daily tasks. And similarly to many Linux users I tend to prefer a slightly older hardware which is well supported than some bleeding edge gadgets which might not work properly or at all except you are commited to code the drivers yourself :) This heuristics for choosing hardware worked for many years, until some people stated to do rewrites, but cutting off support for legacy features.

Or is Fedora trying to be that kind of distro which says "Without the newest CPU, GPU, 16 gigs of RAM and 2 TB of disk space you are a looser"?

Sorry for this non-technical post with a lot of rhetorical questions, but I felt the need to state my deeper motivations for opening this bug.

Just a single argument for having overlay support in the Radeon KMS driver:
[6/6,drm/i915] implement drmmode overlay support v2
http://patchwork.kernel.org/patch/44833/
Comment 3 Jérôme Glisse 2009-09-14 09:50:43 EDT
First reason we can't spend hugue amount of time on old hw while we don't have working driver for newer hw thus we have to make choice on what we want to support so yes r1xx, r2xx is not platinium with KMS but most of the feature will be there in fact overlay is the only one missing (from the top of my head).

Second reason overlay are more complex to program than what it might seems, you have to recompute display watermark and adjust clock which are both painfull and error prone due to various hw bugs or limitations, this is one of the reasons we didn't implemented it in the first time.

Last KMS is designed with newer hw in mind rather than older one and that leads to some design choice which makes some old thing hard to achieve. Overlay is one of those things that newer hw doesn't have or doesn't use anymore (meaning that even the closed source driver doesn't use it so it's untested and might not work and is likely going to disappear if not already has).

That being said we are open to patch, just don't expect me or other radeon guys to work on that as a top priority maybe in one year when we got new hw 3d working with all the features we will consider doing this.

Note that my main desktop use a r100 GPU with 128VRAM and just 512M ram and i like to have thing running smoothly on it so i don't think one can say that we target top high end hw, i am sure many others people than me try to make linux more efficient even on old hw and i believe KMS could help there too.

Sorry about overlay, i just wanted to comment on the bug so you didn't get your hope too high into expecting that it will be fixed soon (of course if some one is working on that it could be fixed soon). Good luck with your desktop.
Comment 4 Martin Decky 2009-09-14 10:23:24 EDT
Thanks for the information, I can certainly understand that a day has no more than 24 hours :) I just hope that somebody competent is able to look into it some day and preferably sooner than by the time when the hardware is really obsolete .. That's why we should keep this bug open.

A note about sending patches: I have already tried to look on the driver code, but, you know, patching something like this is really a guru's work. It is not only about the hardware specs (which are complex, but available) and a deep knowledge of many related components such as the internals of X.org and DRM (which is probably not so well documented). It is also about patching something which is constantly in development and, let's face it, the gurus don't usually take the time to document the status quo or even write don't future plans in much detail. Or is there any detailed white paper about the current architecture and implementation of DRM/KMS? Is there a paper describing where we want to be in a year, in two years, in five years?
Comment 5 Jérôme Glisse 2009-09-14 11:53:46 EDT
Well it looks and sounds more complicated than it really is, i think for overlay the biggest issue is the API and by quick glimpse at intel patch i think there API could apply to radeon as well. Once you got an api you can hack support without bothering about clock stuff (thus don't try with big resolution) just to make sure basic is working, once that works then you can pay attention to clock side of the overlay and then you get a patch. For the userspace side of it there is also a patch to the intel ddx that should layout the basis of what change should happen in the radeon ddx.

Sorry about documentation it's in a bad state but given the major change we are undergoing writing documentation was the least of our concern. Sadly i think it's often the case with complex stuff.

And there is no white paper beside various presentation i suggest you look at X presentation at XDC,XDS,LCA,Fosdem events this is likely where you will find high level view of things. For the future i think it's basicly having kms and memory management in the kernel also maybe gpu context stuff and everythings else in the userspace in only one place like gallium driver (at least i wish to have only one place to hack and fix bugs in userspace :)).
Comment 6 Matěj Cepl 2009-09-14 18:44:17 EDT
*** Bug 476418 has been marked as a duplicate of this bug. ***
Comment 7 Matěj Cepl 2009-09-14 18:45:34 EDT
This is quite certainly way over bug triaging, assigning to the devleoper.
Comment 8 Matěj Cepl 2009-09-14 18:50:29 EDT
(In reply to comment #4)
> It is also about patching something
> which is constantly in development and, let's face it, the gurus don't usually
> take the time to document the status quo or even write don't future plans in
> much detail.

I think the best mode of catching up with the current development and future plans is to follow xorg-devel@lists.x.org. That could be also the best place to put the patch for review and getting into the current stream of development.
Comment 9 Matěj Cepl 2009-11-05 12:13:15 EST
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages (at least F12Beta, but even better if the very latest versions).

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
Comment 10 Bug Zapper 2009-11-16 05:03:18 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 Martin Decky 2009-11-18 11:26:31 EST
(In reply to comment #9)

This is a "long-term" bug. It describes a lack of a functionality in the KMS infrastructure which is not essential, but it was present in the pre-KMS world and would be nice to have in the KMS world, too.

Therefore I suggest to keep this bug open to track any progress in this matter.
Comment 12 Dave Airlie 2009-11-19 19:07:59 EST
btw I've done some fixes for KMS textured video that might help for displays > 2048 upstream, r100+r200 has a bug where the video could be restricted without good reason.

They don't solve the playing a movie > 2048x2048, they should solve the playing a movie < 2048 on the left hand side of a desktop that is > 2048. or on the right hand side if running xcompmgr.
Comment 13 Martin Decky 2009-12-13 08:00:17 EST
(In reply to comment #12)

> They don't solve the playing a movie > 2048x2048, they should solve the playing
> a movie < 2048 on the left hand side of a desktop that is > 2048. or on the
> right hand side if running xcompmgr.  

Does that mean that there is a way how you can force the hardware to consider the clipping region not 2048x2048+0+0, but say 2048x2048+2048+0? And change the offset dynamically as needed? This would definitively be a reasonable solution. I don't want to play a single video larger than 2048x2048, nor do I want to play more videos simultaneously with a combined bounding region larger than 2048x2048. I just want to be able to put top-left corner of the video output beyond 2048 pixels horizontally and that's it.

Are the fixes you are referring to in comment #12 already present in xorg-x11-drv-ati-6.13.0-0.15.20091127gita8dbf7c23.fc12.i686? Because I don't observe any improvements with this version. Or do I need some specific versions of other packages as well?
Comment 14 Adam Williamson 2010-02-10 16:07:29 EST

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 15 Miroslav Lichvar 2010-07-28 15:32:17 EDT
I don't need to use resolutions higher that the limit reported here, but I'm having problems with tearing in the textured video output. The tear goes from lower left corner to upper right corner, it doesn't look like disabled vsync. With nomodeset videos play fine.

The card is identified as 1002:5960:174b:0260 ATI Technologies Inc RV280 [Radeon 9200 PRO] rev 1.

xorg-x11-drv-ati-6.13.0-1.fc13.x86_64
kernel-2.6.33.6-147.fc13.x86_64

Please let me know if you need more info.
Comment 16 Florian Fahr 2010-07-28 17:52:54 EDT
Same here.

01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]
Comment 17 pumba88 2011-03-01 01:43:01 EST
Same here. Higher video resolution and bitrate = more tearing.  2.6.38-rc4, xserver 1.9 and xserver-xorg-video-ati 6.14.0. With UMS and Overlay video playback is perfect, a 1280x720p 5000kbps mkv is unwatchable because it tears like hell. 

"xvinfo:

"X-Video Extension version 2.2
screen #0
  Adaptor #0: "Radeon Textured Video"
    number of ports: 16
    port base: 63
    operations supported: PutImage 
    supported visuals:
      depth 24, visualID 0x21
    number of attributes: 9
      "XV_BICUBIC" (range 0 to 2)
              client settable attribute
              client gettable attribute (current value is 0)
      "XV_VSYNC" (range 0 to 1)
              client settable attribute
              client gettable attribute (current value is 1)"

Xorg.0.log:

"[    16.486] (--) RADEON(0): Chipset: "ATI Radeon XPRESS 200M 5A62 (PCIE)"
(ChipID = 0x5a62)
[    16.487] (II) RADEON(0): KMS Color Tiling: enabled
[    16.487] (II) RADEON(0): KMS Pageflipping: enabled
[    16.487] (II) RADEON(0): SwapBuffers wait for vsync: enabled"

dmesg:

[    7.936293] [drm] radeon defaulting to kernel modesetting.
[    7.936299] [drm] radeon kernel modesetting enabled.
[    7.936458] radeon 0000:01:05.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[    7.939726] [drm] initializing kernel modesetting (RS400 0x1002:0x5A62).
[    7.939790] [drm] register mmio base: 0xC0000000
[    7.939793] [drm] register mmio size: 65536
[    7.940143] [drm] Generation 2 PCI interface, using max accessible memory
[    7.940154] radeon 0000:01:05.0: VRAM: 128M 0x0000000058000000 -
0x000000005FFFFFFF (128M used)
[    7.940159] radeon 0000:01:05.0: GTT: 512M 0x0000000060000000 -
0x000000007FFFFFFF
[    7.940177] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[    7.940180] [drm] Driver supports precise vblank timestamp query.
[    7.940255] [drm] radeon: irq initialized.
[    7.942623] [drm] Detected VRAM RAM=128M, BAR=256M
[    7.942629] [drm] RAM width 128bits DDR
[    7.942763] [TTM] Zone  kernel: Available graphics memory: 440494 kiB.
[    7.942766] [TTM] Zone highmem: Available graphics memory: 705970 kiB.
[    7.942769] [TTM] Initializing pool allocator.
[    7.942805] [drm] radeon: 128M of VRAM memory ready
[    7.942808] [drm] radeon: 512M of GTT memory ready.
[    7.942841] [drm] GART: num cpu pages 131072, num gpu pages 131072
[    7.969009] [drm] radeon: 1 quad pipes, 1 z pipes initialized."
Comment 18 pumba88 2011-03-01 01:44:38 EST
Correction: With UMS and Overlay video
playback is perfect. A 1280x720p 5000kbps mkv is unwatchable with KMS and Textured Video because it tears like hell.
Comment 19 pumba88 2011-03-16 05:38:20 EDT
No tearing with 2.6.38 final and VLC Player.

Note You need to log in before you can comment on or make changes to this bug.