| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
So that we can pull a couple of Intel bug fixes into xf86-video-intel.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We cannot afford to cache the vma per open bo as this may exhaust the
per-process limits.
References: https://bugs.freedesktop.org/show_bug.cgi?id=43075
References: https://bugs.freedesktop.org/show_bug.cgi?id=40066
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>
|
|
Valgrind throws warns about a user-after-free if you try to bind a
new subchannel after the old one in that slot was freed,
so remove it from the channel list.
Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com>
|
|
Initial test only include ttm test for stressing ttm memory
allocations.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
|
|
Push the new Intel API for use by mesa.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
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>
|
|
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This used to be next to some map refcounting code, but that is long dead.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
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 was reported in coverity.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
|
|
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
|
|
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
|
|
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
|
|
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
|
|
It's more compatible; at least the Intel driver now rejects 32 bit
depths since it generally can't support real 32 bit framebuffers
(supports 30, 36, and 64 bit, but not 32).
|
|
|
|
fixes a segfault on make check seen in tinderbox
|
|
To enable usage of xf86drm.h from C++ programs/frameworks.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
[ickle: also wrap xf86drmMode.h]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Luckily the kernel has become extremely paranoid about such matters.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Otherwise it's pretty hard to differentiate the different chipset
variants.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
... because argument is evaluated only if NDEBUG is not defined
|
|
Both drmIoctl and ioctl define second argument as unigned long.
Debugging/tracing tools (like strace or valgrind) on 64-bit machines see
different request value for ioctls with 32nd bit set, because casting
signed int to unsigned long extends 32nd bit to upper word, so 0x80000000
becomes 0xFFFFFFFF80000000)
Nobody noticed because higher 32 bits are chopped off on their way to kernel.
|
|
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
|
|
It's going to call bo_get_subdata method, but not bo_subdata
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
|
|
|
|
Push the new Intel API for use by mesa.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
... so request a 32bpp dumb buffer rather than a 16bpp.
Fixes modetest and friends.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Hi Alex,
Enclosed is a revised version of the patch sent on Mar 18, against
the master branch of the drm userspace (i.e. libdrm). Details
summarised in this thread:
http://lists.freedesktop.org/archives/dri-devel/2011-March/009499.html
This patch reconciles libdrm with the the kernel change that Dave
pushed this morning. It *supersedes* the previously sent patch (i.e.
apply it to the master branch as it exists at the time of this writing,
not as an incremental patch to the one sent previously).
Regards,
Ilija
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
Reported-by: Oliver McFadden <oliver.mcfadden@nokia.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
|
|
A tile on gen2 has a size of 2kb, stride of 128 bytes and 16 rows.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Replace some deprecated autoconf macros and use the new libtool
syntax
|
|
|
|
this uses the drm cap interface to check if the dumb ioctl
is supported.
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
