With the introduction of GEM, we can continue to submit batch buffers
irrespective of ownership of the console, so do so.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Similar to the empty glyphs make sure that we just advance by the
character width without drawing anything.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A space is encoded as a 1x1 blank glyph, but we still need to advance by
its character width and so we cannot simply discard the glyph.
References: https://bugs.freedesktop.org/show_bug.cgi?id=44091id=44091
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to prevent it falling foul of the inactive pixmap reaper, we
need to mark the pixmap as pinned.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Still not getting the single-stream mode that I am aiming for!
Reported-by: Matti Hamalainen <ccr@tnsp.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44150
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Marginally simplify the convoluted logic for choosing the most
appropriate path and help prevent further errors.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
Chris Wilson