As we discard the buffer after the next batch, we will lose the contents
of the pixmap. Instead discard the cache, and treat it as a normal
shadow again.
References: https://bugs.freedesktop.org/show_bug.cgi?id=42426
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This was originally split between into functions for flexibility that
nothing used, so merge the duplicated code into a common function.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The synchronisation costs overwhelm any benefit from offloading the
copy, unless we are currently streaming the updates anyway.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Not only must we defend against the span starting too far to the right,
we must also defend against the span terminating too far to the left.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Skip the filling of the whole pixmap if we have a small read and we
know the GPU bo is clear. Also choose to operate inplace on the GPU bo
if we meet the usual criteria.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It is useful to know and to receive confirmation that you have
successfully compiled and executed the driver with debugging enabled.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Part of the large buffer handling was to move the decision making about
whether to create GPU bo for a pixmap to creation time. The single
instance where we change our minds later is involving large glyphs which
we choose not to cache.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Ordinarily if the GPU is wedged, we just want to create a shadow buffer.
Except that we must ensure that we do allow a bo to be created for
attaching to the scanout.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The joy of conditional compiles masked this compilation failure when
testing.
Reported-by: Reinhard Karcher <reinhard.karcher@gmx.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Do not attempt to further reduce the operator locally in each backend as
the reduction is already performed in the upper layer.
References: https://bugs.freedesktop.org/show_bug.cgi?id=42606
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Instead of keeping a virgin partial buffer around on its inactive list,
just transfer it to the global bo cache (in actuality destroy it since
it is just a kmalloc with no pages bound).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The root pixmap, for instance, may have unique DRI2Drawables for each
inferior window. We only want to clear the flush flag on the last
release, so we need to keep a count of how many DRI drawables remain
attached rather than a solitary flag.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As if we try to perform the operation with outstanding operations on the
source pixmaps, we will stall waiting for them to complete.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we may be holding on to them as an active mapping whilst they are
executing; reseting the used counter back to zero in this case can cause
corruption.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Whilst iterating the partial list and uploading the buffers, we need to
avoid trigger a recursive call into retire should we attempt to shrink a
buffer. Such a recursive call will modify the list beneath us so that we
chase a stale pointer and wreak havoc with memory corruption.
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47061
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In the refactoring to avoid repeatedly applying the singular
pCompositeClip, the check for the all-clipped state was lost.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson