If we are about to do a write-only drawing operation that will exceed
our cache, allocate a GPU bo and perform the operation inplace.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we would prefer to perform the copy on the GPU and if the pixmap is
virgin, create a GPU bo for the operation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Pixmaps are swapped out into the CPU after a period of inactivity. This
then prevents the core rendering routines from migrating the pixmap back
to the GPU until it gets used again on a Render path. However, we can
clear that CPU damage and enable migration before a number of key steps
in the expose process.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Following the switch to a global mode for damage, the elts array became
redundant and all that is required is the list of boxes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The batch compaction breaks the 1:1 mapping between the cpu buffer and
the bo, so we can no longer safely align the transfer to whole
cachelines.
References: https://bugs.freedesktop.org/show_bug.cgi?id=44091
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
GTK+ has a clever trick for premultiplying its images by loading the
same pixel data into both the source and mask, and then performing the
composite. This causes us to upload the same pixel data twice!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Even if we don't know the extents of the render operation, if the entire
pixmap is damaged we can still reduce the damage tracking.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Presume that we will not fallback and so treat a GPU only bo (one that
is initially created on the GPU) as being all-damaged. This makes future
operations cheaper as the damage tracking overhead is much reduced, and
the cost of the first readback will mainly be in the synchronisation
overhead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
RenderFillRectangles is often used to initially clear a pixmap after
creation by flooding it with a solid colour, as is PolyRect. We can
reduce further damage operations by checking for this condition.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
During creation of sna_pixmap we validate that we can use a GPU bo with
the target pixmap. This fails if we pass in a raw pixmap header, so
make sure the scratch pixmap is fully initialised first.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Replace the source picture+alpha with a bo that contains the RGB
channels from source and A from the alpha map.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we have no shader support for generic convolutions, we currently
create the convolved texture using pixman. A multipass accumulation
algorithm can be implemented on top of CompositePicture, so try it!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The only place where we did anything other than use the default was when
creating a new bo for CopyArea. In that case, basing the choice on the
src GPU bo was not only wrong but a potential segfault.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After 0c12f7cb0 we were setting the width/height of the pixmap *after*
trying to use them to determine if the pixmap could be created on the
GPU. Normally this would be corrected when we attempt to render, except
for the core drawing protocol.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Don't assume that a read/write will clear the active flag if the bo has
been exported to another DRI client.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Most small pixmaps appear to be single shot, so amalgamate them into one
buffer and trim our memory usage.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
These are treated by the core drawing routines as replacements for the
front-buffer attached to Windows, and so expect the usual BLT
accelerations are available, for example overlapping blits to handle
scrolling. If we create these pixmaps with Y-tiling and then they are
pinned by the external compositor we are forced to perform a double copy
through the 3D pipeline as it does not handle overlapping blits and the
BLT does not handle Y-tiling.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Only marginally better than falling all the way back to using the CPU,
is to perform a double copy to workaround the overlapping copy.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Short-cut the determination of whether it can be tiled and accelerated
-- we know it can't! This is mainly to cleanup the debug logs.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In the READ==0 case we know that the region does not intersect damage
because we have just subtracted, and checking the intersection causes us
to immediately apply the subtraction operation defeating the
optimisation and forcing the expensive operation each time.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Only those that point into scratch memory need to synchronized before
control is handed back to the client.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Mark the end of a sequence of CPU operations and force the decision to
map again to be based on the current upload operation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the last operation was on the GPU, continue on the GPU if this
operation overlaps any GPU damage or does not overlap CPU damage.
Otherwise, if the last operation was on the CPU only switch to the GPU
if we do not overlap any CPU damage and overlap existing GPU damage.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we now can accelerate most of the common core drawing operations, we
can create GPU bo for accelerated drawing on first use without undue
fear of readbacks. This benefits Qt especially which heavily uses core
the drawing operations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The theory being that we will also require cache space to copy from when
uploading into the shadow.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
UXA now also uses pixman_triangle_t in order for its fallback, so we
need to bump the required pixman version for UXA as well as SNA.
Reported-by: Fabio Pedretti <fabio.ped@libero.it>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43946
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>