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>
In the case where we emit a no-op, we may not attempt to finish binding
the vbo as it is considered empty. This leaves a stray relocation for
the next batch, and also causes it to believe that it has a vbo bound
already.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As it is advisable to combined the synchronous rendering debug option
with other debugging options, it is more convenient to make it into a
configure option: --enable-debug=sync
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is handy for the case where the batch triggers a GPU hang rather
than being rejected by the kernel.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes regression from
commit c789d06cf8
Author: Dave Airlie <airlied@redhat.com>
Date: Mon Jan 7 13:57:21 2013 +1000
intel: fixup damage posting to be done correctly around slave pixmap
which causes the entire slave scanout to be readback from uncached
memory every time a pixel is modified.
Reported-by: Stephen Liang <inteldriver@angrywalls.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59539
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we perform a read-read synchronisation, the kernel may still believe
that the bo is busy as it remains on the active lists being read by the
GPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As gen6/7 need to prevent ring switching and perform a rendercopy if we
need to perform a vsync'ed copy.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Remember that for an inplace operation we are not dealing with an a8
mask, but rather a x8r8g8b8 surface and so need to step accordingly.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It is not as clearly beneficial as for GetImage, as for example toolkits
may only push the shadows around a window.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This was to track a pixmap that had been used for migration (i.e had in
the past been used for mixed rendering). It is no longer used so remove
it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The complexity of the function has been moved to move-to-cpu so we can
take further advantage of the simplified logic in put_zpixmap to clean
up the code by removing an unwanted goto.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Colin Walters
Adam Jackson