Revert back to basics, and clear the CPU flag everytime we use the GPU,
rather than try to avoid clearing it along some paths.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I thought these were completely specified via the LOAD_STATE_IMMEDIATE
commands we used whilst seting up the render pipeline. I was wrong.
Reported-by: Timo Kamph <timo@kamph.org>
References: https://bugs.freedesktop.org/show_bug.cgi?id=55455
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
So that we keep the assertion checks that without CPU damage we can not
be on the cpu.
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55591
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we need to clflush the scanout buffer as we return it to the bo cache
on SNB+, it is costly to terminate the pageflipping as soon as we drop a
frame as mesa often fails to keep up to the vrefresh rate.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In an interesting twist during teardown, the driver info structure is
freed long before the caches. However, the glyph cache teardown was
checking to see if glamor was enabled to see if it could skip the
teardown. In fact, since we won't have created the glyph caches in that
circumstances it was safe any way.
Reported-by: Maarten Lankhorst <m.b.lankhorst@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Just ignore the error return from WaitVBlank and make up a value for
last MSC/SBC similar to an unattached Drawable.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55395
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we delay the dropping of DRM master we may complete a VT switch
before we are ready and so prevent a second X server from reacquiring
master, and dying.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55446
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we attempt to power up the pipe through a DPMS request, but it was
previously disabled due to an error, first try re-enabling.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As intel_crtc_on() depends upon the current value for determining if the
pipe is active, we can only change the value afterwards.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we schedule a flip to happen on a far distant vblank, it is possible
for us to disable the pipes with a modeset, whilst maintaining the fb
size, or with a DPMS command. If the pipe is disabled and we still try
to flip, then we trigger an EINVAL error from the kernel.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Adam Jackson was kind enough to point out that mibstore had been a no-op
since xorg-1.4 and the earliest we claim to support is xorg-1.6.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The async case needs special handling as the current front buffer may be
pending a flip onto the scanout which needs to be completed even if the
Drawable is destroyed.
Fixes regression from commit ad877abdc7
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sat Jul 7 17:48:52 2012 +0100
sna/dri: Attach the chain of frame events to the Window, not pixmap
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In the Ubuntu xserver it is apparently possible for the Screen to be
deleted prior to being fully initialised. Make sure we don't crash in
that situation!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55346
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Just in case on the off-chance that the kernel modifies the pipe and we
had a pipe-dependent operation in the batch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
commit 4dc2a76740d921c824a4d8193f39dd373475f02a
Author: Adam Jackson <ajax@redhat.com>
Date: Thu Sep 20 17:57:00 2012 -0400
miext/damage: Only wrap into the GC ops chain if there's a listener (v3)
leaves the GC->funcs still pointing to the damage layer as it calls into
the driver functions, so we need to be careful to restore the correct
function table after we manipulate the GC for fallbacks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson