We still encounter hangs with kernel-3.5 with the culprit being a wait
on a disabled pipe. As we thoroughly check before that the pipe is still
disabled and flush before a modeset, the only possibility that remains
is that DPMS is disabling the pipe before we submit. Close that race by
always submitting the batch immediately after a WAIT_FOR_EVENT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Prevent the leak and remove some unsightly code in the process.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The compat header takes care of the old server vs new server.
this commit was autogenerated from util/modular/x-driver-screen-scrn-conv.sh
Signed-off-by: Dave Airlie <airlied@redhat.com>
Be paranoid and check that we own the VT before emitting a scanline
wait. If we attempt to wait on a fb/pipe that we do not own, we may
issue an illegal command and cause a lockup.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We have yet to implement a yuv-shader that applies
contrast/brightness/saturation and so should not advertise such
features, potentially allowing the client to fallback and perform the
adjustments itself.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Now, the pixmap being used is meant to the Screen pixmap and by rights
that has to exists in a GPU buffer! Evidence contrary to the above
exists and so we had better check that we have a bo before using...
Reported-by: Toralf Förster <toralf.foerster@gmx.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40439
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to avoid video lag and jerky playback we need to ensure that
any queued video is flushed before we go to sleep.
Fixes regression from 6f104189bb.
Reported-and-tested-by: Edward Sheldrake <ejsheldrake@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37068
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit d2106384be.
Breaks compiz (but not mutter/gnome-shell) on gen6. Not sure if this is
not seem deep interaction issue with multiple clients sharing the GPU or
just with compiz, but for now we have to revert and suffer the inane
performance hit. It looks suspiciously like another deferred damage
issue...
Bugzilla: 51a27e88b073cff229fff4362cb6ac22835c4044
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We have seen GPU hangs with:
batchbuffer at 0x0f9b4000:
0x0f9b4000: 0x09000000: MI_LOAD_SCAN_LINES_INCL
0x0f9b4004: 0x00000300: dword 1
0x0f9b4008: 0x09000000: MI_LOAD_SCAN_LINES_INCL
0x0f9b400c: 0x00000300: dword 1
0x0f9b4010: 0x01820000: MI_WAIT_FOR_EVENT
0x0f9b4014: HEAD 0x02000006: MI_FLUSH
on a 1366x768 display. That according to the specs an invalid command
for the pipe.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35576
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
scrn->currentMode is a hack for xf86vidmode and in general is wrong for
RANDRful drivers. Use the mode on the associated CRTC instead.
Signed-off-by: Adam Jackson <ajax@redhat.com>
[ickle: crtc->mode is a ModeRec]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The acceleration code does not yet exist, so we try to use gen4 shaders
which hangs the chip and makes everybody upset. Disable it until such a
time as support is written for Sandybridge XVideo.
Reported-by: Matthias Hopf <mhopf@suse.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30500
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
An attempt to workaround the incoherency in gen2 chipsets, we avoid
using dynamic reallocation as much as possible.
The first step is to disable allocation of pixmaps using GEM and simply
create them in system memory without a backing buffer object. This
forces all rendering to use S/W fallbacks.
The second step is to allocate a shadow front buffer and assign that to
the Screen pixmap. This ensure that the front buffer remains in the GTT
and pinned for scanout. The shadow buffer will be rendered to in the
normal fashion via the Screen pixmap, and be marked dirty. In the block
handler, the dirty shadow buffer is then blitted (using the GPU) over
the front buffer. This should completely avoid having to move pages
around in the GTT and avoid incurring the wrath of those early chipsets.
Secondly, performance should be reasonable as we avoid the ping-pong
caused by the small aperture and weak GPU forcing software fallbacks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
And fixup all the drmmode_* functions to have an intel prefix and
categorise those into intel_mode, intel_crtc, intel_output and
intel_property so that the functions are a little more self-descriptive
and, more importantly, are consistent.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson likes to sprinkle these all over, but in this
case it's just misleading. libdrm already does this for us.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The kernel overlay code does asynchronous overlay flips. So keep
onto two old buffers, for otherwise the rendering of the next
frame might overwrite the contents of the currently still displaying
one. With ~25fps videos and ~50 Hz screens that's rather unlikely,
still, fix it.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
After passing the new buffer to the kernel, the old buffer is unpinned
and becomes available for re-use. So keep hold of the old buffer and
swap after a PutImage. This greatly reduces the amount of CPU time
consumed by the kernel on behalf of the video overlay -- by only
allocating two buffers for an entire sequence, we avoid clflushing and
page allocation on every frame.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we use the static DummyEncoding and may attempt to modify it for each
adaptor (on each device), we should use copies instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The dri code is much more careful in ensuring that the scan lines that
is waits for are valid. Copy this code to video, with a bit of work this
can be refactored, and perhaps even teach dri how to handle rotated
front buffers.
References:
Bug 28964 - [i965gm] GPU infinite MI_WAIT_FOR_EVENT while watching video
in Totem
https://bugs.freedesktop.org/show_bug.cgi?id=28964
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After splitting out the i810 driver into its own legacy directory, we
can identify the common routines not as i830 but as intel. This
clarifies the code which *is* i830 specific.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Dave Airlie
Dave Airlie
Xiang, Haihao
Adam Jackson
Krzysztof Halasa
Matt Turner
Daniel Vetter