Matthias Hopf wrote: > On Jan 09, 09 22:01:12 +0100, Christiaan van Dijk wrote: > >>> The engine is still stalling for the vline. The problem is you are >>> hitting the hw guardband limits on r3xx/r4xx. The diagonal tearing is >>> due to the fact that the hw renders a quad as two triangles. To avoid >>> this we render to a single clipped triangle; this means the triangle >>> > > If you're using guardband clipping, this means that you're really > rasterizing (and throwing away) an awful lot of pixels. And this is > still fast enough? Fascinating. > > Matthias > > Yep, not sure how the engine is handling the non-used parts of the triangle, if I display the entire triangle the tails seem to be filled with copies of the last horizontal/vertical line of the source. Speed however seems quite OK. Vertical AVIVO synchronisation is not working on the RS690 (at least not in the intended way), tried several options without desired result, only the RE bit seems to do something. To see if I could get a tear free displayed I tried rendering the source block (SD TV 16:9) to the destination block (HDTV 1080p/50Hz) in quads of 100 lines max. The idea was to wait for a V-sync and refresh the display from top to bottom to keep up with the refresh instead of updating the entire display in one quad (2 triangles). The picture is quite good, at least much better as the huge diagonal tear but still not tear free. Sometimes the diagonal tear can be seen in one or more (2..4 segments out of 11) of the 100 line segments. This last point is really puzzling, this could indicate the graphics engine is just keeping up with the refresh, slightly slower or slightly faster.
Also did some digging in the fglrx code. There are some vertical sync wait loops in here which use bit 0 in registers 0x609C/0x689C for crtc0/crtc1. There however seems to be some kind of exclusion for AVIVO (bit 0 must be clear in AVIVO_DxVGA_CONTROL and bit 0/1 must be set in 0x6F08). No idea what the registers do but will give it a try. Not sure if it's a good idea to put a dumb wait loop in the driver but will see what happens (or not). Christiaan. _______________________________________________ xorg-driver-ati mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-ati
