If we fail to submit a batchbuffer, the driver is broken and likely to
continue to fail to render. Give up, and fallback to swrast so that the
session remains usable.
References: https://bugs.freedesktop.org/show_bug.cgi?id=59771
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we are trying to find the best coverage, then by definition if the
drawable is an exact match for one CRTC, we can stop looking.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the GPU bo is currently mapped to the Pixmap, we need to be sure to
invalidate that mapping if we swap the GPU bo (for SwapBuffers). If we
forget, we leave a dangling pointer to chase.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60042
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Modify the presumption that if we are using a core operation on a shadow
pixmap, then we are likely to continue migrating that pixmap back and
forth.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we need to synchronize that bo before the next reply, we need to keep
track of it whenever it is active on the GPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When completing a batch mid-operation, we need to wait upon the other
threads to complete their writes so that memory is coherent before
submitting the work to the GPU. This was achieved by forcing the finish,
but all that from that is the wait, which makes the handling of threads
much explicit and removes the unnecessary vbo refresh.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
X uses them (SIGIO especially) for input handling, and gets rightfully
confused if it finds itself in a different thread.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The point of the refactor was to execute the last stage of the composite
in the master thread, so do so.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The clipExtents is in screen coordinates whereas we just want to confirm
that the maximum pixel to be copied lies with the DRI2 buffer, which is
relative to the drawable.
Reported-by: Matthieu Baerts <matttbe@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59806
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The goal is to reject stale DRI2 buffers that are smaller than the
target due to not-yet-handled ConfigureNotify, but not to reject
blitting from Windows that are larger than the frontbuffer.
Fixes a regression from the overzealous
commit b27ecf3059
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Nov 12 14:06:06 2012 +0000
sna/dri: Prevent scheduling a swap on stale buffers
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It helps to wait upon the event we program and enable.
References: https://bugzilla.kernel.org/show_bug.cgi
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It helps to wait upon the event we program and enable.
References: https://bugzilla.kernel.org/show_bug.cgi
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we inverted the predicate, we no longer restored the original
operation after performing a CA pass - glyph would randomly become
white.
Reported-by: Jiri Slaby<jirislaby@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=47597
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Still no sure just how the bo ends up there, but as there seems to be
the occasional malinger, just free it.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=47597
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we never used the bo as an actual scanout it will never have had been
moved to the uncached domain and so we can return it back to the system
cache.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=47597
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Do as told; both the LRI and WAIT_FOR_EVENT need to be in the same
cacheline for an unspecified reason.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The hardware needs to be programmed with the line before the desired
scanline, wrapping around as required.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we are carrying over a nearly full vbo from one batch to the next, we
may indeed finish it prior to writing any new primitives and so the
assert is truly bogus.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The documentation says that both start/end scanline need to be the line
before the desired value, and so to program the first scanline we need
to set it to the last scanline. The docs also say that the lower 3 bits
are ignored, so tweaked the values programmed accordingly with an extra
check that the window is not reduced to 0.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes a regression from commit a6ecb6d31d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Jan 16 09:14:40 2013 +0000
sna: Discard the batch if we are discarding the only buffer in it
as we may keep a stale relocation for the vertex buffer alive if we
attempt to clear the bo using the render engine before discarding it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Allow the DDX to continue even if the kernel rejects our batchbuffers by
disabling hw acceleration - just extends the existing hang detection to
also handle the driver producing garbage.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson