Problem with persistent scaling/shifting in RADEONDisplayVideo()
Thomas Hilber
xorg-driver-ati at toh.cx
Mon Jul 28 04:06:43 PDT 2008
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'
/* 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.
> 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.
The first two pictures refer to overlay XV (the good case). The next two
pictures refer to texture XV (the bad case):
+---------------------------------+
| |
| |
| frame 1 |
| |
| |
|---------------------------------| one scanline between the frames
| |
| |
| frame 2 |
| |
| |
+---------------------------------+
Picture 1. overlay double buffers switch almost instantly to next frame
(not synchronized to VBLANK here for better demonstration)
+---------------------------------+
| |
| |
| |
| |
| |
| frame 1 |
| |
| |
| |
| |
| |
+---------------------------------+
Picture 2. synchronized to VBLANK the tearing scanline in overlay mode fully
hides behind VBLANK interval => good
+---------------------------------+
| |
| |
| frame 1 |
| |
|-------------\ | -+ very large area (>VBLANK interval)
| \ | | with pixels of frame 1 and frame 2
| \ | | in one scanline
| \----------------| -+
| |
| frame 2 |
| |
+---------------------------------+
Picture 3. textured mode takes very long until consistent frame is
shown (again not synchronized to VBLANK here for better
demonstration of this effect)
+---------------------------------+
| \----------------| <- end of frame 0 visible
| |
| |
| |
| |
| frame 1 |
| |
| |
| |
| |
|-------------\ | <- start of frame 2 visible
+---------------------------------+
Picture 4. textured mode now synchronized to VBLANK. But still tearing
effects are visible at the very top and bottom of screen => bad
Cheers
Thomas
More information about the xorg-driver-ati
mailing list