If the outputs are resized very early on, in CreateScreenResources, then
we will not yet have created a RootWindow and so trying to change its
pixmap is a futile effort.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In case we should be creating an untiled framebuffer, we need to make
sure we honour the scanout alignment.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
So that we can allow prime to replace the backing bo of currently
exported pixmaps through DRI2.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This allows us to replace the prime bo to meet sharing requirements, but
still maintain the integrity with other users.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order for nvidia to handle the buffers we are currently generating,
they need to have a pitch alignment of 256 bytes. Make it so.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit ad57ac07a2.
These checks end up being too frequent and not allowing us to batch
sufficient commands to offset the overhead of batch submission. Hmm.
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 38fb77af75
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>
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>
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>
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>
Chris Wilson
Imre Deak
Сковорода Никита Андреевич
Dave Airlie
Dave Airlie