If we are going to transfer GPU damage back to the CPU bo, then we can
reuse an active buffer and so improve the recycling.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to avoid conflating whether a bo was marked purgeable with its
retained state, we need to carefully handle the errors from madv.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we incurred a context switch to the BLT in order to prepare the
target (uploading damage for instance), we should recheck whether we can
continue the operation on the BLT rather than force a switch back to
RENDER.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we need to halt the 3D engine in order to flush the pipeline for a
dirty source, we may as well re-evaluate whether we can use the BLT
instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we will need to extract either the source or the destination, we
should see if we can do the entire operation on the BLT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As for PutImage, if the damage will be immediately flushed out to the
GPU bo, we may as well do the write directly to the GPU bo and not
staged via the shadow.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
One issue with the heuristic is that it is based on total pixmap size
whereas the goal is to pick the placement for the next series of
operations. The next step in refinement is to combine an overall
placement to avoid frequent migrations along with a per-operation
override.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When the pixmap is large, larger than L2 cache size, we are unlikely to
benefit from first copying the data to a shadow buffer -- as that shadow
buffer itself will mostly reside in main memory. In such circumstances
we may as perform the write to the GTT mapping of the GPU bo. As such,
it is a fragile heuristic that may require further tuning.
Avoiding that extra copy gives a 30% boost to putimage500/shmput500 at
~10% cost to putimage10/shmput10 on Atom (945gm/PineView), without any
noticeable impact upon cairo.
Reported-by: Michael Larabel <Michael@phoronix.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to avoid having to perform a copy of the cacheable buffer into
GPU space, we can map a bo as cacheable and write directly to its
contents. This is only a win on systems that can avoid the clflush, and
also we have to go to greater measures to avoid unnecessary
serialisation upon that CPU bo. Sadly, we do not yet go to enough length
to avoid negatively impacting ShmPutImage, but that does not appear to
be a artefact of stalling upon a CPU buffer.
Note, LLC is a SandyBridge feature enabled by default in kernel 3.1 and
later. In time, we should be able to expose similar support for
snoopable buffers for other generations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Until the advent of the VMA cache, we were safe to reap the batch bo by
hand. However, as we continue to add additional data to the bo, it is
wise to use the common free function.
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43899
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we failed to create textured pixmap from BO's handle, we
turn to create a new glamor pixmap by call glamor_create_pixmap
rather than fallback to in-memory pixmap. Have to introduce
a new wrapper function intel_glamor_create_pixmap.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
And propagate that failure back to the client.
Reported-by: Paul Neumann <paul104x@yahoo.de>
References: https://bugs.freedesktop.org/show_bug.cgi?id=43716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When we try to create a glamor pixmap and fail we need to create a real
pixmap along with its pixel allocation, instead of detaching ourselves
and returning the fake pixmap header.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The danger of the early return when UXA is not using glyphs is evident
in the eventual crash when glamor begins evicting and reusing its glyph
cache slots.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Don't attempt to dereference the NULL gpu_bo after having just freed it.
Here in lies the folly of trying to blindly silence the compiler.
Instead we should heed the error return as it means that we didn't
decouple the pixmap from the inactive list and so we choose to place it
back on the active list to purge again in the near future.
Reported-by: Paul Neumann <paul104x@yahoo.de
References: https://bugs.freedesktop.org/show_bug.cgi?id=43716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In the event of failure, we choose to loose track of the damage and
choose rendering corruption over crashing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This commit hooks up all the remaining rendering routines to call into
glamor; the takeover is nearly complete! When tested with the latest
glamor master branch, it passes rendercheck.
One thing need to be pointed out is the picture's handling.
Pictures support many different color formats, but glamor's
texture only support a few color formats. And the most common
scenario is that we create a pixmap with a color depth and
then attach it to a picture which has a specific color format
with the same color depth. But there is no way to change a
texture's internal format after the texture was allocated.
If you do that, the OpenGL will allocate a new texture. And
then the glamor side and UXA side will be inconsitent. So
for all the picture related operations, we can't fallback to
UXA path directly, even it is rather a straight forward
operation. So for the get_image, Addtraps.., we have to add
wrappers function for them to jump into glamor firstly.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
[ickle: prefer access; ok = glamor(); finish; if (!ok) goto fallback; return; ]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
intel_glamor.c: In function 'intel_glamor_create_screen_image':
intel_glamor.c:192:12: warning: variable 'pixmap' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we now defer the allocation of pixel data until first use, it can
fail in the middle of a rendering routine. In order to prevent chasing
us passing a NULL pointer into the fallback routines, we need to propagate
the failure from the malloc and suppress the failure, discarding the
operation, which is less than ideal.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The cpu bo is only allocated on LLC systems, so do avoid the NULL deref on
debugging for others.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Zhigang Gong