In order to get the ordering correct we need to free the xf86_cursors
before calling the miPointerCloseScreen. This requires us to insert a
hook at the top of the CloseScreen chain. However we still require the
final CloseScreen hook in order to do the fundamental clean up, hence
split the CloseScreen callback into two phases.
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>
But only if we meet the required versions of Xorg and leave UXA as the
default AccelMethod for the time being.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Originally I intended to skip assigning the box on the last list.
However, loop simplicity failed and now we run the risk of writing
beyond the end of stack_extents, and overwriting the list_extents
pointer.
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>
i810_hwmc.c can pull it in via i810.h like everybody else. As for
xaalocal.h, I have no idea what that is... Both appear to be cut'n'paste
includes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to put current front_buffer to back buffer thus we
don't need to create a new back buffer next time. This behaviou
should be the same with or without glamor. Previous code
incorrectly discard the previous front_buffer and cause a
big buffer leak problem.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
glamor_glyphs will never fallback. We don't need to keep a
uxa glyphs cache picture here. Thus simply bypass the
corresponding operations.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we can acheive the same rasterisation results without the mask,
rendering the glyphs-to-dst is so much faster that it outweighs the cost
of checking for overlapping glyphs.
The penalty is then for code that correctly declared that it required
a mask, who now have an extra ~10% overhead in the processing of their
glyphs.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Spotted by Zhigang Gong is this optimisation to avoid the problem with
multiple lines passed in a single request (using multiple lists). As the
start of line will overlap with the previous line when we use the simple
bbox comparison, we always declare those runs as overlapping and so we
cannot substitute a glyph mask. However, we can reduce the problem to
only checking for overlapping glyphs within a list and then checking for
overlapping lists. Very, very clever.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It was only ever used in conjunction with HAS_DEBUG_FULL. For debug
purposes it is as easy to redefine DBG locally. By simplifying the DBG
macro we can create it consistently and so reduce the number of compiler
warnings.
Long term, this has to be dynamic. Sigh.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we only operating on a small region of the pixmap and have require
damage migration in the past, we are likely to require migration again
at some point. So keep track of small damage areas.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We consideer a singular FillRect to be a sequence point in the rendering
commands, that is it is usually used to clear the background as the first
operation in a drawing sequence. So it is useful to ask if we can move
the sequence to the GPU at that point.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Look for those operations that maybe better via the GTT and those that
are preferred to be in CPU cache. The wonders of multiple layers of
heuristics.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the existing front buffer is clear, just apply the clear color to
then new buffer rather than copy the old one across.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we hook into the DestroyWindow notification, we can reliably use the
original Drawable reference and avoid the secondary object lookups.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we now emit work whenever we wakeup and find the GPU idle, we rarely
actually have pending work in the deferred flush queue, so try to avoid
installing a timer if we are not accumulating work.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Zhigang Gong
Daniel Stone