Otherwise we do not detect gradients that start from white!
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48407
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Caught by the addition of the assertion.
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>
If the required temporary mask is larger than the 3D pipeline can
handle, just render to a CPU buffer rather than redirect every glyph
composition.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The shaders treat colours as an argb value, however the clear color is
stored in the pixmap's native format (a8, r5g6b5, x8r8g8b8 etc). So
before using the value of the clear color as a solid we need to convert
it into the a8r8g8b8 format.
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48204
Reported-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47308
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Incurs a slight loss of precision for the internal gradient, but much
more preferable to the artefacts around the borders with RepeatNone.
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45016
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Everytime we issue a MI_WAIT_FOR_EVENT on a scan-line from userspace we
run the risk of that pipe being disable before we submit a batch. As the
pipe is then disabled or configured differently, we encounter an
indefinite wait and trigger a GPU hang.
To minimise the risk of a hotplug event being detected and submitting a
vsynced batch prior to noticing the removal of the pipe, perform an
explicit query of the current CRTC and delete the wait if we spot that
our framebuffer is no longer attached. This is about as good as we can
achieve without extra help from the kernel.
Reported-by: Francis Leblanc <Francis.Leblanc-Lebeau@verint.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45413 (and others)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It's the location of the pixels within the row that matter for
alignment!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47418
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Magnus Kessler <Magnus.Kessler@gmx.net>
Magnus found that inplace_row was still crashing on his setup when it
tried to perform an 8-byte aligned write to an unaligned pointer. This
time it looks like the row pointer itself was not 8-byte aligned, so
instead of assuming that and fixing up the indices, ensure that the
(index+row) results in an 8-byte aligned value.
Reported-by: Magnus Kessler <Magnus.Kessler@gmx.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47418
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Vincent Untz <vuntz@gnome.org>
Reported-by: Robert Bradford <robert.bradford@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48045
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the maximum thread count and urb size differs between different
incarnations of the GT units, be a little more flexible in programming
those maximums.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we may hold a cached reference to an upload buffer whilst it is
in-flight, the assertion that there are no such references to a buffer
being reused is no longer true. Those cached references will be released
as soon as we retire the buffer during the readback and so we are free
to reuse such an upload buffer for immediate readback.
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>
Same change for intel_display.c and sna_display.c.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we lack the ability to use a shader to compute the gradients
per-pixel, we need to use pixman to render a fallback texture. We can
reduce the size of this texture and upsample to reduce the cost with
hopefully imperceptible loss of quality.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It was broken and not flushing damage correctly. With the
improvements made to the kernel, it is no longer a significant advantage
per se and not worth its additional complexity.
Reported-by: Tilman Sauerbeck <tilman@code-monkey.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32547
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Another case where I passed an empty string believing that would be
sufficient to replace the error path...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
With xterm, it is quite common for it to redraw itself by using lots of
spaces and so it is efficient for us if we ellide those clear glyphs and
only draw the backing boxes. However, we were only checking the first 8
pixels in each line because of a missing pointer increment.
Fixes absent '=' characters when using a compositor and ImageText.
Reported-by: Jiri Slaby <jirislaby@gmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47735
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since the removal of the ability to create a backing pixmap after the
creation of its parent, it no longer becomes practical to attempt
rendering with the GPU to unattached pixmaps. So having made the
decision never to render to that pixmap, perform the test explicitly
along the render paths.
This fixes a segmentation fault introduced in 8a303f195 (sna: Remove
existing damage before overwriting with a composite op) which assumed
the existence of a backing pixmap along a render path.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47700
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Double check that the maximum access size computed from the bo
parameters is within the allocated size for the bo.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The danger now is that we may have either discarded the shadow pixels or
have replaced them with a GTT mapping, either way undesirable and so we
should reconstruct the shadow mapping.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the font is kept around and reused after UnrealizeFont, we need to
nullify the pointer to our private data in order to prevent the later
use-after-free.
Reported-by: Peter Jordan
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we only enter that path for singular unbounded boxes, we are
guaranteed to fill the entire trapezoid extents and so do not need the
unbounded fixup the assertion was fretting about.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to do this apparently or else we never perform the VT switch.
However, we can not do it too early, especially not before we have
finished intialising the outputs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47395
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Eugeni Dodonov
Paulo Zanoni