summaryrefslogtreecommitdiff
path: root/intel/intel_bufmgr_gem.c
AgeCommit message (Collapse)Author
2010-02-10intel: Handle resetting of input params after EINTR during SET_TILINGChris Wilson
The SET_TILING is pernicious in that it overwrites the input arguments following an error in order to report the current tiling state of the buffer. This caught us by surprise as we then fed those arguments back into to the ioctl unmodified following an EINTR and so the kernel then reported success for the no-op. We interpreted this success as meaning that the tiling on the buffer had changed so updated our state and started using the buffer incorrectly in the new tiled/untiled manner. This lead to all sorts of random corruption and GPU hangs, even though the batch buffers would look sane (when the GPU had not wandered off into forbidden territory). References: Bug 25475 - [i915] Xorg crash / Execbuf while wedged http://bugs.freedesktop.org/show_bug.cgi?id=25475 Bug 25554 - i830_uxa_prepare_access: gtt bo map failed: Input/output error http://bugs.freedesktop.org/show_bug.cgi?id=25554 (And probably every other weird bug in the last few months.) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-02-09intel: Account for potential pinned buffers hogging fencesChris Wilson
As the kernel reports the total number of fences, we must guess how many fences are likely to be pinned. In the typical system these will be only used by the scanout buffers, of which there may be one per pipe, and any number of manually pinned fenced buffers. So take a conservative guess and reserve two fences for use by the system. Note this reduces the number of fences to 3 for i915 and prior. Reference: http://bugs.freedesktop.org/show_bug.cgi?id=25911 The latest intel driver 2.10.0 causes kernel oops and system hangs Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-02-02intel: check return value for callocDave Airlie
2009-12-08intel: Clear virtual after failing to mmap_gtt.Chris Wilson
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>
2009-12-05intel: Expect caller to guarantee thread-safety of bo during relocChris Wilson
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>
2009-12-02intel: Free memory before inserting bo into cache.Chris Wilson
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>
2009-12-02intel: Check and propagate errors from building reloc-treeChris Wilson
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>
2009-12-02intel: Repeat execbuffer after EINTRChris Wilson
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>
2009-12-02intel: Review use of errno.Chris Wilson
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>
2009-12-02intel: Make bo_reference() inline for internal use.Chris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2009-12-02intel: Remove the extra reference while validating the reloc treeChris Wilson
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>
2009-12-01intel: Wrap a few more syscalls with EINTR protectionChris Wilson
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>
2009-11-30intel: Clear bo->used_as_reloc_target flag on destroyChris Wilson
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>
2009-11-30intel: Apply pessimistic alignment to in-aperture buffer sizeChris Wilson
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>
2009-11-30intel: Only store a buffer in the cache if it is retained.Chris Wilson
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>
2009-11-20Merge remote branch 'origin/master' into libdrmKristian Høgsberg
2009-11-17Move libdrm/ up one levelKristian Høgsberg