diff options
author | Marc Aurele La France <tsi@xfree86.org> | 2006-07-29 01:02:48 +0300 |
---|---|---|
committer | George Sapountzis <gsap7@yahoo.gr> | 2006-07-29 01:02:48 +0300 |
commit | 91b8b0ca41ad0b9659f0982a05148cab8558e9d5 (patch) | |
tree | 90f507a398670cadd3ee7708420e7673b5c557be | |
parent | 7800407a2db4b7307192bf3b43fffb9c4748b9c0 (diff) |
Bug #807: copy throttling.
Fix corruption associated with the engine randomly not waiting for a copy
operation to commit its results.
-rw-r--r-- | src/atimach64accel.c | 12 |
1 files changed, 12 insertions, 0 deletions
diff --git a/src/atimach64accel.c b/src/atimach64accel.c index a0a9e17..272de3d 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); } /* |