| Age | Commit message (Collapse) | Author |
|---|
|
If the count is 0, then the malloc is permitted to return NULL, so don't
throw an error in that case.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Peter Clifton hit an issue whereby he had a spurious TV hotplug event
that occurred between the two GETRESOURCES ioctls that caused the kernel
to skip filling one array and led to a crash (as the size of the
allocated and initialised block of memory differed from the reported
size).
Fixes: http://bugs.freedesktop.org/show_bug.cgi?id=25912
Crash whilst probing modes
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Peter Clifton <pcjc2@cam.ac.uk>
|
|
|
|
|
|
Conflicts:
configure.ac
|
|
|
|
|
|
|
|
- unreference pushbuf objects on channel destruction
Based on Krzysztof Smiechowicz's patch.
|
|
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
|
|
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
|
|
|
|
|
|
as Michel pointed out we are exposing too much info for these object
for this to be maintainable going forward.
This patch set minimises the exposed parts of the radeon_bo and
radeon_cs objects to the piece necessary for ddx/mesa to operate
at a decent speed.
The major problem is mesa contains a legacy BO/CS managers which we still
need to expose functionality to, and we really cannot change the API
until we can drop the non-KMS codepaths.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Don't store the error return in bo_gem->gtt_virtual or else we will
attempt to use that as a valid pointer in future mappings.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
|
|
|
|
|
|
This is needed as change in kernel will lead to ioctl returning
EINTR if they are interrupted.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
This removes the foremost prolific user of mutexes in libdrm_intel.so.
The other uses of the bufmgr_gem->mutex to serial access to individual
bos are currently required by Mesa, and are far less frequent.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[anholt: This chunk looks good...]
Acked-by: Eric Anholt <eric@anholt.net>
|
|
Forgot to update this when pushing the pageflip bits.
|
|
Conflicts:
include/drm/drm.h
|
|
|
|
|
|
Conflicts:
include/drm/drm.h - RMFB had its signature changed to avoid uint32_t
|
|
|
|
|
|
|
|
This has the unfortunate behaviour of releasing our malloc cache, but
the alternative is for X to consume a couple of gigabytes of ram and
die during testing. Fortunately the extra mallocs have little impact on
performance whereas avoiding swap and death, lots.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Instead of forcing the caller to check after every emit_reloc(), we can
flag the object as being in error, propagating that error upwards through
the relocation tree, and failing the eventual batch buffer execution.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
EAGAIN cannot be raised by the current code, but the system call maybe
interrupted and so return EINTR.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Hitting this error lead to a segfault:
intel_bufmgr_gem.c:919: Error mapping buffer 48607 (pixmap):
Cannot allocate memory.
because the errno was reused as the function return value after being
reset by the fprintf(), so caller thought the mapping had succeeded. The
convention established by libdrm is that the return value is the
negative errno and that uses of libdrm cannot trust the value of errno
afterwards, but must use the return code.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Buffers on the relocation tree are guarded by the reference to the batch
object and so do not need an extra reference whilst constructing the
list of execution buffer objects.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Having been bitten by a missing EINTR check during mmap_gtt(), I thought
it prudent to add some more protection around the ioctls.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This allows us to keep the assert added in the previous commit that we do
not modify the tree_reloc_size after inserting the buffer into a relocation
tree, which was being hit here:
#0 0xb78c2424 in __kernel_vsyscall ()
#1 0xb74f6401 in raise () from /lib/libc.so.6
#2 0xb74f7b42 in abort () from /lib/libc.so.6
#3 0xb74ef5a8 in __assert_fail () from /lib/libc.so.6
#4 0xb737e78b in drm_intel_bo_gem_set_in_aperture_size (bufmgr_gem=<value optimized out>, bo_gem=0x6) at intel_bufmgr_gem.c:373
#5 0xb737f519 in drm_intel_gem_bo_set_tiling (bo=0xa1030a0, tiling_mode=0xbff6c85c, stride=0) at intel_bufmgr_gem.c:1386
#6 0xb737f67f in drm_intel_gem_bo_unreference_final (bo=0xa1030a0, time=<value optimized out>) at intel_bufmgr_gem.c:768
#7 0xb737f5e3 in drm_intel_gem_bo_unreference_locked_timed (bo=0xa1e50d0, time=<value optimized out>) at intel_bufmgr_gem.c:805
#8 drm_intel_gem_bo_unreference_final (bo=0xa1e50d0, time=<value optimized out>) at intel_bufmgr_gem.c:756
#9 0xb737fcbb in drm_intel_gem_bo_unreference (bo=0xa1e50d0) at intel_bufmgr_gem.c:821
#10 0xb737b4e6 in drm_intel_bo_unreference (bo=0x0) at intel_bufmgr.c:80
#11 0xb7325625 in intel_batch_flush (scrn=0x9d91f78, flush=1) at i830_batchbuffer.c:200
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
For the older chipsets, i.e. pre-i965, which have severe alignment
restrictions for tiled buffers we need to pessimistically assume that we
will waste the size of buffer to meet those alignment constraints.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If the kernel immediately frees the backing store for a buffer when
marking it purgeable, then there is not point adding to the cache. Free
it immediately, instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
|
|
|
|
DRM_MAJOR is platform specific, but not used outside of xf86drm.c
that I can find.
|
|
lost in 500f5b524000ed5930301f4303744cb4c0a19b75
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
|
