On Mon, Jul 28, 2008 at 7:06 AM, Thomas Hilber <[EMAIL PROTECTED]> 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 _______________________________________________ xorg-driver-ati mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-ati
