Problem with persistent scaling/shifting in RADEONDisplayVideo()

Alex Deucher alexdeucher at
Mon Jul 28 07:11:31 PDT 2008

On Mon, Jul 28, 2008 at 7:06 AM, Thomas Hilber <xorg-driver-ati at> wrote:
> On Mon, Jul 28, 2008 at 08:53:49AM +0200, Michel Dänzer wrote:
>> > the source is not copied exactly 100% to the destination. It appears if
>> > there still takes place a vertical shift of 1/2 pixel or even less.
>> Maybe some of the overlay registers aren't programmed quite correctly
>> for the 1:1 case. Alex Deucher may have some ideas.
> yes I hoped Alex Deucher could give me some hints. I would rather fix
> this issue myself because the error is not noticeable in a conventional
> setup though also existent there. I really don't want to bother anybody else
> with this issue.
> But I do not have any documentation about Radeons nor do I know where to
> get one. I made lots of experiments with the code near to this comment in
> 'radeon_video.c'

Unfortunately, I haven't really looked at the overlay code in ages.
As far as I know, no documentation on the overlay has been released
without nda.  I'm guessing it's some slight mis-configuration of the
something in the display video code, but I'm not sure what off hand.
Perhaps an issue with interlaced material as Roland suggested.

> /* we could do a tad better  - but why
>   bother when this concerns downscaling and the code is so much more
>   hairy */
> But without success.
> So I finally installed DirectFB - alas - the error does NOT appear there.
> That's another evidence for me that there is a bug in RADEONDisplayVideo().
> It's no hardware limitation.
> Maybe I will try to port parts of DirectFB overlay code to the Radeon DDX.

If you can find what's different in the directfb code, that would be
great.  Also, if you have any questions about any of the overlay
registers, I can definitely look up the information for you.
Unfortunately, I don't really have the time to dig into this myself at
the moment.

>> I assume this is due to scheduling latency between the vblank interrupt
>> and the textured video rendering getting emitted from userspace. It may
>> be possible to avoid this by synchronizing the textured video rendering
>> to vertical blank, see
> yeah! I already tried this. Syncronization with VBLANK itself is not a
> problem but the sheer vertical size of tearing area in texture mode.
> There are too many scanlines involved. Maybe we can give data to the
> board in smaller chunks to avoid this? Some illustration of what I mean.
> My screen resolution for PAL is 720x576.

I think the real solution is composite and pageflipping.  Although the
single triangle trick would definitely help.


More information about the xorg-driver-ati mailing list