For many of the core drawing routines, passing a BoxRec for the fill is
more convenient since they already have one generated by the clip
intersection.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As damage accumulation is handled modally, we do not need to track the
mode per elt and so attempt to simplify the code.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I translated the region to copy by the composite pixmap offset, only
failed to use the translated region for the actual copy command (using
instead the original boxes). Fix that mistake by avoiding the temporary
region entirely and applying the translation inplace.
We also have to be careful in the case of copying between two composited
windows that have different offsets into the same screen pixmap.
This fixes the regression introduced with a3466c8b69 (sna/accel:
Implement a simpler path for CopyArea between the same pixmaps).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the bo is outside of our control whilst it is under the influence of
an external renderer, we try to maintain it on the gpu so as to avoid
unnecessary ping-pong. But once it is wholly back under our control, we
want to stop paying the penalty for sharing it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Take advantage of any available temporary buffer that we reuse for
readback knowing that it is the last operation in the batch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We track the last ring used when active so as to avoid stalling between
batches. Once the GPU has retired all the pending requests, we can use
whichever ring is preferrable for the next operation without any danger
of stalling upon submission.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is to workaround a ping-pong issue involving small icons. The
horrible sequence of operations appears to use a tiled FillRect to copy
from the scanout onto to a temporary pixmap, which causes us to
readback from the scanout. We are destined to hit the fallback path there
anyway until we implement stippling...
References: https://bugs.freedesktop.org/show_bug.cgi?id=41718
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We can only emit state between primitives, ergo we need only check for
state updates if we've finished the vbo or are starting a new operation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
So that we can simply use the pending DRAWRECT as the non-pipelined
flush required following use of a BLT command.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I missed clearing the all-damaged flag on the subtract fast paths,
causing us to disregard further GPU damage and losing track of render
coherency.
Reported-by: Roman Jarosz <kedgedev@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41769
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The first workaround was a performance killing MI_FLUSH_DW after every
op. This workaround appears to be a stable compromise instead, only
requiring a redundant command after every BLT command with little
impact on throughput.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=27892
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39524
Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We only need to emit the vbo description either at the beginning of a
new op (when the state may have changed) or after finishing a full vbo.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the fb routine does not access the pixel data directly, but instead
calls into an mi routine, we can defer the readback and possibly avoid
it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson