Tearing problem at bigger overlay sizes

[Christiaan van Dijk]

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.