Problem with persistent scaling/shifting in RADEONDisplayVideo()

[Alex Deucher]

On Mon, Jul 28, 2008 at 7:06 AM, Thomas Hilber <xorg-driver-ati at toh.cx> 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
>>
>> http://cgit.freedesktop.org/~agd5f/xf86-video-ati/log/?h=vsync_accel
>
> 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.

Alex