And so hopefully make it clearer. In the process we restore the flushing
behaviour for UXA back to before the glamor intervention.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to workaround a bug in the shaders on gen4, we need to flush
the pipeline after every rectangle. The recently introduced fill-one
mechanism for gen4, missed this vital step triggering a random hang with
an otherwise sane batchbuffer (the missing flush is hard to spot!).
Fixes regression from 86f99379ee (sna/gen4: Add fill-one).
Reported-by: Albert Damen <albrt@gmx.net>
Reported-by: Fryderyk Dziarmagowski <fdziarmagowski@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43083
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Added one configuration option --enable-glamor to control
whether use glamor. Added one new file intel_glamor.c to
wrap glamor egl API for intel driver's usage.
This commit doesn't really change the driver's control path.
It just adds necessary files for glamor and change some
configuration.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Make sure that the damage is always set, even if only to NULL, so that
we are safe if in future the operation state is not initially cleared.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes a later assert that the fenced size is valid for kgem_create_2d()
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42888
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Don't just deference any old random pointer, use the one we actually
mapped in the first place!
Reported-by: Matti Hamalainen <ccr@tnsp.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42880
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When allocating objects, we need to check the size of the full fenced
regions against the mappable limits in order to be able to mmap the
object later.
References: https://bugs.freedesktop.org/show_bug.cgi?id=42813
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
PutImage rarely uploads the entire image inside a single request,
instead breaking up into scanline segments to fit within the protocol
limits. A few optimisations are based on detecting when we can discard
the GPU bo for an all-dirty CPU pixmap, which are useful in this case so
check for an entirely dirty pixmap following an incremental PutImage.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For a long lived pixmap which we are repeatedly using for upload and
copying to other pixmaps, we don't want to keep to maintain a GPU
buffer. So instead, reset the source counter if we discard the GPU bo
and treat the pixmap as purely CPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is the stub of the decoder, sufficient to give details of the ops
within the batch and to keep the debugger happy.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Otherwise gnome-shell forgets to update. Eventually, I'll get the async
pageflipping bits merged into the Xserver and this path and its extra
bw wastage will be history! But still I'll be undermined by the
compositor, grrr.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A large part of the function preamble overhead is the multi-indirection
lookup for retrieving the sna pointer. We can eliminate most of these by
storing a pointer on the Pixmap as well, which we often need to lookup
anyway.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is to keep the sanity checks upon the caches happy by keeping a
potential flush out of the inactive cache.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Zhigang Gong