If we fail to allocate an alternate bo to replace the still visible
scanout bo, we stall and were supposed to continue using the old
wait->bo. However, we chose to use NULL instead which is going to lead
to an eventual crash.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We occasionally will read from an "incoherent" ptr in the belief that
the clflush hit will be worth it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We can read from the current scanout buffer without incurring a visual
tear, so delay the GPU bo exchange until we see a write to the object.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If there are more processors than we ever expect, good! Just use lots of
them, rather than none at all.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the failure in gc move-to-cpu occurs late, i.e. after the function
pointers are updated to point to CPU functions, we need to undo those
changes, i.e. call move-to-gpu for the GC on failure.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we fail to mmap the pixmap when preparing it for use with prime, be
sure to throw away the now lost priv->gpu_bo.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Defer the actual wait until the next use of the screen pixmap, and then
if needed replace the GPU bo with an alternative back buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When trying to conserve power, reduce the number of small batches we
emit - trying to maximise GPU efficacy and minimise CPU overhead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the kernel does not preserve the name and driver type when returning
the current CRTC mode, we need to reconstruct those from the EDID mode
when available.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Whenever we reprobe an unchanging output and re-read its EDID, we emit a
useless log message. Previously this was squelched by trying to spot
when an EDID was unchanged through the use of its blob.id, however we
need to do a complete check on the contents in case the kernel returns
us a new EDID with the old id. So make a temporary copy of the current
EDID data and only squelch the log messages if the new EDID is an exact
match.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to add the current mode to the Modes list and not directly to
the output->probed_modes as that gets overwritten.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the unmap routine will deference the GPu bo in its debugging code, we
need to be sure that the pointer is still valid at the time of
unmapping. Hence unmap before release.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=70461
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We no longer unconditionally clear the CPU hint when moving to the GPU
for readonly updates, so we can no longer assert that the priv->cpu ==
false afterwards.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to also take account of upload buffers which include an offset
to the base map. To do so, we also need to stop conflating the cpu hint
with the current mapping flag.
References: https://bugs.freedesktop.org/show_bug.cgi?id=70461
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It didn't consider the height of the glyph above the baseline, i.e. it
was fundamentally flawed. The only thing to do is to make sure that
glyph_extents() is sufficiently fast never to show up in profiles.
(Until then QA should spot the ~10% regression.) An alternative would be
to feed the drawable clip extents to the render engine and avoid manual
clipping if the clip region covers the whole drawable.
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Reported-by: Jiri Slaby <jirislaby@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70552
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
And make sure we consider such overflowing strings for correct clipping
against Windows.
To offset the cost of doing a full extents check (~10% on aa10text), we
introduce an approximate extents query (~1% on aa10text). The disparity
should be rare, and should be an overestimate to force redundant
clipping.
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70541
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Pavel Roskin found that with a 32-bit build of the DDX with a 64-bit
kernel that the call to GETCONNECTOR was overwriting the 4 bytes beyond
the end of the drm_mode_get_connector structure. This would appear to be
due to the surreptious padding inserted by the compiler so that the
structure would be naturally aligned on a 64-bit system. To compenstate
we need to insert padding between the adjacent 32-bit structures on the
stack.
As usual, be paranoid and make sure that all the adjacent KMS structs we
use are padded out to an 64-bit boundary.
Reported-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit 41b6b792d8 in favour
of the better fix to not ask RRChangeOutputProperty to reset the known
hardware values.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When we assign the hardware values to the output properties, we do not
need to process the set_property callback to write those values back to
hardware. This callback is triggered by the pending update flag passed
to RRChangeOutputProperty.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70406
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When querying the current backlight value, be sure not to overwrite the
last user set value by the call to RRChangeOutputProperty.
RRChangeOutputProperty calls into set_backlight_property, tricking us
into believing that the user has set a new backlight value. The result
is that we end up believing that the user chooses a 0 backlight if she
should happen to query the property whilst the output is disabled.
Reported-by: reztho@archlinux.us
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70406
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Remember to set it initially to false so that we randomly do not start
using fallbacks.
Fixes regression from
commit 0cd2c43fa8
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sun Oct 13 14:46:45 2013 +0100
sna/trapezoids: Use the aligned fast path for fallbacks
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we use the current ring to encode upon the bo relocs, we need that
ring to be properly setup prior to performing relocations.
References: https://bugs.freedesktop.org/show_bug.cgi?id=70461
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson