Created attachment 71434 [details] screenshot showing the problem We are using xvideo to display video on an AMD T40E cpu with a radeon HD 6250 GPU builtin. When we display one XVideo window fullscreen, no problem everything shows fine. However when we try to show a second smaller xvideo window above the first window (picture in picture), we can see that the horizontal region in the first window where the second window is located, is shifted a couple of pixels. This creates a tearing like effect, but it is not tearing. The moment you hide the PIP window the effect is gone. The amount of shifting seems to vary, the further away from the PIP window, the less it gets. See the attached picture where the effect is highlighted by a rectangle. Note that the PIP does not have to be using xvideo, we also get the effect when just showing some basic X application above the xvideo window. We also use other hardware with an intel GPU and CPU, and it does not experience from this problem. So our own display software doesn't seem to be the culprit. There is nothing fancy or experimental we do to display the video, just using shared memory and XvShmPutImage. That is why I'm thinking it is radeon driver issue. The software running on the hardware is debian wheezy with xorg version 7.7, the radeon driver version 6.14.4 and a 3.2.33 linux kernel. XVideo is using a textured video port. This is the output of 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: 7 "XV_VSYNC" (range 0 to 1) client settable attribute client gettable attribute (current value is 1) "XV_BRIGHTNESS" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_CONTRAST" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_SATURATION" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_HUE" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_COLORSPACE" (range 0 to 1) client settable attribute client gettable attribute (current value is 0) "XV_CRTC" (range -1 to 5) client settable attribute client gettable attribute (current value is -1) maximum XvImage size: 16384 x 16384 Number of image formats: 4 id: 0x32595559 (YUY2) guid: 59555932-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x30323449 (I420) guid: 49343230-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x59565955 (UYVY) guid: 55595659-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) Doing some googling, I found this redhat bugreport, which describes the same problem: https://bugzilla.redhat.com/show_bug.cgi?id=583382
Looks like the texture coordinates are calculated inconsistently between different cliprect sizes. Can you capture a direct screenshot of the problem?
Created attachment 71441 [details] Direct screenshot Here is a direct screenshot from X
This might be fixed with xf86-video-ati Git commit 37786e9027b8c8d1f9ec9928915784dd28853766 ('radeon: avoid rounding errors in texture coords for textured xv on EG+').
OK, I will see if that commit fixes it
The problem is gone when I try 37786e9027b8c8d1f9ec9928915784dd28853766, so we will have to backport that fix. Big thanks for the help.
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.