Prevent the leak and remove some unsightly code in the process.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
And just fixup the computed coordinates in the face of an invalid
matrix.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
Chris Wilson
Nick Bowler