aboutsummaryrefslogtreecommitdiffstats
path: root/include
diff options
context:
space:
mode:
authorMarek Olšák <maraeo@gmail.com>2010-09-12 05:09:12 +0200
committerDave Airlie <airlied@redhat.com>2010-09-13 20:30:02 +1000
commitec00efb72f4b88078427d01f38f664c67c7ca0c0 (patch)
tree9cd8810b734378eb02704babcb7d5ebb476da1a2 /include
parentb741be82cf2079f71553af595610f17a3a3a752a (diff)
downloadmrst-s0i3-test-ec00efb72f4b88078427d01f38f664c67c7ca0c0.tar.gz
mrst-s0i3-test-ec00efb72f4b88078427d01f38f664c67c7ca0c0.tar.xz
mrst-s0i3-test-ec00efb72f4b88078427d01f38f664c67c7ca0c0.zip
drm/radeon/kms: increase lockup detection interval to 10 sec for r100-r500
One subtest of mesa/demos/gltestperf takes 9 seconds to complete, so to prevent an unnecessary gpu reset followed by a hardlock, I am increasing the interval to 10 seconds after which a GPU is considered in a locked-up state. This is on RV530. However, with a little slower GPU, we would surpass the interval easily, so this is not a good fix for gltestperf. Nevertheless, this commit also fixes hardlocks in the applications which render at speed of less than 1 frame per second, where the whole frame consists of only one command stream. The game Tiny & Big is an example. This bar is now lowered to 0.1 fps. Now the question comes down to whether we should (often unsuccessfully) reset the GPU at all? Once we have stable enough drivers, we won't have to. Has the time come already? If possible, this commit should go to stable as well. Signed-off-by: Marek Olšák <maraeo@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions