In this fairly common case, avoid both the double pass and use a simpler
algorithm as we can simply reverse the order of the boxes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Even if the pixmap is entirely damaged on the CPU, we still may be in
the process of transferring it and so cause an unwanted stall.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
So there appears to be a bug hidden here. But only when we scroll
upwards in a GTK+ application. Hmm.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
That would have been much more successful had I not supplied the wrong
opaque formats to the sampler.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
Chris Wilson
Zhigang Gong
Daniel Stone