Since the naive implementation uses an 8bit temporary, we can only
support so many passes before the quantization artefacts become
apparent. We have to be extra conservation in order to support
multi-pass convolution algorithms (notable 2-pass separable Gaussian
kernels).
References: https://bugs.freedesktop.org/show_bug.cgi?id=95091
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Mesa wants to pass Y-tiled framebuffers onto scanout. Admittedly, this
isn't quite that but it does prevent them being jumbled up.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we now do more syscalls after the setcrtc, we cannot rely on errno
storing the pertinent error code. Instead we have to save it immediately
after the drmIoctl() and propagate that back.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the first choice of orientation and tiling may be invalid, e.g.
left/right rotation on Skylake, we need to force the second pass here to
try and an alternate non-native rotation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Avoid postponing until the next vblank to avoid continually recursing
every TearFree update, and to minimise the presentation delay.
References: https://bugs.freedesktop.org/show_bug.cgi?id=94982
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Temporarily stopping the pointer whilst we try to queue the flip should
help keep the output latency down.
Reported-by: Rafael Ristovski <rafael.ristovski@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=94980
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to actually stall the pipeline completely and to wait for
earlier flushes to complete, we have to set a flag in the pipecontrol.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Increment the target_msc by one, not the last known msc!
Reported-by: Rafael Ristovski <rafael.ristovski@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When doing the misaligned copy from the start of the dst pointer, the
important check is whether there is enough bytes remaining to the next
alignment position, next from the last.
References: https://bugs.freedesktop.org/show_bug.cgi?id=94928
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
So that when we size from transformed cursors to non-transformed, we
remember to clear the entire area.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When draining the flipqueue for TearFree, we may recurse from the vblank
handlers. Avoid this by delaying the Present vblank until next frame.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Kick the error back to the upper layer for it to sort out.
Reported-by: Timo Aaltonen <tjaalton@ubuntu.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we have to fake a vblank because the CRTC is off and we compute the
delay as being 0, then we would report the event immediately - but with
the earlier msc. Instead, we want to report the completion.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Each GT on Skylake is bigger than previous generations. For reusing the
placement logic, we then want to pretend that Skylake has a higher
GT-equivalence.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We should be consistent in making the code simpler for the compiler and
so not rely on it eliminating the dead-code for a single loop of
sse64xN!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Don't bake in the assumption that the CRTCs will always be allocated in
the low byte of the identifiers range. It is only used in a pair of
other functions (Xv plane updates), so not a big deal.
Reported-by: Mark Kettenis <kettenis@openbsd.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Timers can only be set for a maximum of int32_t milliseconds into the
future. Respect that - if we need more, we'll just requeue!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We store a flag on the vblank's CRTC to indicate whether we have marked
the target CRTC as having an immediately pending vblank. We should clear
this set of flags early so that we don't have to worry about the flag
whilst processing the vblank, and so that we don't get confused if we
have to requeue the vblank.
Reported-by: Christoph Haag <haagch@frickel.club>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94829#c32
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After fixing the 32bit build (sigh), testing out the manual unwinding of
the sse2 memcpy doesn't look worthwhile (at least on pnv). So leave it
off for 32bit builds.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Trying to unify all the target attributes to chase down:
blt.c: In function ‘memcpy_from_tiled_x__swizzle_0__sse2’:
blt.c:345:1: error: inlining failed in call to always_inline
‘memcpy_sse64xN’: target specific option mismatch
memcpy_sse64xN(uint8_t *dst, const uint8_t *src, int bytes)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For delays over a frame, we aim to fire a frame early and so
compensating again for less than a whole frame is irrelevant.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than queuing vblanks for future events up to 4000 years and
setting the hardware to stay awake for all that period (reporting a tick
every refresh), use the timer for the first part. (The timer should
allow a precise-(ish) single wakeup of the hardware.) We set the timer a
frame ahead, so that we can then queue an actual hw event for the final
vblank for precision.
References: https://bugs.freedesktop.org/show_bug.cgi?id=94829
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the screen is already scanning out from the desired framebuffer
(because we failed when flipping and already restored the mode), skip
the unflip.
References: https://bugs.freedesktop.org/show_bug.cgi?id=94829
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we wake up early from the timer, we can use the hw to give us a more
precise wakeup for the vblank (rather than estimating to the approximate
millisecond).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since commit 02f535e8f3
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Mar 24 09:39:06 2016 +0000
sna/present: Requeue early vblank completions
we may hit the fake vblank timer path with an old hw struct that may have
multiple associated events. The assert that we only called the fake
vblank from sna_present_queue_vblank is no longer correct.
Reported-by: Christoph Haag <haagch@frickel.club>
References: https://bugs.freedesktop.org/show_bug.cgi?id=94829#c15
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After doing a blocking wait (rather than event driven) for the imminent
arrival of the next frame (when it is expected less than 1ms in the
future), update the timestamp and frame counter that we then report back
to present.
Reported-by: Christoph Haag <haagch@frickel.club>
References: https://bugs.freedesktop.org/show_bug.cgi?id=94829#c15
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Don't forget that along the vblank path, we may use a timer instead of
the hw event in which case, we don't actually count the info as queued
(to hardware)
Reported-by: Christoph Haag <haagch@frickel.club>
References: https://bugs.freedesktop.org/show_bug.cgi?id=94829#c13
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we cancel a flip, we may try to restore the current mode and this may
flush the partial flip (in a multi-monitor setup). We report the completed
event back to present and free the event info. Then we report the error
back to present, and free the event info a second time. Chaos and
corruption ensues.
Reported-and-tested-by: Christoph Haag <haagch@frickel.club>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94829
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Telling the compiler the known alignment should improve the memcpy
operation, but only has a small impact today (a few bytes/instructions
per function).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The actual disablement doesn't take place until the next modeset, and
until then we are likely to keep spamming the error message.
References: https://bugs.freedesktop.org/show_bug.cgi?id=94806
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since Haswell, we lost the ability to use hardware scalers on the
overlay planes. Allow Xv clients to pass in unscaled data and use the 3D
pipe to prescale the images before display.
(I doubt I have the rotations corrected!...)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson