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>
This commit only enables two glamor functions for
uxa_fill_spans and uxa_poly_fill_rects.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
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>
Integrate glamor acceleration into UXA framework. Add
necessary flushing at the following points:
1. Flush UXA batch buffer before call into glamor.
2. Flush GL operations after return from a glamor function.
3. The point we need to flush UXA batch buffer, we also
need to flush GL operations, for example, in
intel_flush_callback and couple of places in intel_display.c.
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>
Chris Wilson
Zhigang Gong