If the pci_device's actual gen was > 4, then we stupidly set
bufmgr_gem->gen = 6. Luckily this caused no bugs, and this fix shouldn't
change any behavior, because all checks against the gen currently have one
of the forms below:
gen == 2
gen == 3
gen >= 4
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
This will make these macros reusable from intel_decode.c, which
doesn't have a bufmgr_gem context, without faking the struct. We
should generally only be using these macros from bufmgr_gem context
setup anyway.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
During free we unconditionally delete the bo from the vma cache. This
relies on the its list member being kept in a sane state. This fails
after the object is purged, as the purge operation performs a pure
deletion and doesn't reset the list member, leaving a pair of dangling
pointers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Hopefully all the bugs in the callers have been found, so time to
handle the failures "gracefully" again.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the max number of VMA mappings is a hard per-process limit, we need
to include the number of currently active mappings when evicting in
order to make room for a new mmap.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
There is a per-process limit on the number of vma that the process can
keep open, so we cannot keep an unlimited cache of unused vma's (besides
keeping track of all those vma in the kernel adds considerable overhead).
However, in order to work around inefficiencies in the kernel it is
beneficial to reuse the vma, so keep a MRU cache of vma.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As a precautionary measure munmap on buffer free so that we never leak
the vma. Also include a warning during debugging.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Otherwise we blow up on heavy tiled blitter loads (with giant
pixmaps).
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Before this, consumers of the libdrm API that might map a buffer
either way had to track which way was chosen at map time to call the
appropriate unmap. This relaxes that requirement by making
drm_intel_bo_unmap() always appropriate.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
This lets us replace the current inner drawing loop of mesa:
for each prim {
compute bo list
if (check_aperture_space(bo list)) {
batch_flush()
compute bo list
if (check_aperture_space(bo list)) {
whine_about_batch_size()
fall back;
}
}
upload state to BOs
}
with this inner loop:
for each prim {
retry:
upload state to BOs
if (check_aperture_space(batch)) {
if (!retried) {
reset_to_last_prim()
batch_flush()
} else {
if (batch_flush())
whine_about_batch_size()
goto retry;
}
}
}
This avoids having to implement code to walk over certain sets of GL
state twice (the "compute bo list" step). While it's not a
performance improvement, it's a significant win in code complexity:
about -200 lines, and one place to make mistakes related to aperture
space instead of N places to forget some BO we should have included.
Note how if we do a reset in the new loop , we immediately flush. We
don't need to check aperture space -- the kernel will tell us if we
actually ran out of aperture or not. And if we did run out of
aperture, it's because either the single prim was too big, or because
check_aperture was wrong at the point of setting up the last
primitive.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A few of the bitfield-based booleans are left in place. Changing them
to "bool" results in the same code size, so I'm erring on the side of
not changing things.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is Fail.
First patch to libdrm, and I've borked it up.
Noticed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... and if asked to open a bo by the same global name, return a fresh
reference to the previously allocated buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
gen4+ hardware doesn't use fences for GPU access and the older kernel
doesn't expect userspace to make such a mistake. So don't.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32190
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For relaxed fencing the object may only consume the small set of active
pages, but still requires a fence region once bound into the aperture.
This is the size we need to use when computing the maximum possible
aperture space that could be used by a single batchbuffer and so avoid
hitting ENOSPC.
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Both the consumers of this API (sync objects and client throttling)
were expecting this behavior. The kernel used to actually behave the
desired (but incorrect) way for us anyway, but that got fixed a while
back.
If bufmgr.bo_mrb_exec is not set, drm_intel_bo_mrb_exec returns ENODEV
even though drm_intel_gem_bo_mrb_exec2 will work fine for the RENDER ring.
Fixes xf86-video-intel after commit 'add BLT ring support' (5bed685f76)
with kernels without BSD or BLT ring support (2.6.34 and before).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31443
Signed-off-by: Albert Damen <albrt@gmx.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The intent of these was to catch mismatched map/unmap. What it
actually did was check whether there was ever a mapping of that type
(including in a previous life of the buffer through the userland BO
cache), not whether they were mismatched. We don't even actually want
to catch mismatched map/unmap, unless we also do refcounting, since at
one point Mesa would do map/map/use/unmap/unmap. Just remove this
code instead.
The kernel has always allowed userspace to underallocate objects
supplied for fencing. However, the kernel only allocated the object size
for the fence in the GTT and so caused tiling corruption. More recently
the kernel does allocate the full fence region in the GTT for an
under-sized object and so advertises that clients may finally make use
of this feature. The biggest benefit is for texture-heavy GL games on
i945 such as World of Padman which go from needing over 1GiB of RAM to
play to fitting in the GTT!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the higher layers check the error return from libdrm-intel and
are supposed to handle the error (and print their own warning in
extremis) the voluminous output on stderr is just noise and a hazard in
its own right.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the mapping succeeds we have a valid pointer. If setting the domain
failures we may incur cache corruption. However the usual failure mode
is because of a hung GPU, in which case it is preferable to ignore the
minor error from setting the domain and continue on oblivious. If
these errors persist, we should rate limit the warning [or even just
remove it].
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Mesa uses the returned pitch from alloc_tiled, so make sure that we set
it correctly before modifying the stride used for the SET_TILING call.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Ensure that the user doesn't attempt to specify a stride to use with a
linear buffer by forcing such to be zero.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
execbuffer() returns ENOSPC if it cannot fit the batch buffer into the
aperture which is the error we want to diagnose here.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rearrange the cache cleanup so that we always scan following a final
unreference, and guard against multiple scans in a single second.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When allocating a tiled buffer, if we remove the desired tiling mode due
to it being beyond hardware limits, also remove the stride. This ensures
that we only ever use stride 0 with I915_TILING_NONE.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we now expose a method to allocate tiled buffers, it makes more sense
to defer the SET_TILING until required. Besides the slim chance that it
will be a no-op, by delaying the change we are less likely to stall on
waiting for a bound buffer to release a fence register.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to inform the kernel if the tiling stride changes and not only
for changes of the tiling mode.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We had two cases recently where the rounding to powers of two hurt
badly: 4:2:0 YUV HD video frames would round up from 2.2MB to 4MB, and
Urban Terror was hitting aperture size limitations. For UT, this is
because mipmap trees for power of two texture sizes will land right in
the middle between two cache buckets.
By giving a few more sizes between powers of two, Urban Terror on my
945 ends up consuming 207MB of GEM objects instead of 272MB, and HD
video decode on Ironlake goes from 99MB to 75MB.
cairo-perf-diff of the benchmarks for gl and xlib shows a 1.09x and
1.06x speedup and a 1.07x, 1.08x, and 1.11x slowdown. From this, I
think this patch was really a no-op in terms of performance for these
CPU-bound workloads.
If the pitch is too large for the hardware to tile, recompute the
required surface size based on the untiled pitch and alignments. For the
older hardware, which has smaller limits and greater restrictions, this
may be a considerable saving in allocation size.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chad Versace
Eric Anholt
Chris Wilson
Daniel Vetter
Albert Damen