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>
See if we have a bo that we can cheaply map to an inplace upload, rather
than rely on an existing GTT map.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Updating one CRTC may cause the kernel to turn off another, so be
paranoid and run the check in a loop after applying the CRTC set.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We do no want to slow down the detection phase by performing our
self-tests, so only running those before initialising the driver.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As these should be the only time that they change and we now have the
checks in place, we can drop the workaround of doing the check just
before emitting the wait.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Section "Device"
Option "AccelMethod" "uxa/glamor/sna"
EndSection
The appropriate backend must also be enabled at compile time for the
runtime option to be available (i.e. --enable-uxa (default) --enable-sna
--enable-glamor)
Demanded-by: Adam Jackson <ajax@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50290
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Unifies available options for both UXA and SNA drivers, and
moves them into a common header file, intel_opts.h.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Chris Wilson
Nick Bowler
Johannes Obermayr
Eugeni Dodonov