Age | Commit message (Collapse) | Author |
|
Reported-by: Nick Bowler <nbowler@draconx.ca>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54561
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
References: https://bugs.freedesktop.org/show_bug.cgi?id=54561
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This reverts commit ad57ac07a273bf376b74884de47d8ee1e7129fb8.
These checks end up being too frequent and not allowing us to batch
sufficient commands to offset the overhead of batch submission. Hmm.
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
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>
|
|
Fixes regression from commit 38fb77af757318e5fb6f605b37306ce4585b11a5
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Sep 5 08:23:34 2012 +0100
sna: Don't upload ignored cpu damage
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As Imre Deak pointed out in the previous patch, drmModeRmFB only works
when we hold the DRM master, therefore to prevent a leak of the
framebuffer across server reset we need to defer dropping master until
after we release our scanouts and modes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Calling drmModeRmFB is only allowed in DRM master mode. Since leaving
the VT also drops master mode we need to remove the FB before calling
I830LeaveVT.
This is only a real leak in case of a server reset, otherwise the server
process will exit anyway and the kernel will clean up the FB.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
So that we can use the same teardown path as normal scanouts.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Reported-by: Reinhard Karcher <reinhard.karcher@gmx.net>
References: https://bugs.freedesktop.org/show_bug.cgi?id=54488
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Experiment with pushing those first commands earlier.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
In particular, don't forget to flush when we only have offload slaves
and no native pixmaps.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
s/achieve/retrieve/ otherwise it is nonsense.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The DRI2 code tries to create pixmaps with non-zero width/height,
whoops.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Preliminary prime support.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Completing commit 0768ac4d195214825137152893deb74a87fcd11e
Author: Dave Airlie <airlied@redhat.com>
Date: Wed Jul 25 16:11:23 2012 +1000
intel: add platform probing support.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Сковорода Никита Андреевич <chalkerx@gmail.com>
|
|
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54134
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Probably never gets hit but shuold return FALSE,
pointed out on irc by Lekensteyn
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This queries the kernel for prime support before advertising
the capabilities.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This adds support for pixmap tracking and scanout of
alternate pixmaps.
v2: do dirty updates after uxa block handler, check if kernel
can flush vmap for us so we don't have to.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This allows the driver to be loaded by the platform loading code.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If the hw/kernel doesn't support snoopable buffers, then it makes little
sense to search for one, and force a retire in the certainty of not
finding any.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If we have a CPU bo, consider if it may be quicker to render to it then
create a GPU bo.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The issue being that, due to the delay, the chained swap would miss its
intended vblank and so cause an unwanted reduction in frame throughput
and increase output latency even further. Since both client and server
have other rate-limiting processes in place, we can forgo the stall here
and still keep the clients in check.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54274
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As we may defer the actual release of the pixmap until after completion
of the last shm operation, we need to make sure in that case we mark the
GPU bo as released to prevent a use-after-free.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Only the later gen had these useful assertions, add them to the rest
just in case.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Otherwise we end up considering the GPU bo as a real target, causing
confusion and failed asserts.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Fixes regression from
commit 96a921487ef00db03a12bec7b0821410d6b74c31
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Aug 27 21:50:32 2012 +0100
sna: Track outstanding requests per-ring
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As we now may not prefer to use the GPU even if all-damaged and clear,
asserting that if we choose to use the CPU if clear is now bogus.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If we write to the same page as it already active on the GPU then
despite the invalidation performed at the beginning of each batch, we do
not seem to correctly sample the new data.
References: https://bugs.freedesktop.org/show_bug.cgi?id=51422
References: https://bugs.freedesktop.org/show_bug.cgi?id=52299
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The subtly is that we need to reset the mode correctly after
submitting the batch which was not handled by kgem_flush(). If we fail
to set the appropriate mode then the next operation will be on a random
ring, which can prove fatal with SandyBridge+.
Reported-by: Reinis Danne <reinis.danne@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
In order to properly track when the GPU is idle, we need to account for
the completion order that may differ on architectures like SandyBridge
with multiple mostly independent rings.
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54127
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As the code will optimistically convert a request for a GTT mapping into
a CPU mapping if the object is still in the CPU domain, we need to
overrule that in this case where we explicitly want to write directly
into the GTT and furthermore keep the buffer around in an upload cache.
References: https://bugs.freedesktop.org/show_bug.cgi?id=51422
References: https://bugs.freedesktop.org/show_bug.cgi?id=52299
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As we will stall in the near future to serialise access with the
ShmPixmap, we may as well stall first and do a simple copy using the
CPU in this highly unlikely scenario.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|