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>
With a rotated output and shadow buffers, we never perform the flip in
the first place and so can ignore the unflip request as well.
Reported-by: Mihail Kasadjikov <hamer.mk@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=84105
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Mark the stub intel_glamor_fd_from_pixmap() as inline to silence the
compiler warnings about unused function definitions.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The trick is to make sure we consider the CapLast setting in the
direction the line is being drawn and adjust the inked pixels
accordingly.
Testcase: DrawSegments/hv0
Reported-by: Russell King
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we have unfortunate fragmentation, e.g. a cursor is pinned in the
middle of an aperture, we can struggle to fit large objects, especially
fenced objects on gen2/gen3. We do have one last trick up our sleeves
that we can try: disable all of the outputs and cursors and try
submitting the batch in as pristine an aperture as we can arrange. We
can only hope that the subsequent restoration of the outputs is more
conducive to future batches (and so not lead us into continual flicker).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In case we have a hotplug at just the wrong time, we can fail a modeset
with a stale connector. Before attempting to recover, probe the kernel
for the current state.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to fix the build without DRI3, we need to stub out the
functions not compiled in, such as intel_sync_fini().
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Check that we have the required Xorg headers for glamor if the user
requests --enable-glamor. There is a possiblity that the headers
mismatch as they don't have internal versioning, but this should catch
the majority of errors early on.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
glamor_pixmap_from_fd and glamor_fd_from_pixmap were added before
version 1.15.99.902, so check for that version before trying to use them.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Fabio Pedretti <fabio.ped@libero.it>
Instead of always including intel_uxa.h from intel.h, and including
uxa.h from some files directly, use intel_uxa.h directly from .c files
that have UXA-specific code in them.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
There aren't any symbols from uxa.h used in this file, remove the #include.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This makes the UXA-specific elements of intel_screen_private and a bit
of code in intel_driver covered under #if USE_UXA
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
intel_flush flushes any pending acceleration operations to the
hardware, just like intel_uxa_batch_submit does today except that it is
not uxa-specific.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This starts to separate uxa from the rest of the driver by renaming
uxa-specific functions and structs to make it clear which portions of
the driver are uxa-specific and which are common.
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Eric Anholt <eric@anholt.net>
UXA and Glamor both share this function, so move it out of the UXA file.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Chris Wilson
Egbert Eich
tobias.jakobi1@uni-bielefeld.de
Keith Packard