diff options
| author | Chris Wilson <chris@chris-wilson.co.uk> | 2010-11-05 09:58:45 +0000 |
|---|---|---|
| committer | Chris Wilson <chris@chris-wilson.co.uk> | 2010-11-05 10:07:46 +0000 |
| commit | a44a63d2ff6c01c3dc61de6f736dd441ddd25e52 (patch) | |
| tree | a8dd4f9bd6ff69261d447dc0f5f6976ddcc1d4ff /src/intel_batchbuffer.c | |
| parent | 52b32436b9e14a3e13818f80102150ff5bc3c002 (diff) | |
Wait for any pending rendering before switching modes.
A perennial problem we have is the accursed WAIT_FOR_EVENT hangs, which
occur when we switch the framebuffer before the WAIT_FOR_EVENT completes
and upsets the GPU.
We have tried more subtle approaches to detected these and fix them up in
the kernel, to no avail. What we need to do is to delay the framebuffer
flip until the WAIT completes, which is quite tricky in the kernel
without new ioctls and round-trips. Instead, apply the big hammer from
userspace and synchronise all rendering before changing the framebuffer.
I expect this not to cause noticeable latency on switching modes (far
less than the actual modeswitch) and should stop these hangs once and
for all.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31401 (...)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Diffstat (limited to 'src/intel_batchbuffer.c')
| -rw-r--r-- | src/intel_batchbuffer.c | 3 |
1 files changed, 3 insertions, 0 deletions
diff --git a/src/intel_batchbuffer.c b/src/intel_batchbuffer.c index fec52819..9f8ca6f3 100644 --- a/src/intel_batchbuffer.c +++ b/src/intel_batchbuffer.c @@ -283,6 +283,9 @@ void intel_batch_wait_last(ScrnInfoPtr scrn) { intel_screen_private *intel = intel_get_screen_private(scrn); + if (intel->last_batch_bo == NULL) + return; + /* Map it CPU write, which guarantees it's done. This is a completely * non performance path, so we don't need anything better. */ |