When on the same Y-band as the span, as soon as the clip boxes are too
far to the right, we can stop searching for more intersections.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the pixel exists only in the CPU damage, attempting to read it back
from the GPU only results in garbage.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The offsets from image_from_pict() already include the drawable offset
so we need not apply them twice.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When using the mask instead of the src for adding the glyphs we need to
pass the glyph coordinates through the mask coordinates rather than the
source.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Beware the overflow implicit in:
adx = x2 >= x1 ? x2 - x1 : x1 - x2;
when both x2 and x1 may be large signed 16-bit values
Reported-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50532
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the glyph format does not match the mask format we can not simply add
the two together, but must first perform a channel expansion (or
contraction) by multiplying the glyph against a WHITE source.
Normally the glyph and the mask are equivalent formats and so we hit the
fast path.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This was lost in the midst of the OSTimer overhaul.
Reported-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=50393
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
And similarly for MALLOCLIKE_BLOCK. The issue being that valgrind may
overwrite such blocks with alloc-fill and free-fill values, but when in
fact they are defined and still in use by the GPU. This can lead to the
GPU processing garbage, and GPU hangs.
Reported-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50393
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Commit 8a9a585341 ("Only create a single instance of the intel_options
array") moved the definition of intel_options into a separate .c file.
Several of the defined options are #ifdef'd based on the configuration,
but since config.h is never included, the macros being tested are never
defined. Therefore, none of the configuration-specific options will
ever be available at runtime, even if they should be.
Add an inclusion of config.h so that such configuration-specific options
work again.
Signed-off-by: Nick Bowler <nbowler@draconx.ca>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we check before allocating the upload buffer, we can not be certain
that we will allocate an already attached bo or that we have a free exec
slot. So always check that we have an extra exec slot available - the
false positive rate is going to be negligible.
Reported-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50457
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
There is not point repeating the search after retiring if we know that
there is no outstanding suitable active buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Trivial readibility fix, as the actual ordering is serialised through
there being only a single thread.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the GPU is busy, then we may not actually schedule our copy for
several vblanks, resulting in us falsely reporting that the work
completed too early and allowing the client to continue scheduling more
work and racing ahead of the queued copies.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
So that we may benefit from the caching of buffers and the automatic
selection of the preferred upload method.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Nick Bowler