Having reduced all the vb code for these generations to the same set of
routines, we can refactor them into a single set of functions.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The idea being that when creating a surface to perform inplace
rasterisation, we won't be using the GPU for a while and so give it time
to naturally throttle.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Simply ignore the cropping and copy the whole plane rather than
complicate the computation of the packed destination pixels.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Oh fun. Textured video expects the source content to be relative to the
origin, whereas overlay video expects the source at the origin.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
So it appears that we end up performing a context switch on an empty
batch, but already has a mode. This is caught later, too late, by
assertions. However, we can change the guards slightly to prevent those
assertions without altering the code too greatly. And I can then think
how to detect where we are setting a mode on the batch but doing no
work - which is likely masking a bigger bug.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47597
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We only use a single cache for very large buffers, so we need to be
careful that we set the tiling on them. More so, we need to take extra
care when allocating large CPU bo from that cache to be sure that they
are untiled and the flags are true.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fortunately nobody had yet noticed that all videos were assumed to play
with a matching src/dst origin.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Keeping a set of pinned batches in userspace is considerably faster as
we can avoid the blit overhead. However, combining the two approaches
yields even greater performance, as fast as without either w/a, and yet
stable.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Ease debugging by allowing all acceleration or render acceleration to be
disabled through AccelMethod:
Option "AccelMethod" "off" -> disable all acceleration
Option "AccelMethod" "blt" -> disable render acceleration (only use BLT)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we will undoubtably flush and sync upon the SHM request very shortly
afterwards, we only want to use the GPU for the SHM upload iff it is
currently busy.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Split the decision between where it is imperative to use the BLT to
avoid TLB misses and the second case where it is merely preferential to
witch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Track the most recent ring each bo is executed on, and prefer to keep it
on that ring for the next operation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Oops, we never managed to reuse the cached location of the target
surface as we entered it into the cache with the wrong key.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
cell_list_alloc() is only called from one place, and the compiler should
already be inlining it - but does not appear to be. Hint harder.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The goal is to reduce the preference of rendering to a SHM pixmap - only
if it is already active, will we consider continuing to use it on the
GPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
So that we can prevent feeding back a stale bo when the DRI2 client
tries to swap an old buffer.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57212
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Further restrict the amount of fenced bo we try to fit into the batch to
make it easier for the kernel to accommodate the request.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In case we hit a path were we avoid reusing the source for the mask and
leave is_affine unset for a solid mask.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson