As we know that such operations are likely to be slow and consume
precious GTT space, mark them as candidates for flushing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Under ZaphodHeads we end up with multple screens accessing the common
sna_glyph_key and so cause conflicting updates and erroneous references
into the screen-local texture atlases.
Two approaches can be tried here. Transition to a screen-specific
private key introduced with xorg-1.13, or to move the glyph cache (and
the rest of the gpu state tracker) down into the device private rather
than screen private. This is neither of those, but a workaround to avoid
reusing the incorrect entries from shared screens.
Reported-by: Stephen Liang <inteldriver@angrywalls.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54707
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the possible_crtcs is a bitmask of the available crtcs exposed to the
Xserver, we need to adjust it for the limited view given by Zaphod mode.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
Chris Wilson
Imre Deak