Age | Commit message (Collapse) | Author |
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
By using move-area-to-gpu and specifying that we overwrite the target
area, we can optimize away any needless damage migration.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Rather than guess in the backend when we are going to be called for
multiple boxes, rely on the frontend declaring it correctly.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
When dereferences priv, make sure it exists first. ShmPixmaps for
example, may not have one, nor do very small buffers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If the composite reads entirely from within a large pixmap which is a
clear color, just replace the source with a solid.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Under PictFilterNearest, we can ignore fractional translations (not all
renderers discard those.) And if we are being approximate, we can loosen
our tolerance as well.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
I forgot that the initial memset(&fill, 0, sizeof(fill)) was no longer
performed and we rely on explicit initialisation during the setup, so
add the missing fields.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76088
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We need to flush the batch if we run out of space aligning our vertex
buffer - but the test must anticipate the space required for the new
alignment.
Reported-by: Arkadiusz Miskiewicz
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We can now check whether the Composite operation will require existing
CPU damage and if not discard it.
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 surface creation routines should ensure that the minimum pitch
alignments are met. However, when rendering to a CPU bo, the pitch is
not under our control so we need to be more careful.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Older version of glibc and valgrind require a slight massage.
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 submit prior to an operation, check that we didn't just wedge the
GPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
For the scanlines emitted for rendering Core drawing primitives, it is
preferable to use the BLT engine, so pass those hints down.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Upon aligning the buffer, we may enlarge the vbo to accomodate the
vertex alignment and push the current index past the end of the buffer.
Move the space check from before the alignment computation to
afterwards.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=47597
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
For these gen, we always want to use BLT where possible - even if it
incurs a context switch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Now that we use CPU mmaps to read/write to tiled X surfaces, we find
ourselves frequently switching between CPU and GTT mmaps and so wish to
cache both.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Highlights of that distribution include xorg-xserver-1.6.5, kernel
3.0.76 and gcc-4.3.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Occasionally when forced to use an intermediate destination surface, we
know that we will completely overwrite the contents of the surface and
so we can forgo the initial copy from the target.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66297
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The clear hint is correctly updated when performing the move-to-gpu and
so it is being superfluously repeated by the callers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If the target bo is not bound when we start to emit the composite state
for the operation, we are screwed.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This is useful, for example, with the multiple gen7 variants.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
References: https://bugs.freedesktop.org/show_bug.cgi?id=62198
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
gen3_emit_composite_primitive_identity_gradient__sse2
References: https://bugs.freedesktop.org/show_bug.cgi?id=62198
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Prefer the slightly cheaper _sna_get_transformed_scaled().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This helps gen3 in particular as it uses the unique_id field of a bo to
detect changes in render target.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This is required for copying from depth-15 surfaces onto other depths.
Reported-by: Reinis Danne
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>
|
|
When applying pan and zoom to a mismatched video, it would inevitably
miscompute the origin and scale factors.
Reported-by: Matti Hamalainen <ccr@tnsp.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61610
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>
|
|
Oops, the assertions that we had sufficient free space was inverted.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If we end up contending for the vertex lock, we need to double check
there is sufficient vertex space left for us.
Bugzill: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1124576
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Various assertions to track down a potential programming error.
References: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1124576
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The idea is to implement more fine-grained checks as we may want
different heuristics for desktops with GT1s than for mobile GT2s, etc.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We need to be careful not just when finishing the current vbo to
synchronize with the sharing threads, but also before we emit the batch
state that no other thread will try and do the same.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
When completing a batch mid-operation, we need to wait upon the other
threads to complete their writes so that memory is coherent before
submitting the work to the GPU. This was achieved by forcing the finish,
but all that from that is the wait, which makes the handling of threads
much explicit and removes the unnecessary vbo refresh.
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 are carrying over a nearly full vbo from one batch to the next, we
may indeed finish it prior to writing any new primitives and so the
assert is truly bogus.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|