Tearing problem at bigger overlay sizes

[Christiaan van Dijk]

Hi all,

here's a summary of the experiments I have been doing.

* A RS690 can not render a full-HD image in the vertical blanking time 
(@50Hz) but the engine should easily be able to render a full screen 
when split in two halves. This is the assumption I'm now working with 
and I feel confident about this.

* For testing purpose I'm rendering the source image (SD-TV) to a top 
and bottom half, I'm using the full image scaled to half the height, 
this eases comparison between the top and bottom segment. Before 
rendering a segment I load the AVIVO_D1MODE_VLINE_START_END register and 
issue a WAIT_UNTIL condition. These are some of the results:
(hope this table works :-/)

	INV 	start
	stop
	
	Result
top half
bottom half
	Set
Set
	0
540
	540
1080
	WAIT+FE
WAIT+FE
	tearing
tearing
top half
bottom half 	Set
Set
	0
540
	540
1080
	FE
FE
	tearing
tearing
top half
bottom half 	
	0
540
	540
1080
	FE
FE
	tearing
tearing
top half
bottom half 	Set
Set
	540
0 	1080
540 	WAIT+FE
WAIT+FE
	tearing
STABLE
top half
bottom half 	Set
Set
	0
540
	540
1080
	RE
RE
	tearing
STABLE
top half
bottom half 	
	0
540
	540
1080
	RE
RE
	tearing
STABLE
top half
bottom half 	
	270
810
	275
815
	RE
RE
	tearing
STABLE
top half
bottom half 	
	540
1080
	545
1085
	RE
RE
	tearing
STABLE
top half
bottom half 	
	810
270
	815
275
	RE
RE
	tearing
tearing
top half
bottom half 	
	-
0
	-
5
	-
RE
	tearing
STABLE
top half
bottom half 	
	1080
-
	1085
-
	RE
-
	tearing
tearing
top half
bottom half 	
	0
-
	5
-
	RE
-
	tearing
tearing

RE=RADEON_WAIT_RE_CRTC_VLINE
FE=RADEON_WAIT_FE_CRTC_VLINE
WAIT=RADEON_WAIT_CRTC_VLINE

* I can only get the bottom segment stable, top is always tearing. If I 
scale the playback window to normal size (around 300 lines) the top 
segment is tearing and the bottom segment is stable, this is independent 
of the position of the window (top/bottom screen). The register values 
for vertical blanking are fixed and do not scale with the window in this 
test, very surprising.

* To see if the problem would be in the source data I added a 2ms delay 
between the loading of the data in the framebuffer and the starting of 
the rendering, this has no effect.

* I tried using 3 wait points (line 0, 270, 810). This is causing 
mplayer to slow down video playback (complains too slow machine). Every 
wait_until seems to be waiting for a full frame instead of the 
sequential position in one frame.

* I tried putting all commands in the ring buffer to ensure execution in 
the right order:
- Write VLINE_START_END, write WAIT_UNTIL
- Write Vertex data top segement
- Write R300_DC_FLUSH_3D
- Write VLINE_START_END, write WAIT_UNTIL
- Write Vertex data bottom segement
- Write R300_DC_FLUSH_3D
The documentation seems to suggest this is needed for R500 chips but 
should have no effect on R300 chips. On the RS690 this has no effect, 
identical results. There seems to be a minor bug in the current code 
here where the space in the ringbuffer is allocated, not sure if this is 
critical.

* The AVIVO_D1MODE_VLINE_START_END is doing something but it's not clear 
what is happening. The register size also puzzles me, there seem to be 
14 bits reserved for start and stop position (IRC blog) while the 
vertical counter register only has 13 bits.

I'm really starting to run out of idea's here, any input would be very 
appreciated. The system is intended as a HTPC connected to a full-HD LCD 
but is pretty useless with the current performance. Fglrx drivers are 
incredible unstable with full-HD and 64-bit platform and also do not 
seem to resolve the tearing issue.

Christiaan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.x.org/archives/xorg-driver-ati/attachments/20090119/12485204/attachment.htm