On 20.06.2009 00:04, Krzysztof Halasa wrote:
> Hi,
>
> "Jacques, Hugo" <[email protected]> writes:
>
>> I get a strange phenomenon using the XV texture adapter in YV12 format
>> on my 945G hardware and a 2.7.0 xf86-video-intel driver.
>>
>> 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 grey rectangle!
>
> I think we're then in some sort of Matrix. I just opened the xorg list
> folder to write about precisely the same observation :-)
>
>> Same phenomenon appears on either VGA,
>> DVI or CVBS-TV monitors: it doesn't seem to be monitor/video encoder
>> issue-related.
>
> Yes. BTW the data in video memory is already "corrupted" - tested with
> mplayer, playdv for simplicity, and verified with xwd.
>
> The same on i915 + git driver and on Radeon RV6xx with Fedora 11. The
> effects are precisely the same, there is some averaging/filtering here.
> But it only happens with Xvideo output - X11 and GL are fine. OTOH on
> R300 it's different - textured XVideo output looks good (at least much
> better, that's a high res display and individual pixels are hard to
> see), but the XVideo overlay has the symptom (RV6xx has no overlay).
X11 doesn't do any scaling, so you will always get a 1:1 exact mapping.
textured xv however uses bilinear texture filtering (some drivers can
actually do better), it doesn't even know what a 1:1 mapping is. So if
you have some half-pixel offset somewhere bilinear filter will produce
exactly the same grey for all pixels if you have an alternating pattern
of black and white lines in the source image.
With a very quick look at the r600 code, I suggest trying out the
attached patch to test my theory about half pixel offsets in hardware.
This could mess though with EXA acceleration, so if you see a bit odd
corruption don't be surprised :-).
As said I'm not sure if (and if how) i915 can be tweaked for that (if
not just add offset to the tex coords).
Overlays are a bit a different matter, not only are they usually hard to
set up really correctly but they may actually use filters where you
can't get a basically unfiltered output even with a 1:1 mapping (not
sure about this though), unless you'd switch filtering off (I guess
could do that if we'd add detection for unscaled case).
Roland
diff --git a/src/r6xx_accel.c b/src/r6xx_accel.c
index e9741cd..65834bf 100644
--- a/src/r6xx_accel.c
+++ b/src/r6xx_accel.c
@@ -974,7 +974,7 @@ set_default_state(ScrnInfoPtr pScrn, drmBufPtr ib)
EREG(ib, PA_SU_POLY_OFFSET_FRONT_OFFSET, 0);
EREG(ib, PA_SU_LINE_CNTL, (8 << PA_SU_LINE_CNTL__WIDTH_shift)); /* Line width 1 pixel */
- EREG(ib, PA_SU_VTX_CNTL, ((2 << PA_SU_VTX_CNTL__ROUND_MODE_shift) |
+ EREG(ib, PA_SU_VTX_CNTL, ((2 << PA_SU_VTX_CNTL__ROUND_MODE_shift) | PIX_CENTER_bit |
(5 << QUANT_MODE_shift))); /* Round to Even, fixed point 1/256 */
EREG(ib, PA_SU_POLY_OFFSET_CLAMP, 0);
_______________________________________________
xorg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xorg
