summaryrefslogtreecommitdiff
path: root/intel/intel_bufmgr_gem.c
AgeCommit message (Collapse)Author
2012-03-09intel: Bump the copyright dates on the bufmgr files.Eric Anholt
We've been hacking these constantly.
2012-03-09intel: Add .aub file output support.Eric Anholt
This will allow the driver to capture all of its execution state to a file for later debugging. intel_gpu_dump is limited in that it only captures batchbuffers, and Mesa's captures, while more complete, still capture only a portion of the state involved in execution. This is a squash commit of a long series of hacking as we tried to get the resulting traces to work in the internal simulator. It contains contributions by Yuanhan Liu and Kenneth Graunke. v2: Drop the MI_FLUSH_ENABLE setup. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
2012-03-09intel: Add support for overriding the PCI ID via an environment variableKenneth Graunke
For example: export INTEL_DEVID_OVERRIDE=0x162 If this variable is set, don't actually submit the batchbuffer to the GPU, it probably contains commands for the wrong generation of hardware. v2: Introduce a getter for the overridden devid, and avoid getenv per exec. Reviewed-by: Yuanhan Liu <yuanhan.liu@linux.intel.com> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Eric Anholt <eric@anholt.net>
2012-02-15intel: Detect cache domain inconsistency with valgrindChris Wilson
Every access to either the GTT or CPU pointer is supposed to be proceeded by a set_domain ioctl so that GEM is able to manage the cache domains correctly and for the following access to be coherent. Of course, some people explicitly want incoherent, non-blocking access which is going to trigger warnings by this patch but are probably better served by explicit suppression. v2: Also mark the pointers as inaccessible following the explicit unmap and implicit unmap upon return to the cache. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-02-11intel: Mark up with valgrind intrinsics to reduce false positivesChris Wilson
In particular, declare the hidden CPU mmaps to valgrind so that it knows about those memory regions. v2: Add an additional VG_CLEAR for the getparam References: https://bugs.freedesktop.org/show_bug.cgi?id=35071 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Ben Widawsky <ben@bwidawsk.net> [anholt: Ideally valgrind should just learn about the ioctls, and removing the clear for the non-valgrindified code feels risky.] Reviewed-by: Eric Anholt <eric@anholt.net>
2012-02-01intel: query for LLC supportEugeni Dodonov
This adds support for querying the kernel about the LLC support in the hardware. In case the ioctl fails, we assume that it is present on GEN6 and GEN7. v2: fix the return code checking Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
2012-01-30intel: Fix bufmgr_gem->gen for gen > 4Chad Versace
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>
2011-12-29intel: Make intel_chipset handle devid directly.Eric Anholt
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>
2011-12-14intel: Reset vma list upon purgeChris Wilson
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>
2011-12-13intel: Remove the fresh assertions used to debug the vma cacheingChris Wilson
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>
2011-12-13intel: Update map-count for an early error return during mappingChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2011-12-06intel: Evict cached VMA in order to make room for new mappingsChris Wilson
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>
2011-12-05intel: Add an interface to limit vma cachingChris Wilson
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>
2011-12-05intel: Clean up mmaps on freeing the bufferChris Wilson
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>
2011-12-05intel: Unmap buffers during drm_intel_gem_bo_unmapChris Wilson
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>
2011-12-04intel: limit aperture space to mappable area on gen3Daniel Vetter
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>
2011-10-29intel: Share the implementation of BO unmap between CPU and GTT mappings.Eric Anholt
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>
2011-10-29intel: Don't call the SW_FINISH ioctl unless a CPU-mapped write was done.Eric Anholt
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2011-10-29intel: Remove stale comment.Eric Anholt
This used to be next to some map refcounting code, but that is long dead. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2011-10-28intel: Add an interface for removing relocs after they're added.Eric Anholt
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>
2011-10-28intel: Use stdbool.h for dealing with boolean values.Eric Anholt
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>
2011-09-22drm/i915: y tiling on i915G/i915GM is differentDaniel Vetter
Luckily the kernel has become extremely paranoid about such matters. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2011-09-22drm/intel: don't clobber bufmgr->pci_deviceDaniel Vetter
Otherwise it's pretty hard to differentiate the different chipset variants. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2011-03-26Cleanup gen2 tiling confusionDaniel Vetter
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>
2011-02-22intel: Fixup for the fix for relaxed tiling on gen2Daniel Vetter
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>
2011-02-22intel: fix relaxed tiling on gen2Daniel Vetter
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2011-02-14intel: Remember named boChris Wilson
... 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>
2011-02-14intel: Set the public handle after opening by nameChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-12-19intel: Export CONSTANT_BUFFER addressing modeChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-12-07intel: Reorder need_fence vs fenced_command to avoid fences on gen4Chris Wilson
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>
2010-12-03intel: If the command is fenced inform the kernelChris Wilson
... but only account for a fenced used if the object is tiled. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-11-22intel: Compute in-aperture size for relaxed fenced objectsChris Wilson
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>
2010-11-09intel: Fix drm_intel_gem_bo_wait_rendering to wait for read-only usage too.Eric Anholt
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.
2010-11-07intel: initialize bufmgr.bo_mrb_exec unconditionallyAlbert Damen
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>
2010-11-02intel: Drop silly asserts on mappings present at unmap time.Eric Anholt
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.
2010-11-02intel: Remove gratuitous assert on bo_reference.Eric Anholt
This couldn't be triggered except by overflow, since there's an assert in unreference to catch the usual failure of over-unreferencing.
2010-11-01intel: Remove stale comment.Eric Anholt
2010-10-29intel: enable relaxed fence allocation for i915Chris Wilson
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>
2010-10-26intel: Prepare for BLT ring split.Chris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-01intel: Downgrade error warnings to debugChris Wilson
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>
2010-09-25intel: Replace open-coded drmIoctl with calls to drmIoctl()Chris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-06-29intel: Suppress the error return from setting domains after mapping.Chris Wilson
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>
2010-06-24intel: Limit tiled pitches to 8192 on pre-i965.Chris Wilson
Fixes: Bug 28515 - Failed to allocate framebuffer when exceed 2048 width https://bugs.freedesktop.org/show_bug.cgi?id=28515 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-06-22intel: Only adjust the local stride used for SET_TILING in tiled allocChris Wilson
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>
2010-06-22intel: Restore SET_TILING for non-flinked bo.Chris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-06-22intel: '===' != '=='Chris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-06-22intel: Sanitise strides for linear buffers and SET_TILINGChris Wilson
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>
2010-06-21intel: Print out debugging message following ENOSPCChris Wilson
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>
2010-06-21intel: Scan the cache for old bo once every second.Chris Wilson
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>
2010-06-21intel: Force stride to be 0 for I915_TILING_NONE.Chris Wilson
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>