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>
Sync with kernel commit 7157bb27e79875db5603aa1e30f56e873a8300f9
Author: Michał Winiarski <michal.winiarski@intel.com>
Date: Fri Feb 5 13:21:42 2016 +0100
drm/i915/skl: Add missing SKL ids
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When we fail to do a modeset, we need to make sure that we restore the
previous bo in the event that it's changed. Otherwise we'll crash the X
server the next time we do a pageflip.
This fixes an issue with panning crashing the X server if a user tries
to set a large panning resolution such as 5200x3200, and the GPU doesn't
have enough memory to handle the bo due to being in UXA mode.
Signed-off-by: Lyude <cpaul@redhat.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
The kernel checks for past vblanks using an int32_t comparison, so we
can only program up to 31bits into the future (and similarly programing
a timer that large would also overflow).
References: https://bugs.freedesktop.org/show_bug.cgi?id=94685
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit e4e469a0ed.
It looks like we get to choose between breaking the clang build or the
gcc build. With gcc, we need to ensure that enter xorg/os.h with the
right set of HAVE_STRNDUP et al guards, e.g.
In file included from /usr/include/string.h:630:0,
from /usr/include/xorg/os.h:53,
from /usr/include/xorg/misc.h:116,
from fd.c:34:
/usr/include/xorg/os.h:590:1: error: expected identifier or '(' before '__extension__'
strndup(const char *str, size_t n);
Reported-by: Arkadiusz Miskiewicz <arekm@maven.pl>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Oops, copy'n'paste broke the non-Present build:
sna_trapezoids_boxes.c:(.text+0x0): multiple definition of
`sna_present_cancel_flip'
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Still not working right, remove it to keep the standard build working.
Sorry if you have been relying on ACLOCAL_FLAGS.
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
There's no point in testing for functions we don't use and seem to cause
problems for Clang.
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the vblank completes too early (e.g. due to a modeset), try
requeueing it so that it fires at the expected time (and so after the
modeset).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we cannot queue a vblank further than 1<<32 into the future, nor can
we set a Timer to expire that far into the future, creating such a
vblank event is futile. Report BadValue and hope for the best.
References: https://bugs.freedesktop.org/show_bug.cgi?id=94515
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Just in case we haven't otherwise flushed and invalidated the scanout
prior to loosing control of the output.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Given Present bugs, any completion event may be sent too early and
out-of-order. Make sure we drain all outstanding events before
continuing on to the next test.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Lyude