Fixes regression from
commit e3f15cbf39 [2.99.905]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Oct 22 15:19:15 2013 +0100
sna: Move gc back to GPU after failure to move it to CPU
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Expunge our caches if we fail to write into a bo (presuming that
allocation failure is the likely fixable cause).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After computing the clip intersection, we immediately check for the
empty result, so refactor the check into the common routine.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For consistency with the other aperture metrics and correctness when
passing around required number of pages.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we get a pageflip fail when trying to do a TearFree update, just
fallback to a copy (before turning off the display for complete
failure). The rare tearing copy should mar the user experience far less.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This will overcount buffers that both fenced and unfenced (likely most
fenced buffers!) but is required to prevent ENOSPC due to alignment
issues.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
kgem_check_bo_fenced queries whether the GPU is idle, and so its result
is timing dependent and not suitable for assertion.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes a regression introduced in
commit 4d2840919f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Sep 26 15:30:58 2013 +0100
sna: In desperation, query the actual available aperture space
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
DamageRegionAppend() will itself apply the drawable offsets, so we need
to pass it the untransformed region. This also fixes an issue where we
might fallback without applying any Damage.
Reported-by: Christian Nassau <nassau@nullhomotopie.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32734
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Whoops. Only the kernel sprintf() accepts NULL as a valid target string,
not libc's.
Reported-by: Jay Little <jaylittle@jaylittle.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70835
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Otherwise we may not correctly undo COW or pending move-to-gpu updates.
v2: goto move_to_gpu instead for correcting the damage handling.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70821
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
Chris Wilson