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>
In this case, we may also be handling an unattached pixmap, so avoid the
deferences of the sna_pixmap unless we are sure it will exist.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Allow --enable-ums-only as a counter-option to --enable-kms-only in case
the distribution wishes to enable a non-root KMS driver but also offer
a separate UMS driver for i81x.
On the second pass, use "--enable-ums-only --disable-uxa --disable-sna"
to get the trimmed down unaccelerated i810 support.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Under the circumstances where we can not instead stream the write into
the GPU bo, we need to use the busy CPU bo.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54978
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the EDID blob id is set to 0, that means that it does not exist and
so we can safely skip it.
References: https://bugs.freedesktop.org/show_bug.cgi?id=55193
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Based on a suggestion by Chad Versace (taken from a patch for mesa).
This allows for a faster upload of pixel data through a ShmImage, or for
complete replacement of a GPU bo.
Using a modified version of x11perf to upload to a pixmap rather than
scanout on an IVB i7-3720qm:
Before:
40000000 trep @ 0.0007 msec (1410000.0/sec): ShmPutImage 10x10 square
4000000 trep @ 0.0110 msec ( 90700.0/sec): ShmPutImage 100x100 square
160000 trep @ 0.1689 msec ( 5920.0/sec): ShmPutImage 500x500 square
After:
40000000 trep @ 0.0007 msec (1450000.0/sec): ShmPutImage 10x10 square
6000000 trep @ 0.0061 msec ( 164000.0/sec): ShmPutImage 100x100 square
400000 trep @ 0.1126 msec ( 8880.0/sec): ShmPutImage 500x500 square
However, the real takeaway from this is that the overheads for
ShmPutImage are substantial, only hitting around 70% expected efficiency,
and overshadowed by PutImage, which for reference is
60000000 trep @ 0.0006 msec (1800000.0/sec): PutImage 10x10 square
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When computing the active region with of a composite operation with
unknown extents we try to simply use the whole Drawable. However, this
needs to be clipped otherwise it may trigger assertion failure with an
offscreen pixmap.
References: https://bugs.freedesktop.org/show_bug.cgi?id=55164
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson