Suggested by Emil Velikov:
Normally hard coding pkg-config is considered a bad idea. Please
try PKG_CHECK_EXISTS - it would work like a charm when
cross-compiling.
Cheers
Emil
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We were not updating the window->crtc for the immediate swaps with the
result that after switching CRTCs, we were requesting a vblank on the
wrong pipe and triggering an error path (forcing the blit and negating
the elision).
Testcase: test/dri2-speed
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We expect mesa nowadays to preferentially use the render pipeline for
doing its clears and so want to avoid handing it back an active BLT bo
if we don't have semaphores (as that would cause a sync).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to make tools indivdiually selectable for compiling, we don't
want to override earlier tools - so use '+=' rather than a plain '='
when adding each tool to the set of PROGRAMS.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
present.flush is called on the Window after a copy from a Pixmap is
completed - which will be naturally flushed anyway. What the API should
be passing is the Pixmap, since we do want to flush the operations from
it before sending the idle event. C'est la vie.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When emitting batches early for improved GPU/CPU concurrency, we only
want to do so if the target ring is not busy. However, if the batch
requires a semaphore, we also need to consider the other ring as well.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We improve dispatch latency if after creating a command buffer we
immediately submit if the GPU is idle. This improves concurrency as we
continue to build the next command buffer as the GPU executes and helps
prevent needlessly using one engine for too long (i.e. sometimes we may
be able to execute the work much early and do the ring switch cheaply).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since knowing which ring the bo is currently active on is important when
considering the impact of semaphores on the next operation, be sure to
query it on foreign bo before we use them.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Even on GT3, it is preferrential to use the blitter if the copy is small
(due to the latency in execution).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Even on GT3, it is preferrential to use the blitter if the copy is small
(due to the latency in execution).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Disabling the outputs and trying again can only possibly help in the
case of fragmentation. In all other failures modes (typically GPU hang)
it just causes a slow flash of the display.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It's white lie that only is technically required for gen2, and works
around a massive performance hit on gen7.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Properties may refresh quickly, more often than the output status
changes. We want to query the properties without doing a forced probe,
so make sure we refresh the values if the user requests a property.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The preferred all-inclusive method for finding alloca().
Reported-by: Richard Palo <richard@netbsd.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89762
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to include <sys/mkdev.h> on Solaris.
Reported-by: Richard Palo <richard@netbsd.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89763
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Or else face compile failures:
blt.c: In function 'affine_blt':
blt.c:1403:3: error: unknown type name 'pixman_f_vector_t'
blt.c:1407:4: error: request for member 'v' in something not a structure or union
blt.c:1408:4: error: request for member 'v' in something not a structure or union
blt.c:1409:4: error: request for member 'v' in something not a structure or union
blt.c:1411:3: warning: passing argument 2 of 'pixman_f_transform_point_3d' from incompatible pointer type [enabled by default]
In file included from /usr/include/xorg/miscstruct.h:52:0,
from /usr/include/xorg/regionstr.h:52,
from /usr/include/xorg/region.h:50,
from /usr/include/xorg/window.h:51,
from /usr/include/xorg/input.h:55,
from /usr/include/xorg/xf86str.h:38,
from sna.h:43,
from blt.c:32:
/usr/include/pixman-1/pixman.h:247:15: note: expected 'struct pixman_f_vector *' but argument is of type 'int *'
blt.c:1413:7: error: request for member 'v' in something not a structure or union
blt.c:1415:7: error: request for member 'v' in something not a structure or union
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since clearing is a relatively trivial operation, allow us to do the
clear to a CPU bo rather than block on the GPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A few assertions are there to catch less desirable behaviour rather than
outright errors. For these, just grab the backtrace and continue.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Until now we only applied pixel-exact rotations to the cursors. However,
this left the cursors ignoring scaling and so appearing incorrect on
outputs with transformations applied. An extra complications comes from
making sure that the scaling routine is signal safe.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Ideally, we would iterate over each CRTC and check that the transformed
cursor is still valid for the HW plane and then remember to transform
the cursor before displaying. Disabling the HW cursor if a non-native
transform is the first step in correcting the display of said cursor.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Sitting here with a 3200x1600 panel but no 1600x900 intermediate mode,
and I am too lazy to add it by hand.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When we are using the fallback method, we need to make sure the source
is on the CPU.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89053
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>