summaryrefslogtreecommitdiff
path: root/src/atimach64accel.c
diff options
context:
space:
mode:
authorMarc Aurele La France <tsi@xfree86.org>2006-07-29 01:02:48 +0300
committerGeorge Sapountzis <gsap7@yahoo.gr>2006-07-29 01:02:48 +0300
commit91b8b0ca41ad0b9659f0982a05148cab8558e9d5 (patch)
tree90f507a398670cadd3ee7708420e7673b5c557be /src/atimach64accel.c
parent7800407a2db4b7307192bf3b43fffb9c4748b9c0 (diff)
Bug #807: copy throttling.
Fix corruption associated with the engine randomly not waiting for a copy operation to commit its results.
Diffstat (limited to 'src/atimach64accel.c')
-rw-r--r--src/atimach64accel.c12
1 files changed, 12 insertions, 0 deletions
diff --git a/src/atimach64accel.c b/src/atimach64accel.c
index a0a9e176..272de3db 100644
--- a/src/atimach64accel.c
+++ b/src/atimach64accel.c
@@ -481,6 +481,18 @@ ATIMach64SubsequentScreenToScreenCopy
outf(SRC_WIDTH1, w);
outf(DST_Y_X, SetWord(xDst, 1) | SetWord(yDst, 0));
outf(DST_HEIGHT_WIDTH, SetWord(w, 1) | SetWord(h, 0));
+
+ /*
+ * On VTB's and later, the engine will randomly not wait for a copy
+ * operation to commit its results to video memory before starting the next
+ * one. The probability of such occurrences increases with GUI_WB_FLUSH
+ * (or GUI_WB_FLUSH_P) setting, bitsPerPixel and/or CRTC clock. This
+ * would point to some kind of video memory bandwidth problem were it noti
+ * for the fact that the problem occurs less often (but still occurs) when
+ * copying larger rectangles.
+ */
+ if ((pATI->Chip >= ATI_CHIP_264VTB) && !pATI->OptionDevel)
+ ATIMach64Sync(pScreenInfo);
}
/*