If the kernel replies that a bo is still busy, stage its retirement
through the flushing list to be certain that we never stall on a
subsequent write.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Currently if the dst is wholly contained within the CPU, then we try to
continue to operate on the GPU. However, if we have FORCE_GPU set, it
means that one of the sources for the operation resides on the GPU, and
that would require a readback in order to perform the operation on the
CPU. Hence, if we try to use a CPU bo and fail, convert back to using
the GPU bo if forced.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we encounter a delayed flip with a different back buffer than the
current, simply update the info rather than bug out.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As scanouts are uncached, they need to be treated carefully and
decontaminated before being placed in the general cache. So double check
that no bo in those caches are still marked as a scanout.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Having relaxed the earlier assertion because the kernel is wrong, we can
now retire for READ-READ optimisations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
All the callers have explicitly changed the domain upon the bo before
calling kgem_bo_retire(), so we still get the occasional sporadic
failure as kgem_busy() reports true. Kill the assertion for now.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
Chris Wilson