The bo may be considered unmappable due to being bound to outside the
mappable region, which we are attempting to rectify through mapping into
the GTT domain.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the fast paths only setup state upfront, we were missing the state
changes required between dash-on/off. Take advantage of that each pixel
is only drawn once to batch the state changes and run the
miZeroDashLines twice.
A future task would be to use a custom line drawing routine...
Fixes regression from ec1267df74.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For a vmapped upload buffer, we need to notify the kernel (and thereby
the GPU) to invalidate the sampler and flush its caches when we reuse an
idle buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to use the full 32-bits of mmap address space on small
platforms we need to use mmap64().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
sna_accel.c: In function 'sna_pixmap_move_area_to_gpu':
sna_accel.c:1751:12: warning: declaration of 'flags' shadows a parameter
[-Wshadow]
sna_accel.c:1731:72: warning: shadowed declaration is here [-Wshadow]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
And mark it as currently in no domain afterwards, so that if we reuse
it, it will be appropriately moved later.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
To avoid accumulating the write offset for wide spans, we need to reset
the destination pointer between spans.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48332
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In particular the glyph routines require the composite setup to
reinitialise state between glyph runs. This affects anything trying to
use glyphs without a mask with a gradient source, for example.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
Chris Wilson