They appear to work fine with the BLT and only seem to cause issues when
used with the sammpler. So enable them for accelerated uploads and
downloads.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>