Wrap the madvise ioctl for use in APPLE_object_purgeable.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
The old code increments the command stream size by another kbyte, but does
not make sure that the requested packet size fits into the stream. The patch
ensures that the whole next packet fits there and rounds the allocated size to
a power of two.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
The kernel will now write data to the DRM fd for various event types if
requested. Currently, the only supported event is a vblank event: it contains
the vblank count for the event as well as a timestamp from when the event
ocurred. Since the DRM fd is now pollable, it's easy to integrate into
existing event loops.
Notably when freeing a batchbuffer, we often end up freeing many of the
buffers it points at as well. Avoiding repeated calls brings us a 9% CPU
win for cairo-gl.
[ # ] backend test min(s) median(s) stddev. count
before:
[ 0] gl firefox-talos-gfx 58.941 58.966 0.75% 3/3
after:
[ 0] gl firefox-talos-gfx 54.186 54.195 0.49% 3/3
If the target we're asking about hasn't ever been used as a relocation
target, then it obviously hasn't been used as a target by the batch's reloc
tree. This is the common case for good GL programming where you only map
fresh buffers, and gives us a 5% win in cairo-gl.
[ # ] backend test min(s) median(s) stddev. count
before:
[ 0] gl firefox-talos-gfx 64.680 64.756 0.06% 3/3
after:
[ 0] gl firefox-talos-gfx 60.816 60.970 0.29% 3/3
Only build libdrm_intel automatically if we have support for atomic
operations. To force configure to build drm pass --enable-intel, which
will cause the configure to error if no support is found. Or pass
--disable-intel to explicitly prevent libdrm_intel from being built.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I slipped it in with the alloc_tiled changes, since we were explicitly
throwing the parameter away. It caught some bogus released code, which
we've now fixed, so remove the asserts to keep old drivers working.
This simplifies driver code in handling object allocation, and also gives us
an opportunity to possibly cache tiled buffers if it turns out to be a win.
[anholt: This is chopped out of the execbuf2 patch, as it seems to be useful
separately and cleans up the execbuf2 changes to be more obvious]
In conjunction with the atomic operation patch, it may be more
convenient for some people to disable building libdrm-intel and its
dependencies upon the atomic intrinsics then it is for them to use a
supported compiler.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the target architecture for Intel GPUs is the x86, we can presume to
have reasonable compiler support for Intel atomic intrinsics, i.e. gcc,
and so use those in preference to pulling in a complicated mess of
fragile assembly.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[anholt: hand-resolved against my previous commit. This brings cairo-gl
firefox-talos-gfx time from 65 seconds back down to 62 seconds.]
Signed-off-by: Eric Anholt <eric@anholt.net>
Set the DONTNEED flag on cached buffers so that the kernel is free to
discard those when under memory pressure.
[anholt: This takes firefox-talos-gfx time from ~62 seconds to ~65 seconds
on my GM965, but it seems like a hit worth taking for the improved
functionality from saving memory]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
There are a bunch of places in GL where if we can't do this we have to
flush the batchbuffer, and the cost of lookups here is outweighed by flush
savings.
I thought I was going to do all sorts of crazy experiments with it. I never
did, and it turned out the free-after-a-few-seconds plan is working out fine.
New ids for G41, Clarkdale and Arrandale.
Make sure we don't need to count fence also on new chips.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
This reverts commit 0a732983f0.
Paul Nieminen and Dave Airlie pointed out on IRC that this shouldn't be
necessary. I was seeing visual corruption in X before I made this change, but
I can't reproduce that anymore so it was probably an unrelated issue.