When swapping over the names, we also need to swap the pitches exposed
through the protocol as well.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Even if we cannot render using the GPU, we should still be able to
request that the outputs be flipped. So try, and only if that fails,
resort to writing directly into the scanout.
References: https://bugs.freedesktop.org/show_bug.cgi?id=85058
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we fail to flip onto a new per-CRTC bo, first try a normal modeset.
This catches instances where the pitch changes for example.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we find the GPU is wedged, replace some of the lowlevel render
operations with CPU equivalents to simplify some fallbacks that still
need to operate on GPU bo (such as copying DRI buffers).
References: https://bugs.freedesktop.org/show_bug.cgi?id=85058
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we fail an execbuffer, we disable outputs and try again. (In case we
have severe fragmentation issues and need to rearrange the scanouts in
GTT.) Afterwards we re-enable the outputs, but this causes us to flush
the pending rendering and so recurse into the execbuffer. Prevent this
with a slight hack during enabling of outputs.
References: https://bugs.freedesktop.org/show_bug.cgi?id=85058
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As libudev only pulls off events one by one and we may need to process
several for a MST topology change, keep polling until complete.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Jan spotted that we open the bl_power file using O_RDONLY and then attempt
to write the new power state into it. This fails...
Reported-by: Jan Steffens
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Beware the barbarians at the gate, who invade and steal your ScrnInfoPtr
and its Entity from underneath you. In some configurations, we lose
access to the struct intel_device stored on the Entity after
initialisation, causing havoc. Workaround this by storing the
intel_device that we open in our driverPrivate.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
From the last commit c481254c17,
we need to pass along the private pointer as the flip data as we no
longer pass it down from the caller.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When using ZaphodHeads, we share the /dev/dri/card0 fd between both
screens. So when we read an event back from the fd, it could be for
either head and we cannot assume that our private pointer is valid for
the data passed along with the event. Instead, we need to retreive that
pointer from the event.
Fixes regression from
commit 8369166349 [2.99.912]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Jun 4 08:29:51 2014 +0100
sna/dri2: Enable immediate buffer exchanges
although the design bug is actually older.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84744#c15
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the ddx is configured without udev support, we do not receive
notifications when the MST topology is changed. This leads us to query
the kernel for bad connectors, and so we end up reporting an unknown
connection status for them, which the user and client often find
confusing. However, we can not simply act upon the detection failure as
we are too deep inside the callback chain and cannot change the arrays of
known connectors whilst iterating over them. A neat compromise is to
hook into the rrGetInfo call chain and poll for MST changes before we
report back the current configuration.
References: https://bugs.freedesktop.org/show_bug.cgi?id=84718
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The variable changed meaning, but the assert did not. Fix that up.
Reported-by: Matti Hämäläinen <ccr@tnsp.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we attempt to share an unused Pixmap, we first create an ordinary GPU
bo when migrating onto the GPU. Add a flag here to cause the migration
to create a Pixmap suitable for PRIME instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to sample at the mid-point of each subrow rather than at the
top and preserve the full precision of the edge gradients.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we are using a CRTC source pixmap, it is possible that it is on the
CPU with a GPU bo and so requires flushing prior to the copy.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Odd as it may seem, but we can end up attempting to copy from a source
CRTC pixmap that is not on the GPU. Here we need to use the heavyweight
path to handle its composition normally.
Reported-by: Christoph Haag <haagch@frickel.club>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84653
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In a couple of cases we can re-enable CRTC. After doing so we should
recompute the minimum vblank interval.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the Xorg does not support the ReuseNotify callback, and we use
double-bufferred pageflips, we set the stale flag on the backbuffer but
never clear it. This results in, for example, a compositor with Xorg-1.15
and Prime active from updating the framebuffer.
Reported-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Preserve the original precision for the line vectors of the trapezoids,
and leave the final projection onto the x-cell until last.
Finishes accidental wip commit in 8aff3898c3.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In the early move-to-gpu in ScreenCreateResources we purposefully ignore
any errors from the move-to-gpu as they will be fixed up later when we
try to bind to the CRTCs. Mark it as ignored for future readers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Whilst it is unlikely that we do have any damage queued to the
frontbuffer prior to the copy, it is safer to use the migration tracking
machinery rather than guess.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Currently we only refer to "off" to disable the acceleration, but "none"
is probably more familar to users of other drivers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Before we attach the Screen Pixmap to the scanout, we will have to
create a GPU bo and apply any fixups as required. Therefore failing to
pre-emptively move it during ScreenCreateResource is not fatal and the
failure can be simply ignored.
Suggested-by: Egbert Eich <eich@freedesktop.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
From kernel commit 72bbf0af0c76cbefe9cecbd2ed670b7555e03625
Author: Damien Lespiau <damien.lespiau@intel.com>
Date: Wed Feb 13 15:27:37 2013 +0000
drm/i915/skl: Add the Skylake PCI ids
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As a final precaution, fixup the pitch on the bo to be used for
scanout by switching the bo on the Pixmap for a new correctly aligned
scanout bo.
Reported-by: Egbert Eich <eich@suse.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When converting a linear cached CPU bo into an uncached GPU bo, we must
be careful to adhere to the scanout restrictions if they apply for this
transfer or this Pixmap.
Reported-by: Egbert Eich <eich@suse.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This should mask driver bugs whereby we ask the kernel to make a
framebuffer out of an improper bo.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Invalid negative offsets could slip into the drawing rectangle
without triggering the assertion - the assertion being that they were
not greater than the maximum positive coordinate of the 3d engine.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If ZaphodHeads is active, each screen only has a subset of the CRTC
assigned to it, in fact just the single CRTC associated with the pipe of
that screen. In that case, we only expect to have the single CRTC and so
should not assert that we have a list of all CRTCS.
It should still hold that we dynamically attach ZaphodHeads upon
hotplugging, so it is just the assert that is overzealous.
Reported-by: Nick Bowler <nbowler@draconx.ca>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84281
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Where possible, keep the offset of the partial Picture within the 3D
coordinate limit so that we can use the DrawRectangle offset to
automatically adjust the coordinates.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than alternating between a pair of fb each time, we can reuse the
last shadow buffer so long as it remains the right size.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
And undo the accidental commit of
commit 4e00cbe35d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Sep 22 08:54:57 2014 +0100
traps
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In sna_pixmap_alloc_gpu() a different than the default tiling may be picked
by a usage hint. Before passing the tiling to kgem_create_2d() fix it up
by calling kgem_choose_tiling(). This avoids kgem_surface_size() not being able
to find a surface size for the tiling value.
Fixes regression from
commit a10781b70f [2.99.913]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Jul 1 15:11:07 2014 +0100
sna: Enforce LinearFramebuffer option
Signed-off-by: Egbert Eich <eich@freedesktop.org>
When we create the shadow pixmap for the CRTC, we should copy the
framebuffer contents into the shadow before we show it the first time.
This saves us from showing stale contents until the next redrawn in the
BlockHandler - with the proviso that we can do the copy on the GPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Rodrigo Vivi
Egbert Eich
tobias.jakobi1@uni-bielefeld.de