Created attachment 26959 [details] sample code to see the phenomenon Description: ------------ Using the XV texture adapter in YV12 format. I fill a rectangle with many 1 pixel-high horizontal lines. Odd lines are black and even lines are white. I send this rectangle using XVShmPutImage to a window with the same size so that no scaling occurs. I would expect to see the black/white horizontal lines pattern. But I get a uniformly gray rectangle! Same phenomenon appears on either VGA, DVI or CVBS-TV monitors: it doesn't seem to be monitor/video encoder issue-related. System environment: ------------------ -- chipset: 945G -- system architecture: i686 -- xf86-video-intel/xserver/mesa/libdrm version: 2.7.0/1.6.0/7.4/2.4.7 -- kernel version: 2.6.29.2 -- Linux distribution: homemade -- Machine or mobo model: 945G -- Display connector: VGA (but does not seem to matter) Repro steps: Compile the attached xv_tester.c file with the command gcc xv_tester.c -lXv -lX11 -lXext -o xv_tester Run xv_tester on a XV texture adapter port (use xv_tester -h to see how to change the output window size or specify the Xv port to use) The pattern that was used to create the YV12 image is the attached bitmap. Additional Info: --------------- 1) I also saw that on much older drivers. Maybe it has always been this way. 2) When the output window is one pixel higher(upscaling) or one pixel shorter(downscaling) than the source rectangle, I do see the expected pattern, but with some scaling distortion (as I expected). 3) Opening a bitmap or .jpeg with the same pattern with an image viewer (GIMP), everything is fine. The phenomenon seems to be Xv-specific. 4) With the XV overlay adapter, if the pattern has the same size as the window, I do get all lines but with an unexpected scaling distortion. If the pattern is one pixel higher than the window (downscaling case), I do get the same phenomenon as when the texture adapter is used with no scaling. There seems to be a skew of 1 pixel on the overlay adapter vs. the texture one. 5) [sroland@tungstengraphics.com]) wrote on the xorg mailing list: "Not sure here, but as a wild guess (at least for textured xv) I would guess there's some half-pixel offset somewhere causing the bilinear texture filter to produce grey out of 2 black, 2 white pixels. Maybe either coords are set up slightly wrong, or chip somehow set up incorrectly (for instance d3d and ogl have a half-pixel offset difference in sampling positions - not sure though if that's actually changeable on this chip). "
Created attachment 26960 [details] bitmap used to generate test YV12 pattern
From a thread in the xorg mailing list, it looks like the fix is quite simple. ref: http://lists.freedesktop.org/archives/xorg/2009-June/046155.html Krzysztof Halasa <khc at pm.waw.pl> writes: " > It seems that the fix to i915 is: > > diff --git a/src/i915_video.c b/src/i915_video.c > index 1ef58ac..3b4247c 100644 > --- a/src/i915_video.c > +++ b/src/i915_video.c > @@ -136,8 +136,8 @@ I915DisplayVideoTextured(ScrnInfoPtr pScrn, I830PortPrivPtr pPriv, int id, > format = COLR_BUF_ARGB8888 | DEPTH_FRMT_24_FIXED_8_OTHER; > > OUT_BATCH(LOD_PRECLAMP_OGL | > - DSTORG_HORT_BIAS(0x80) | > - DSTORG_VERT_BIAS(0x80) | > + DSTORG_HORT_BIAS(0x8) | > + DSTORG_VERT_BIAS(0x8) | > format); > > /* front buffer, pitch, offset */ > I think it's safe to commit. Seems like a simple mistake, those fields in that variable seem to be 4-bits wide. Fixes the problem. -- Krzysztof Halasa " Since I am not too versed into the GPU registry manipulation, I will let the bug assignee to verify it. On my system, this seems to be working just fine. Hugo Jacques
Pushed, thanks. commit 3418c6c16b108e45f67f3c868d28932266f7a0bc Author: Krzysztof Halasa <khc@pm.waw.pl> Date: Tue Jul 28 10:47:44 2009 +0800 h/v bias in 3DSTATE_DEST_BUFFER_VARIABLES is 4-bits wide Fixes bug #22370
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.