Age | Commit message (Collapse) | Author |
|
When the trapezoid is rendering to a surface larger than the 3D pipe can
handle, we split it into tiles. However, the code to do so insisted on
passing along the wrong pointer and consequently crashed.
Based on the patch by Carl Michal.
Reported-by: Carl Michal <michal@physics.ubc.ca>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90940
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
One day, we will move the width/height/bpp to the bo itself...
Reported-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
commit 534a0e6433a37c95f7181f7ce9046a4e7c82532d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Apr 28 07:53:13 2014 +0100
sna: Factor in destination sizes for choosing intermediate tiling bo size
assumed that the target bo was being initialisation for the tiling
composite; it was not.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
When tiling, factor in the destination usage of the aperture in case
that reduces the available aperture for the intermediate bo.
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>
|
|
Composite operations were presumed to cover their entire width x height
area. However, a few paths submit boxes that do not cover the clip
region and so the optimisation made during prepare to discard completely
overwritten data is incorrect (and leads to corruption - stale data is
seen which the client expected to have been overdrawn). So along these
more unusual paths, we must add a flag to prevent the overzealous
discard. Notably, xfce4 triggers this as it uses a lot of unantialiased
trapezoids in its theme drawing.
References: https://bugs.freedesktop.org/show_bug.cgi?id=69528
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The first step when tiling with an intermediatory is to copy from the
source bo to the temporary. The alu should only be applied when copying
from the temporary to the destination.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We have to rely on the caller only calling us for a PictOpSrc equivalent
operation as they don't all set op->op.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This avoid a circuituous route through the render pathways and multiple
levels of tiling fallbacks to accomplish the same copy.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
On the older generation, we have severe alignment penalties for fenced
regions which dramatically reduce the amount of space we can effectively
use in a batch. To accommodate this, reduce the tiling step size.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The older generations have stricter requirements for alignment of fenced
GPU surfaces, so accommodate this by reducing our estimate available
space for the temporary tile.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Following a complex path through multiple layers of indirections and
tiling fallbacks, resulted in hitting a path where the source offset was
subsequently ignored. This leads to the operation reading from invalid
memory (or hitting the assert warning about the same).
References: https://bugs.freedesktop.org/show_bug.cgi?id=70924
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We know that when we access either a CPU or GTT mmap we are vulernable
to receiving a SIGBUS. In fact, we can catch these and abort the
operation preventing X and all of its clients from randomly dieing.
This helps for instance if you try and use a 1GiB frontbuffer on a 2GiB
machine...
For complete protection, we also need to catch signals for all GTT maps,
such as VBO and staging buffers. (TBD)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
When stepping over the tiles, beware that the step may overflow the
int16_t region extents, so use an int for the calculation.
Reported-by: Andrew Woodward
Bugzilla: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1200766
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Along the slow path, skip all processing of glyphs that are not visible.
This is important as the slow path handles the per-glyph redirection
case, which is much more expensive.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If we cannot fit the source/destination and a tile into the aperture,
then we cannot perform the copy and must do it using the CPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
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>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
It was only ever used in conjunction with HAS_DEBUG_FULL. For debug
purposes it is as easy to redefine DBG locally. By simplifying the DBG
macro we can create it consistently and so reduce the number of compiler
warnings.
Long term, this has to be dynamic. Sigh.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
To accommodate changes in the Xserver and avoid breakage; would have been
much easier had the fb been exported in the first place.
|
|
If we expect to only emit this set of copy_boxes() and then submit the
batch, we would prefer to use the BLT for its lower latency.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Rename for different variables
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Semmingly only advisable when already committed to using the GPU. This
first pass is still a little naive as it makes no attempt to avoid empty
tiles, nor aims to be efficient.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Rather than attempt to flatten the chain to the last link, we may need
to hold a reference to the intermediate links in case of batch buffer
submission.
Fixes http://tnsp.org/~ccr/intel-gfx/test.html
Reported-by: Matti Hamalainen <ccr@tnsp.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49436
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
These are now fixed by obeying a minimum alignment restriction.
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>
|
|
If we need to enlarge the sampled tile due to tiling alignments, the
resulting sample can become larger than we can accommodate through the 3D
pipeline, resulting in FAIL.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If the pixmap is larger than the pipeline, but the operation extents fit
within the pipeline, we may be able to create a proxy target to
transform the operation into one that fits within the constraints of the
render pipeline.
This fixes the infinite recursion hit with partially displayed extremely
large images.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The kernel has a bug that prevents pwriting buffers large than the
aperture. Whilst waiting for the fix, limit the upload where possible to
fit within that constraint.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We can juggle rendering into large bo on gen4 by redirecting the
rendering through a proxy that is tile aligned, and so the render target
may be slightly larger than the tiling step size. As that is then larger
than the maximum 3D pipeline, the trick fails and we need to resort to a
temporary render target with copies in and out. In this case, check that
the tile is aligned to the most pessimistic tiling width and reduce the
step size to accomodate the enlargement.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If we are attempting to copy between two large bo, larger than we can
fit into the aperture, break the copy into smaller steps and use an
intermediatory.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As we may have a constrained aperture, we need to be careful not to
exceed our resources limits when uploading the pixel data. (For example,
fitting two of the maximum bo into a single batch may fail due to
fragmentation of the GATT.) So be cautious and use more tiles to reduce
the size of each individual batch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If we are forced to perform a render operation to a bo too large to fit
in the pipeline, copy to an intermediate and split the operation into
tiles rather than fallback.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
In order to avoid having to perform a copy of the cacheable buffer into
GPU space, we can map a bo as cacheable and write directly to its
contents. This is only a win on systems that can avoid the clflush, and
also we have to go to greater measures to avoid unnecessary
serialisation upon that CPU bo. Sadly, we do not yet go to enough length
to avoid negatively impacting ShmPutImage, but that does not appear to
be a artefact of stalling upon a CPU buffer.
Note, LLC is a SandyBridge feature enabled by default in kernel 3.1 and
later. In time, we should be able to expose similar support for
snoopable buffers for other generations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This is set in configure and redefining it later inside the C files just
leads to trouble and broken compilation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Now used for spans and so triggering death by NULL function pointer on
older chipsets.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Update the DBG messages to reflect changes in function parameters.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|