| dfd536c60d0bdffe005e354be0677f066af94f83 |
|
27-Jan-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Export a function to re-enable implicit synchronisation
Implicit synchronisation is the default behaviour of the kernel when
rendering with an execobject. It may be disabled with
drm_intel_gem_bo_disable_implicit_sync(), and then to restore it use
drm_intel_gem_bo_enable_implicit_sync().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 22cfd0431131538ad1953af86f7cc2d48af176d4 |
|
27-Jan-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Clear execobject flags before preserving object in reuse cache
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| c4b00767a7f3b2d00c7b1bc61e2b4d13f90c10ca |
|
20-Aug-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Support passing of explicit fencing from execbuf
Allow the caller to pass in an fd to an array of fences to control
serialisation of the execbuf in the kernel and on the GPU, and in return
allow creation of a fence fd for signaling the completion (and flushing)
of the batch. When the returned fence is signaled, all writes to the
buffers inside the batch will be complete and coherent from the cpu, or
other consumers. The return fence is a sync_file object and can be
passed to other users (such as atomic modesetting, or other drivers).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 1bd35da961312aeb33fc7af586fa0d1f207a2d5f |
|
20-Aug-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Allow the client to control implicit synchronisation
The kernel allows implicit synchronisation to be disabled on individual
buffers. Use at your own risk.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 44f220ad6200dbccebea2287b874fda7665efe4d |
|
14-Jan-2017 |
Dongwon Kim <dongwon.kim@intel.com> |
intel: update global_name before HASH_ADD
bo->global_name should be updated first before a hash value
for the entry is calculated with it by HASH_ADD macro.
Signed-off-by: Dongwon Kim <dongwon.kim@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 1924b6704aa34bb3dd044b8e1e29558c521c6902 |
|
20-Nov-2016 |
Grazvydas Ignotas <notasas@gmail.com> |
libdrm: random typo fixes
Just some trivial boring typo fixes all over the tree.
READMEs and comments only.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 770f6bc424f93ab92f2c2f651615d02240f7387a |
|
26-Jan-2015 |
Robert Bragg <robert@sixbynine.org> |
intel: Add a getter for the intel_context ctx_id
Exposing the u32 context ID makes it possible to define new drm kernel
interfaces based on the same IDs that e.g. execbuf uses to identify a
gem context, that aren't themselves abstracted by libdrm but need to be
used by libdrm/drm_intel_context based clients such as (parts of) i-g-t
or Mesa.
For example this can be used to configure an i915-perf stream to collect
metrics for a specific context.
v2: s/drm_intel_gem_context_get_context_id/drm_intel_gem_context_get_id/
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 319108f9475f0165c9b4885efc8cf3b7e042b7fb |
|
09-Nov-2015 |
Neil Roberts <neil@linux.intel.com> |
intel: Allow some codenames in INTEL_DEVID_OVERRIDE
As well as allowing a hexadecimal PCI ID number, the
INTEL_DEVID_OVERRIDE environment variable can now contain one of a few
short codenames. The codenames are stored in a small table to map them
to a corresponding PCI ID. This makes it easier to use without having
to look up the PCI IDs manually.
The PCI IDs used are the same as those chosen for the -p option of
run.c in shader-db but SKL has been added as well.
Reviewed-by: Matt Turner <mattst88@gmail.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| fe4579e263c8da19f790cc5c5430e12d9b1687b5 |
|
24-Oct-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Look prime handle up in handle hash table
A slightly confused copy'n'paste from the open path where we pass in
handle but use it as a global name, in the prime handle-from-fd pass we
pass in handle and do mean handle!
References: https://bugs.freedesktop.org/show_bug.cgi?id=98416
Fixes: 2f23bf1b7b89 ("intel: Migrate handle/name lookups from linear lists...")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 9e24d0c54b162b443e3e144740deb0e1d5f8760b |
|
22-Sep-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Migrate handle/name lookups from linear lists to hashtables
Walking a linear list to find a matching PRIME handle or flinked name
does not scale and becomes a major burden with just a few objects.
That said, the fixed size hash is not much better, it just buckets the
look into a few separate chains rather than one long one.
References: https://bugs.freedesktop.org/show_bug.cgi?id=94631
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 455e9b491723b89b19b6efc6590fc9c5558f7858 |
|
01-May-2015 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Export raw GEM mmap interfaces
Export a set of interfaces to allow the caller to have precise control
over mapping the buffer - but still provide caching of the mmaps between
callers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 98887140e343493f01be7a1dec721c024bcf72c7 |
|
02-Aug-2016 |
Yang Rong <rong.r.yang@intel.com> |
intel: Export pooled EU and min no. of eus in a pool.
Update kernel interface with new I915_GETPARAM ioctl entries for
pooled EU and min no. of eus in a pool. Add a wrapping function
for each parameter. Userspace drivers need these values when decide
the thread count. This kernel enabled pooled eu by default for BXT
and for fused down 2x6 parts it is advised to turn it off.
But there is another HW issue in these parts (fused
down 2x6 parts) before C0 that requires Pooled EU to be enabled as a
workaround. In this case the pool configuration changes depending upon
which subslice is disabled and the no. of eus in a pool is different,
So userspace need to know min no. of eus in a pool.
V2: use return value as the query results.
ret < 0 when error, ret = 0 when not support, and ret > 0 indicate
query results.(Chris)
V3: Correct V2 errors.
Signed-off-by: Yang Rong <rong.r.yang@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 723a6944c0ba8f6b25302adbea40b9d662f7b8ea |
|
03-Apr-2016 |
Eric Engestrom <eric@engestrom.ch> |
intel: Fix spelling mistakes
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| b38a4b2326c1be5702f5cb73a53c0ed74c12d510 |
|
15-Dec-2015 |
Michał Winiarski <michal.winiarski@intel.com> |
intel: Restore formatting of offsets in debug statements
Using lower_32_bits and upper_32_bits macros was accidentally dropped in:
commit 8b4d57e7b75cb0bd01d11ad7f597909034a316aa
Author: Michał Winiarski <michal.winiarski@intel.com>
Date: Wed Sep 9 16:07:10 2015 +0200
intel: Add support for softpin
Let's restore previous, more readable format.
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 8b4d57e7b75cb0bd01d11ad7f597909034a316aa |
|
09-Sep-2015 |
Michał Winiarski <michal.winiarski@intel.com> |
intel: Add support for softpin
Softpin allows userspace to take greater control of GPU virtual address
space and eliminates the need of relocations. It can also be used to
mirror addresses between GPU and CPU (shared virtual memory).
Calls to drm_intel_bo_emit_reloc are still required to build the list of
drm_i915_gem_exec_objects at exec time, but no entries in relocs are
created. Self-relocs don't make any sense for softpinned objects and can
indicate a programming errors, thus are forbidden. Softpinned objects
are marked by asterisk in debug dumps.
Cc: Thomas Daniel <thomas.daniel@intel.com>
Cc: Kristian Høgsberg <krh@bitplanet.net>
Cc: Zou Nanhai <nanhai.zou@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 3350add5cc166b5d0e829377747bf6a94a4b0c09 |
|
03-Sep-2015 |
Michel Thierry <michel.thierry@intel.com> |
intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag)
Gen8+ supports 48-bit virtual addresses, but some objects must always be
allocated inside the 32-bit address range.
In specific, any resource used with flat/heapless (0x00000000-0xfffff000)
General State Heap (GSH) or Instruction State Heap (ISH) must be in a
32-bit range, because the General State Offset and Instruction State Offset
are limited to 32-bits.
The i915 driver has been modified to provide a flag to set when the 4GB
limit is not necessary in a given bo (EXEC_OBJECT_SUPPORTS_48B_ADDRESS).
48-bit range will only be used when explicitly requested.
Callers to the existing drm_intel_bo_emit_reloc function should set the
use_48b_address_range flag beforehand, in order to use full ppgtt range.
v2: Make set/clear functions nops on pre-gen8 platforms, and use them
internally in emit_reloc functions (Ben)
s/48BADDRESS/48B_ADDRESS/ (Dave)
v3: Keep set/clear functions internal, no-one needs to use them directly.
v4: Don't set 48bit-support flag in emit reloc, check for ppgtt type
before enabling set/clear function, print full offsets in debug
statements, using port of lower_32_bits and upper_32_bits from linux
kernel (Michał)
References: http://lists.freedesktop.org/archives/intel-gfx/2015-July/072612.html
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
Signed-off-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 0ec7f4423dcb6f80bee020f98fd319b092f90581 |
|
31-Aug-2015 |
Emil Velikov <emil.l.velikov@gmail.com> |
intel: introduce to_bo_gem() helper
...to minimise misuse of bo_gem.
If the variable is declared at the top of the function and then used
for two (or more) different contexts this can cause confusion and errors.
Just introduce a wrapper, which can be used in a once off situations.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 94425f627221c0f67503a9aa4dff3502725905b3 |
|
15-Aug-2015 |
Emil Velikov <emil.l.velikov@gmail.com> |
intel: error out on has_error in exec2
Just like we do for the original exec()
v2: move bo_gem declaration to the top of the function.
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| cf7e32bdf99740ae3249f100b5cb2f0de54a20ef |
|
15-Aug-2015 |
Emil Velikov <emil.l.velikov@gmail.com> |
intel: resolve shadowing warnings
v2: keep the bo_gem declaration in exec2() within the loop (Chris)
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| cf40cf05a4d7f3945d534790e7768a048adc3ab0 |
|
24-Jul-2015 |
Rafał Sapała <rafal.a.sapala@intel.com> |
intel: Serialize drmPrimeFDToHandle with struct_mutex
It is possible to hit a race condition in create_from_prime, when trying
to import a BO that's currently being freed. In case of prime sharing
we'll succesfully get a handle, but fail on get_tiling call, potentially
confusing the caller (and requiring different locking scheme than with
sharing using flink). Wrap fd_to_handle with struct_mutex to force
a more consistent behaviour between prime/flink, convert fprintf to DBG
when handling errors.
(From Chris:
The race is that the kernel returns us the same file-private handle as
the first thread, but that first thread is about to call gem_close
(thereby removing the handle from the file completely) and does so
between us acquiring the handle and taking the mutex. If we take
the mutex, then we acquire the refcnt on the bo prior to the first
thread completing its unref (and so preventing the early close). Or we
acquire the handle after the earlier close, in which case we are the new
owner.
)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Testcase: igt/drm_import_export/import-close-race-prime
Signed-off-by: Rafał Sapała <rafal.a.sapala@intel.com>
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| cd2f91e18db087edf93fed828e568ee53b887860 |
|
31-Jul-2015 |
Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com> |
intel: Drop aub dumping functionality
We now have a separate tool for this in intel-gpu-tools and we don't
need to clutter up libdrm with this feature. We leave the entry points
in there to avoid breaking API/ABI.
Install intel-gpu-tools, then run (for example)
$ intel_aubdump --output=trace.aub glxgears -geometry 500x500
See the intel_aubdump man page for more details.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 5ba34e1aeed3c343bc9b53727220449d244b3296 |
|
11-Apr-2015 |
Anuj Phogat <anuj.phogat@gmail.com> |
Set alignment value in drm_intel_add_validate_buffer()
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 5c68f9f6f9bcc7edeacbc18b1052aed46a89c9f2 |
|
11-Apr-2015 |
Anuj Phogat <anuj.phogat@gmail.com> |
i965/gen9: Pass alignment as function parameter in drm_intel_gem_bo_alloc_internal()
In case of YF/YS tiled buffers libdrm need not know about the tiling
format because these buffers don't have hardware support to be tiled
or detiled through a fenced region. But, libdrm still need to know
about buffer alignment restrictions because kernel uses it when
resolving the relocation.
Mesa uses drm_intel_gem_bo_alloc_for_render() to allocate Yf/Ys buffers.
So, use the passed alignment value in this function to initialize the
align variable in drm_intel_bo. Note that we continue ignoring the
alignment value passed to drm_intel_gem_bo_alloc() to follow the
previous behavior.
V2: Add a condition to avoid allocation from cache. (Ben)
V3: Make no changes in cache allocation strategy. Just update the alignment.
Update the aperture size estimate including the alignment. (Ben, Chris)
V4: Move aperture size adjustments inside drm_intel_bo_gem_set_in_aperture_size()
Don't split sentences across the one-line header and the changelog. (Chris)
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 30921483c70c6939f017476eac13da6aa26b3b3c |
|
17-Apr-2015 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
intel: Leak the userptr test bo
In order to use userptr, the kernel tracks the owner's mm with a
mmu_notifier. Setting that is very expensive - it involves taking all
mm_locks and a stop_machine(). This tracking lives only for as long as
the client is using userptr objects - so if the client allocates then
frees a userptr in a loop, we will be executing that heavyweight setup
everytime. To ammoritize this cost, just leak the test bo and the single
backing page we use for detecting userptr.
v2: Free the object and memory when bufmgr is destroyed.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 0f8da82500ec542e269092c0718479e25eaff5f6 |
|
31-Mar-2015 |
Emil Velikov <emil.l.velikov@gmail.com> |
drm: remove drm_public macro
Some compilers (like the Oracle Studio), require that the function
declaration must be annotated with the same visibility attribute as the
definition. As annotating functions with drm_public is no longer
required just remove the macro.
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Michel Dänzer <michel.daenzer@amd.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 42465feb9759ef5a6d79d7e628510cd0a081f913 |
|
05-Apr-2015 |
Emil Velikov <emil.l.velikov@gmail.com> |
drm: rename libdrm{,_macros}.h
Provide a more meaningful name, considering what it does.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 32258e4dbd32466b4286ab2ad7883b7cb90c105f |
|
04-Nov-2014 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Delay testing for userptr until first use
Running __mmu_notifier_register() is surprisingly expensive, so let's
not do that unless we have to.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| d556e068a7e4e9dfb57514244ae5f3e0eb9d0b39 |
|
10-Mar-2015 |
Jeff McGee <jeff.mcgee@intel.com> |
intel: Export total subslice and EU counts
Update kernel interface with new I915_GETPARAM ioctl entries for
subslice total and EU total. Add a wrapping function for each
parameter. Userspace drivers need these values when constructing
GPGPU commands. This kernel query method is intended to replace
the PCI ID-based tables that userspace drivers currently maintain.
The kernel driver can employ fuse register reads as needed to
ensure the most accurate determination of GT config attributes.
This first became important with Cherryview in which the config
could differ between devices with the same PCI ID.
The kernel detection of these values is device-specific. Userspace
drivers should continue to maintain ID-based tables for older
devices which return ENODEV when using this query.
v2: remove unnecessary include of <stdbool.h> and increment the
I915_GETPARAM indices to match updated kernel patch.
For: VIZ-4636
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Jeff McGee <jeff.mcgee@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| fcff9e21652c94444be565e915b117ee069227a9 |
|
06-Mar-2015 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
Revert "intel: Fix documentation for drm_intel_gem_bo_wait()"
This reverts commit 080b4929b7452dc1fea32ac1d32e7e571e7fb38b.
Chris noticed that "negative values wait forever" is indeed intended
behaviour and the issue is just that we didn't have a testcase (fixed
now) and that a regression slipped through (fixed and on track for all
stable kernels).
So lets undo the documentation change for consistency, since working
around kernel regressions isn't good. Practical impact is nil anyway.
v2: Add a note to docs that some kernels have been broken.
v3: Remove the random garbage included by accident.
Cc: Kristian Høgsberg <krh@bitplanet.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 080b4929b7452dc1fea32ac1d32e7e571e7fb38b |
|
28-Feb-2015 |
Kristian Høgsberg <krh@bitplanet.net> |
intel: Fix documentation for drm_intel_gem_bo_wait()
The kernel doesn't actually wait indefinately when passed a negative,
timeout, it returns immediately. Document this and suggest using INT64_MAX
for indefinite waits.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| eb7a5b6b04271af3b11b81baa8e18dc826b657dc |
|
11-Feb-2015 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
intel: Unconditionally clear ioctl structs
We really have to do this to avoid surprises when extending the ABI
later on. Especially when growing the structures.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 13fcc697ee194060f949449bf37491d8abd7119b |
|
08-Jan-2015 |
Zhenyu Wang <zhenyuw@linux.intel.com> |
intel: Fix GTT entry setup for aub dump
On recent emulator GTT entry setup for aub dump needs mem type as
GTT_ENTRY instead of NONLOCAL. NONLOCAL would write data in main
memory space which is wrong with new memory layout. GTT_ENTRY write
would setup GTT memory pool and other required internal buffers. With
this I can run aub dump on latest release without crash.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| ec65f8d71eb3eb065c7cadf4153138435ac3b388 |
|
08-May-2013 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Avoid overcounting fences when emitting self-referential relocs
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 4f44ecc6beeaac5064871d41dcc4693b8e313859 |
|
07-Nov-2014 |
Thomas Meyer <thomas@m3y3r.de> |
intel: Fix SIGSEGV in libdrm for heigth = 0 and width = 0
drm_intel_gem_bo_free() crashes because the list bo_gem->vma_list is not
yet initialised, but the error path tries to free it.
See also https://bugs.freedesktop.org/show_bug.cgi?id=75844
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| f1e15d1221288bcc010a743d46ffe37d4216dbea |
|
13-Feb-2013 |
Damien Lespiau <damien.lespiau@intel.com> |
intel/skl: Add gen9 to the buffer manager init
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 537b1ca8d53f985a2c3f1c20d0671d5e8be94fd0 |
|
07-Sep-2014 |
Emil Velikov <emil.l.velikov@gmail.com> |
intel: use drm_mmap/drm_munmap wrappers
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 77dce9a012c2bb9d152fe32458f17d3d5fc715a7 |
|
17-Sep-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
intel: Don't leak the test page in an has_userptr() error path
When handling the error on GEM_CLOSE, we weren't freeing the allocated
page. Plug that.
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 0fa1dbf6469dfd7b8cac4d924235b149ee83daf1 |
|
05-Aug-2014 |
Rafal Sapala <rafal.a.sapala@intel.com> |
intel: Adding locks for drm objects synchronization.
The changes make sure that members of the bufmgr_gem and bo_gem
name lists are sychronized between threads
when using the create from prime and create from name methods.
Signed-off-by: Rafal Sapala <rafal.a.sapala@intel.com>
Testcase: igt/drm_import_export
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| ae8edc7544e566084f7b958eb93c9109b471ca30 |
|
19-Jun-2014 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
intel: Add support for userptr objects
Allow userptr objects to be created and used via libdrm_intel.
At the moment tiling and mapping to GTT aperture is not supported
due hardware limitations across different generations and uncertainty
about its usefulness.
v2: Improved error handling in feature detection per review comments.
v3: Rebase on top of the drm_public addition, minor whitespace addition.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v3)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v1,v2)
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 86b37c61c78edd1353a3f76f678c39e2ec168771 |
|
12-Sep-2014 |
Lionel Landwerlin <lionel.g.landwerlin@intel.com> |
intel: make drm_intel_gem_bo_get_reloc_count() thread safe
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 88025ad808aa61b2d5db63b86fc9327aefdecc3b |
|
12-Sep-2014 |
Lionel Landwerlin <lionel.g.landwerlin@intel.com> |
intel: make bo_unreference() thread safe
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 743af59669386cb6e063fa4bd85f0a0b2da86295 |
|
12-Sep-2014 |
Lionel Landwerlin <lionel.g.landwerlin@intel.com> |
intel: make bufmgr_gem shareable from different API
When using Mesa and LibVA in the same process, one would like to be
able bind buffers from the output of the decoder to a GL texture
through an EGLImage.
LibVA can reuse buffers allocated by Gbm through a file descriptor. It
will then wrap it into a drm_intel_bo with
drm_intel_bo_gem_create_from_prime().
The problem at the moment is that both library get a different
drm_intel_bufmgr object when they call drm_intel_bufmgr_gem_init()
even though they're using the same drm file descriptor. As a result,
instead of manipulating the same buffer object for a given file
descriptor, they get 2 different drm_intel_bo objects and 2 different
refcounts, leading one of the library to get errors from the kernel on
invalid BO when one of the 2 library is done with a shared buffer.
This patch modifies drm_intel_bufmgr_gem_init() so, given a file
descriptor, it will look for an already existing drm_intel_bufmgr
using the same file descriptor and return that object.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 07fead4462b2d537d0c3cae69a09272fc426c598 |
|
31-Jul-2014 |
Maarten Lankhorst <maarten.lankhorst@canonical.com> |
intel: Use symbol visibility.
No exports changed for this driver.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| edf17dbdaa525fe3a9abbbfafa768c556cfd7af2 |
|
13-Jan-2014 |
Kenneth Graunke <kenneth@whitecape.org> |
intel: Create a new drm_intel_bo offset64 field.
The existing 'offset' field is unfortunately typed as 'unsigned long',
which is unfortunately only 4 bytes with a 32-bit userspace.
Traditionally, the hardware has only supported 32-bit virtual addresses,
so even though the kernel uses a __u64, the value would always fit.
However, Broadwell supports 48-bit addressing. So with a 64-bit kernel,
the card virtual address may be too large to fit in the 'offset' field.
Ideally, we would change the type of 'offset' to be a uint64_t---but
this would break the libdrm ABI. Instead, we create a new 'offset64'
field to hold the full 64-bit value from the kernel, and store the
32-bit truncation in the existing 'offset' field, for compatibility.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 02f93c21e6e1c3dad9d99349989daa84a8c0b5fb |
|
15-Jan-2014 |
Eric Anholt <eric@anholt.net> |
intel: Track whether a buffer is idle to avoid trips to the kernel.
I've seen a number of apps spending unreasonable amounts of time in
drm_intel_bo_busy during the buffer mapping process.
We can't track idleness in general, in the case of buffers shared
across processes. But this should significantly reduce our overhead
for checking for busy on things like VBOs.
Improves (unoptimized) glamor x11perf -f8text by 0.243334% +/-
0.161498% (n=1549), which has formerly been spending about .5% of its
time hitting the kernel for drm_intel_gem_bo_busy().
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 3d34fe24957576d77c88877ded22e8ab5d96ca4c |
|
27-Dec-2013 |
Ben Widawsky <benjamin.widawsky@intel.com> |
intel: Handle malloc fails in context create
The previous code would just use the potentially unallocated variable,
which is probably okay most of the time, but not very nice to the user
of the library.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 743372ea26ed38db3aeca4b545e867c1bc08370d |
|
27-Dec-2013 |
Ben Widawsky <benjamin.widawsky@intel.com> |
intel: squash unused variable 'bo_gem'
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| c3d96897de647bd5f6d4802c108a3f65a307d61b |
|
22-Nov-2013 |
Keith Packard <keithp@keithp.com> |
intel: Track known prime buffers for re-use
If the application sends us a file descriptor pointing at a prime
buffer that we've already got, we have to re-use the same bo_gem
structure or chaos will result.
Track the set of all known prime objects and look to see if the kernel
has returned one of those for a new file descriptor.
Also checks for prime buffers in the flink case.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 0c3fd8708fc54b4b46f5db20d34eb29508537b08 |
|
20-Nov-2013 |
Ian Romanick <ian.d.romanick@intel.com> |
intel: Use memset instead of VG_CLEAR
The ioctl expects that certain fields will be zeroed, so we should allow
the helper function to actually work in non-Valgrind builds.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reported-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 5a41b025042c42788977e67aea8d1bf3b59baae4 |
|
15-Nov-2013 |
Ian Romanick <ian.d.romanick@intel.com> |
intel: Add support for GPU reset status query ioctl
I would have just used the drmIoctl interface directly in Mesa, but the
ioctl needs some data from the drm_intel_context that is not exposed
outside libdrm.
This ioctl is in the drm-intel-next tree as b635991.
v2: Update based on Mika's kernel work.
v3: Fix compile failures from last-minute typos. Sigh.
v4: Import the actual changes from the kernel i915_drm.h. Only comments
on some fields of drm_i915_reset_stats differed. There are still some
deltas between the kernel i915_drm.h and the one in libdrm, but those
can be resolved in other patches.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> [v3]
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| da738d1ed0a0941a0cd061395ad86072171b3242 |
|
08-Nov-2013 |
Dave Airlie <airlied@redhat.com> |
Revert "intel: Add support for GPU reset status query ioctl"
This reverts commit 6335e1d28c422050024bcf4100c4fb3a5bac2afb.
No taxation without representation, in other words no userspace without kernel
stuff being in a stable location, either drm-next but I'll accept drm-intel-next
for intel specific stuff.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 6335e1d28c422050024bcf4100c4fb3a5bac2afb |
|
10-Sep-2012 |
Ian Romanick <ian.d.romanick@intel.com> |
intel: Add support for GPU reset status query ioctl
I would have just used the drmIoctl interface directly in Mesa, but the
ioctl needs some data from the drm_intel_context that is not exposed
outside libdrm.
v2: Update based on Mika's kernel work.
v3: Fix compile failures from last-minute typos. Sigh.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| dad3c6b9791920f2bda1193d76f260827c4cd3f1 |
|
15-Feb-2013 |
Damien Lespiau <damien.lespiau@intel.com> |
intel/bdw: Update MI_BATCH_BUFFER_START for aub dumps
The command now takes a 48bits address and is thus 1 dword longer.
v2 (Ben): commit message: s/byte/dword (Eric)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| a0c126dcedb8be64c644321c2b2836723117064b |
|
15-Feb-2013 |
Kenneth Graunke <kenneth@whitecape.org> |
intel/bdw/aub: Update AUB trace block writes for 48-bit addressing.
Since our aub file dumping's GTT handling is totally fake, we always put
everything in the low 4GB anyway and shouldn't ever need to set
AddressHigh to anything other than 0.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
[ben: slight commit message change]
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 5b348f3ac0069485ecd86ee30483646fad4b01cc |
|
13-Feb-2013 |
Ben Widawsky <ben@bwidawsk.net> |
intel/bdw: Handle gen8 bufmgr_init
[bwidawsk: Added Damien's SOB]
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 9c52c3dc4763336884277d8005eac7e6efb77600 |
|
10-Oct-2013 |
Kristian Høgsberg <krh@bitplanet.net> |
intel: Set bo size from lseek if kernel supports it
The various create and open functions set the buffer size, but
drm_intel_bo_gem_create_from_prime() is an exception. In the 3.12 kernel
we can now use lseek on the prime fd to determine the size of the bo.
Use that and override the userprovided size. If the kernel doesn't
support this, we get an error and fall back to the user provided size.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| fea5408098c3c3057958e85ea9d7146f0b08749e |
|
10-Jul-2013 |
Chia-I Wu <olvaffe@gmail.com> |
intel: silence valgrind warnings for unsynchronized maps
Mark the address ranges as accessible with VALGRIND_MAKE_MEM_DEFINED.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| fbd106ad76b0ee33814f6a5b94efaa0b067ec2af |
|
20-Feb-2013 |
Damien Lespiau <damien.lespiau@intel.com> |
intel/aub: Implement a way to specify the output .aub filename
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 1e4f63bbc8e9a23c90745e10027e2772bab15038 |
|
20-Feb-2013 |
Damien Lespiau <damien.lespiau@intel.com> |
intel/aub: Return early if we disable aub dumps
No need to prepare the .aub header and dump in that case, it'll be
done with the next call with true.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 011999927f76a7e9ba8f047fae4b4e084da6c2c3 |
|
13-Nov-2012 |
Xiang, Haihao <haihao.xiang@intel.com> |
intel: Add support for VEBOX ring (v2)
v2: Fix the test for has_vebox
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 3b5cc135424f3b8d6b79fb409fe9b4ffc4855333 |
|
13-Jan-2013 |
Kenneth Graunke <kenneth@whitecape.org> |
intel/aub: Actually run BLT batches on the blit ring.
We didn't set the ring flag for BLT batches, so they got run on the
render ring. Shenanigans ensued, especially when we sent commands that
were only valid on the BLT ring.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| fdda97007b1dbf95beb16a0e3510fd36c89e8c33 |
|
11-Jan-2013 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Remove the fence count contributions when clearing relocs
As we clear the relocs from the bo, we also need to clear the
contribution of the reloc_target_bo from the fence count. Otherwise they
are leaked and prevent any further relocations being added to the bo.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 7d42b49c0cf19dbb4531cd84efae51f95db2eea1 |
|
10-Nov-2012 |
David Shao <davshao@gmail.com> |
intel: Fix missing ETIME on BSD operating systems
Originally posted to Free Desktop bug #52549 by David Shao.
Resolves Gentoo Bug #433403.
Commit message by Richard Yao.
Reviewed-by: Richard Yao <ryao@gentoo.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
References: https://bugs.freedesktop.org/show_bug.cgi?id=52549
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| a83444c925b18b3db431336360d6915aaf21f727 |
|
07-Oct-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Silence a trivial compiler warning
intel_bufmgr_gem.c: In function 'drm_intel_bo_gem_export_to_prime':
intel_bufmgr_gem.c:2477:6: warning: unused variable 'ret' [-Wunused-variable]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 75830a0d2cbb614ecc3f7e6b516ec595bb41d6a3 |
|
07-Oct-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Fix "properly test for HAS_LLC"
commit 92fd0ce4f659d7b0680543e9e5b96a3c7737a5f3
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Aug 31 11:16:53 2012 +0200
intel: properly test for HAS_LLC
missed slightly and in effect had no effect on the outcome of checking
whether the kernel/chipset supported LLC.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 1b7ce582ceac74c7c5f1989c611b4f01a2a18434 |
|
14-Sep-2012 |
Kristian Høgsberg <krh@bitplanet.net> |
intel: Mark bo's exported to prime as not reusable
It's the same situation as flink and we need take the same precautions.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 92fd0ce4f659d7b0680543e9e5b96a3c7737a5f3 |
|
31-Aug-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
intel: properly test for HAS_LLC
If the kernel supports the test, we need to check the param.
Copy&pasta from the above checks that only look at the return value.
Interesting how much one can get such a simple interface wrong.
Issue created in
commit 151cdcfe685ee280a4344dfc40e6087d74a5590f
Author: Eugeni Dodonov <eugeni.dodonov@intel.com>
Date: Tue Jan 17 15:20:19 2012 -0200
intel: query for LLC support
Patch even claims to have fixed this in v2, but is actually unchanged
from v1.
Reported-by: Xiang, Haihao <haihao.xiang@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| a9412fa9de219e38df361852a12df37688c891db |
|
12-Aug-2012 |
Kenneth Graunke <kenneth@whitecape.org> |
intel: Use VG_CLEAR on the context destroy ioctl as well.
Otherwise pad appears uninitialized and valgrind grumbles.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 2607dad20b8dffce96608103def75d26ea0e42b2 |
|
02-Aug-2012 |
Eric Anholt <eric@anholt.net> |
intel: Add a function for the new register read ioctl.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 9a2b57d229fe3e6a1c9799e8cd5397969202d223 |
|
25-Jul-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Bail gracefully if we encounter an unknown Intel device
Otherwise we end up with X hitting a fail-loop as the embedded libGL
stacks asserts whilst initialising.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 7e3f08b463bcbae6950c07cc9ea29a7057f28e69 |
|
18-Jul-2012 |
Eric Anholt <eric@anholt.net> |
intel: Quiet valgrind warnings in context creation.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| c10b08d95954aecd331e5a43b4861c6c04b8aadd |
|
26-Jul-2012 |
Damien Lespiau <damien.lespiau@intel.com> |
intel: Remove two unused variables
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| ff65de96660965e661175f75427cd0020ef1104c |
|
15-Jul-2012 |
Dave Airlie <airlied@gmail.com> |
intel: add prime interface for getting/setting a prime bo. (v4)
This adds interfaces for the X driver to use to create a
prime handle from a buffer, and create a bo from a handle.
v2: use Chris's suggested naming (well from at least for consistency)
v3: git commit --amend fail
v4: fix as per Chris's suggestions, group assignments, add get tiling
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 992e2afd59539d169689bf21d78fac8b5cea4e3c |
|
12-Jul-2012 |
Kenneth Graunke <kenneth@whitecape.org> |
intel: Change context create failure message to from fprintf to DBG().
Since there is no getparam for hardware context support, Mesa always
tries to obtain a context by calling drm_intel_gem_context_create and
NULL-checking the result. On an older kernel without context support,
this caused libdrm to print an unwanted message to stderr:
DRM_IOCTL_I915_GEM_CONTEXT_CREATE failed: Invalid argument
In fact, this caused every Piglit test to fail with a "warn" status due
to the unrecognized error message.
Change the message to use DBG() rather than fprintf(), so people can
still get the debug message, but it won't spam normally.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| f7210fa4ecf6a5456aa5a6bcc0584d38b2c8449e |
|
13-Jan-2012 |
Ben Widawsky <ben@bwidawsk.net> |
intel/context: create/destroy implementation
Add relevant code to set up minimal state and call the appropriate
kernel IOCTLs.
This was missed in the previous cherry-picking for 2.3.36.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 3ed38714bd3792ccfc1089dd7bef84ab3dc9697d |
|
19-Mar-2012 |
Ben Widawsky <ben@bwidawsk.net> |
intel/context: new execbuf interface for contexts
To support this we extract the common execbuf2 functionality to be
called with, or without contexts.
The context'd execbuf does not support some of the dri1 stuff.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 971c080ac0eb8f0531fe3ebabc5b9e585db992b6 |
|
05-Jun-2012 |
Ben Widawsky <ben@bwidawsk.net> |
intel: wait render timeout implementation
int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t timeout_ns)
This should bump the libdrm version. We're waiting for context support
so we can do both features in one bump.
v2: don't return remaining timeout amount
use get param and fallback for older kernels
v3: only doing getparam at init
prototypes now have a signed input value
v4: update comments
fall back to correct polling behavior with new userspace and old kernel
v5: since the drmIoctl patch was not well received, return appropriate
values in this function instead. As Daniel pointed out, the polling
case (timeout == 0) should also return -ETIME.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| da02f72bc286fd8d669f3860bdd97a8d1a1c3015 |
|
04-May-2012 |
Paul Berry <stereotype441@gmail.com> |
intel: Add the ability to supply annotations for .aub files.
This patch adds a new function,
drm_intel_bufmgr_gem_set_aub_annotations(), which can be used to
annotate the type and subtype of data stored in various sections of
each buffer. This data is used to populate type and subtype fields
when generating the .aub file, which improves the ability of later
debugging tools to analyze the contents of the .aub file.
If drm_intel_bufmgr_gem_set_aub_annotations() is not called, then we
fall back to the old set of annotations (annotate the portion of the
batchbuffer that is executed as AUB_TRACE_TYPE_BATCH, and everything
else as AUB_TRACE_TYPE_NOTYPE).
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 5de5b7484a3a41554e16c02a544a45db5516b031 |
|
14-Mar-2012 |
Eric Anholt <eric@anholt.net> |
intel: Quiet two more valgrind complaints with recent changes.
These are more cases where valgrind doesn't understand what gets read
or written by our ioctls.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 99c73378a1b440bcf594742445dfe14ab1e89128 |
|
10-Feb-2012 |
Eric Anholt <eric@anholt.net> |
intel: Add support for (possibly) unsynchronized maps.
This improves the performance of Mesa's GL_MAP_UNSYNCHRONIZED_BIT path
in GL_ARB_map_buffer_range. Improves Unigine Tropics performance at
1024x768 by 2.30482% +/- 0.0492146% (n=61)
v2: Fix comment grammar.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 3a8884851b72af012a8cb2beea320f094a58e5eb |
|
28-Feb-2012 |
Eric Anholt <eric@anholt.net> |
intel: Fix error check for I915_PARAM_HAS_LLC.
drmIoctl returns -1 on error with errno set to the error value. Other
users of it in this file just check for != 0, and only use errno when
they need to send an error value on to the caller of the API.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| c9ce2edfc8d33e760667529250e86e93ff656c3d |
|
10-Mar-2012 |
Eric Anholt <eric@anholt.net> |
intel: Bump the copyright dates on the bufmgr files.
We've been hacking these constantly.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 4db16a9480af2c4f36eb8023193cd54545efbe54 |
|
12-Oct-2011 |
Eric Anholt <eric@anholt.net> |
intel: Add .aub file output support.
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 6e642db7f4a5628ed63ca3c479f06bd6f2ca3893 |
|
11-Oct-2011 |
Kenneth Graunke <kenneth@whitecape.org> |
intel: Add support for overriding the PCI ID via an environment variable
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 23eeb7e1e45417a5a84f826286dd982dba440cd3 |
|
09-Feb-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Detect cache domain inconsistency with valgrind
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 90b23cc24c19fbe131d84237c55311cafeb4ca21 |
|
09-Feb-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Mark up with valgrind intrinsics to reduce false positives
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 151cdcfe685ee280a4344dfc40e6087d74a5590f |
|
17-Jan-2012 |
Eugeni Dodonov <eugeni.dodonov@intel.com> |
intel: query for LLC support
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 592ac67626f6d69bd8b518a33e80e9c4d223eba2 |
|
27-Jan-2012 |
Chad Versace <chad.versace@linux.intel.com> |
intel: Fix bufmgr_gem->gen for gen > 4
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 078bc5b6ee24ea786c465f5e29dcb8b0d2f81b2e |
|
20-Dec-2011 |
Eric Anholt <eric@anholt.net> |
intel: Make intel_chipset handle devid directly.
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 0ab2251b70d49a294d24f3ef54982e95226c104a |
|
14-Dec-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Reset vma list upon purge
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 015286f03e871ccf49af9f2ceef7f5e04c8d61ca |
|
11-Dec-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Remove the fresh assertions used to debug the vma cacheing
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| c5f0ed1d296f11367febd0e1b7dce8789308bf35 |
|
13-Dec-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Update map-count for an early error return during mapping
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| dd9a5b4f7fb07c78db4e7481bedca1b981030e3f |
|
06-Dec-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Evict cached VMA in order to make room for new mappings
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| e4b60f29609e9993dc7268993da509530862aa78 |
|
05-Dec-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Add an interface to limit vma caching
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 5c5332bbc38ff25c06081ac53a15ad583ad4cbc4 |
|
05-Dec-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Clean up mmaps on freeing the buffer
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| c549a777c1b6227a724942c64aa5cd181eb93c6c |
|
05-Dec-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Unmap buffers during drm_intel_gem_bo_unmap
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 36cff1cbb89477c839588a7e40fec2a8db7df396 |
|
04-Dec-2011 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
intel: limit aperture space to mappable area on gen3
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| d0ae6837d117881d9f1f9cc12d3f1012b6a46103 |
|
28-Oct-2011 |
Eric Anholt <eric@anholt.net> |
intel: Share the implementation of BO unmap between CPU and GTT mappings.
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 4cb01eeccfa6a5169edea07c339117cac1f7b261 |
|
28-Oct-2011 |
Eric Anholt <eric@anholt.net> |
intel: Don't call the SW_FINISH ioctl unless a CPU-mapped write was done.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 77dc16f33d19195c7f7c569d877a6180ed1b9d54 |
|
28-Oct-2011 |
Eric Anholt <eric@anholt.net> |
intel: Remove stale comment.
This used to be next to some map refcounting code, but that is long dead.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 515cea6ac67eb458c59fececc3c67411ee6fd3c3 |
|
22-Oct-2011 |
Eric Anholt <eric@anholt.net> |
intel: Add an interface for removing relocs after they're added.
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 2c2bdb36c5b6bd7f8eac07cf163975b361114fb1 |
|
22-Oct-2011 |
Eric Anholt <eric@anholt.net> |
intel: Use stdbool.h for dealing with boolean values.
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 194aa1bee632c6dce19238664eb8373e3483de55 |
|
22-Sep-2011 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: y tiling on i915G/i915GM is different
Luckily the kernel has become extremely paranoid about such matters.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 630dd26fb41c64c1e61be6e929e025c1528e9046 |
|
22-Sep-2011 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/intel: don't clobber bufmgr->pci_device
Otherwise it's pretty hard to differentiate the different chipset
variants.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 06ebbf7c2c071c8a4f32d3cfac914874fe981054 |
|
26-Mar-2011 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
Cleanup gen2 tiling confusion
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| e6018c25ca63fa6066d8fa6e57373030d07b0392 |
|
22-Feb-2011 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
intel: Fixup for the fix for relaxed tiling on gen2
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 9a71ed93f48f4b319148913a6b56751f6341f078 |
|
22-Feb-2011 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
intel: fix relaxed tiling on gen2
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 36d4939343d8789d9066f7245fa2d4fe69119dd8 |
|
14-Feb-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Remember named bo
... 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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 53581b6210c024044e0065527d1506e6f5657ef5 |
|
14-Feb-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Set the public handle after opening by name
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 0184bb1c6d946bcaf198f7680b3405adca676790 |
|
19-Dec-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Export CONSTANT_BUFFER addressing mode
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 537703fd4805e9cd352965fce642670986822d22 |
|
07-Dec-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Reorder need_fence vs fenced_command to avoid fences on gen4
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| af3d282afbd3360245c2ef2d3552b2530f67481d |
|
03-Dec-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: If the command is fenced inform the kernel
... but only account for a fenced used if the object is tiled.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 51b895041c65f7ec9ecda48e79279dde29258b07 |
|
22-Nov-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Compute in-aperture size for relaxed fenced objects
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 877b2ce15b80975b4dac42657bdfb0a3da833e1c |
|
09-Nov-2010 |
Eric Anholt <eric@anholt.net> |
intel: Fix drm_intel_gem_bo_wait_rendering to wait for read-only usage too.
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.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 49447a9b957047db2549b8a929e763bbd87808ba |
|
07-Nov-2010 |
Albert Damen <albrt@gmx.net> |
intel: initialize bufmgr.bo_mrb_exec unconditionally
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| a52e61b5c888444435929a2770f14109c3a94f2f |
|
02-Nov-2010 |
Eric Anholt <eric@anholt.net> |
intel: Drop silly asserts on mappings present at unmap time.
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.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 4abb65f95c79c9a2ec2cc1147a753704b5cdd22e |
|
02-Nov-2010 |
Eric Anholt <eric@anholt.net> |
intel: Remove gratuitous assert on bo_reference.
This couldn't be triggered except by overflow, since there's an assert
in unreference to catch the usual failure of over-unreferencing.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 6560b4766c37603f5167859513bdc300f89a4761 |
|
20-Sep-2010 |
Eric Anholt <eric@anholt.net> |
intel: Remove stale comment.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 362457715faacd3101929e5f0d8ae250d0ad09df |
|
29-Oct-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: enable relaxed fence allocation for i915
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 057fab3382c02af54126ce395c43d4e6dce9439a |
|
26-Oct-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Prepare for BLT ring split.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 96214860bb0a5e11e7d346351a1be248e3716144 |
|
01-Oct-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Downgrade error warnings to debug
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 6299722c478234a759b1ce748436197ca1a17ebf |
|
25-Sep-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Replace open-coded drmIoctl with calls to drmIoctl()
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| c3ddfea1a64b7aaaebfb429243c71feb0801da9d |
|
29-Jun-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Suppress the error return from setting domains after mapping.
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 726210f87d558d558022f35bc8c839e798a19f0c |
|
24-Jun-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Limit tiled pitches to 8192 on pre-i965.
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 6ea2bda5f5ec8f27359760ce580fdad3df0464df |
|
22-Jun-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Only adjust the local stride used for SET_TILING in tiled alloc
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| aba3502190a5bd2203e71ae2b1b7dd5aeb223905 |
|
22-Jun-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Restore SET_TILING for non-flinked bo.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| c7bbaca6a376f40d914d1ed33e119f2330701c9a |
|
22-Jun-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: '===' != '=='
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| cd34cbeb9f5c65b25d241700f27c16b36e1ecce6 |
|
22-Jun-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Sanitise strides for linear buffers and SET_TILING
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 13e8270504cffa96bd067dc5c792a79555e8b2d4 |
|
21-Jun-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Print out debugging message following ENOSPC
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| f16b4164d686893949daa3217a011d21c5bd7f95 |
|
21-Jun-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Scan the cache for old bo once every second.
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 5eec286838118501dd79178c152000ad4cbd70e1 |
|
21-Jun-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Force stride to be 0 for I915_TILING_NONE.
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 1db22ff741f92b84450ec13093e070a6ad5fc857 |
|
21-Jun-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Defer tiling change to allocation.
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 056aa9be04e923a45ca00924caa587d6dbf8821d |
|
21-Jun-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Track tiling stride
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 4f7704aea76b3d93d997d2ff815541d0ac373535 |
|
10-Jun-2010 |
Eric Anholt <eric@anholt.net> |
intel: Fix several other paths for buffers pointing at themselves.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 0ec768e67aec8b1ded9bcf575ad1c0beb28cc0ca |
|
05-Jun-2010 |
Eric Anholt <eric@anholt.net> |
intel: Add more intermediate sizes of cache buckets between powers of 2.
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.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| e65caeba9ed0e6c53830d944248aaae2228351ab |
|
09-Jun-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Convert to untiled pitches if surface is too large for tiling.
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| f179137f8f5bf272b79266575121c7a04038290c |
|
07-Jun-2010 |
Eric Anholt <eric@anholt.net> |
Allow a buffer to point at itself and still get relocs.
I'm using this in experiments with the i965 Mesa driver.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 66375fd6e8d3e95df5d124883a1426460c1b8ed8 |
|
02-Jun-2010 |
Zou Nan hai <nanhai.zou@intel.com> |
intel: Add support for kernel multi-ringbuffer API.
This introduces a new API to exec on BSD ring buffer, for H.264 VLD
decoding.
Signed-off-by: Xiang Hai hao <haihao.xiang@intel.com>
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| fcf3e616eeeb289f96af1436d809f0a1a42bebb7 |
|
24-May-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Don't change tiling mode unless the kernel reports success.
Fixes:
Bug 26686 - Some textures are distorted with libdrm 2.4.18 in GTAVC>A3
http://bugs.freedesktop.org/show_bug.cgi?id=26686
This bug continues to haunt me. The kernel SET_TILING ioctl is
inconsistent in its return values when reporting an error. If one of its
sanity checks fail, then the input values are left unchanged. If the
kernel later fails to change the tiling mode, then the input values are
modified to match the current tiling on the object. In short, userspace
cannot trust the return values upon error and so we must assume that
upon error our current tiling mode matches reality and not update.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| a3305b076c005e0d3bd55da0214e91413cf65b48 |
|
13-May-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
Revert "intel: We don't need to take the bufmgr lock whilst mapping."
This reverts commit 7ca558494dd3f68f29bb6ca981de9b8f49620b60.
This was pushed ahead of an essential review of bo level locking in
mesa, without which we cannot know whether removing this lock is safe.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 07e7589d86624e9c1ca4c38d00cf6886e1445ae2 |
|
11-May-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: query whether a buffer is reusable.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 7ca558494dd3f68f29bb6ca981de9b8f49620b60 |
|
01-Apr-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: We don't need to take the bufmgr lock whilst mapping.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 3506173ba7e726a9d0a17ec42734a925a885b01e |
|
11-Apr-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Use the correct size when allocating reloc_target_info array
Thomas tracked down this error with kdm and commit b509640:
==4320== Invalid write of size 8
==4320== at 0x9A97998: do_bo_emit_reloc (in /usr/lib/libdrm_intel.so.1.0.0)
==4320== by 0x9A97B9C: drm_intel_gem_bo_emit_reloc (in /usr/lib/libdrm_intel.so.1.0.0)
==4320== by 0xAED3234: intel_batchbuffer_emit_reloc (in /usr/lib/xorg/modules/dri/i965_dri.so)
==4320== by 0xAF13827: brw_emit_vertices (in /usr/lib/xorg/modules/dri/i965_dri.so)
==4320== by 0xAF1F14D: brw_upload_state (in /usr/lib/xorg/modules/dri/i965_dri.so)
==4320== by 0xAF12122: brw_draw_prims (in /usr/lib/xorg/modules/dri/i965_dri.so)
==4320== by 0xB256824: vbo_exec_vtx_flush (in /usr/lib/xorg/modules/dri/libdricore.so)
==4320== by 0xB2523BB: vbo_exec_FlushVertices_internal (in /usr/lib/xorg/modules/dri/libdricore.so)
==4320== by 0xB252411: vbo_exec_FlushVertices (in /usr/lib/xorg/modules/dri/libdricore.so)
==4320== by 0xB195A3D: _mesa_PopAttrib (in /usr/lib/xorg/modules/dri/libdricore.so)
==4320== by 0x8DF0F02: __glXDisp_Render (in /usr/lib/xorg/modules/extensions/libglx.xorg)
==4320== by 0x8DF517F: __glXDispatch (in /usr/lib/xorg/modules/extensions/libglx.xorg)
==4320== Address 0x126a8b80 is 0 bytes after a block of size 16,368 alloc'd
==4320== at 0x4C23E03: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4320== by 0x9A97A64: do_bo_emit_reloc (in /usr/lib/libdrm_intel.so.1.0.0)
==4320== by 0x9A97B9C: drm_intel_gem_bo_emit_reloc (in /usr/lib/libdrm_intel.so.1.0.0)
==4320== by 0xAED3234: intel_batchbuffer_emit_reloc (in /usr/lib/xorg/modules/dri/i965_dri.so)
==4320== by 0xAF191DB: upload_binding_table_pointers (in /usr/lib/xorg/modules/dri/i965_dri.so)
==4320== by 0xAF1F14D: brw_upload_state (in /usr/lib/xorg/modules/dri/i965_dri.so)
==4320== by 0xAF12122: brw_draw_prims (in /usr/lib/xorg/modules/dri/i965_dri.so)
==4320== by 0xB255EF6: vbo_exec_DrawArrays (in /usr/lib/xorg/modules/dri/libdricore.so)
==4320== by 0x8DF67A3: __glXDisp_DrawArrays (in /usr/lib/xorg/modules/extensions/libglx.xorg)
==4320== by 0x8DF0F02: __glXDisp_Render (in /usr/lib/xorg/modules/extensions/libglx.xorg)
==4320== by 0x8DF517F: __glXDispatch (in /usr/lib/xorg/modules/extensions/libglx.xorg)
==4320== by 0x446293: ??? (in /usr/bin/Xorg)
which is simply due to only allocating space for the pointers and not
the structs themselves. D'oh.
Reported-by: Thomas Bächler <thomas@archlinux.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 7c697b1670fe34b54a7b82d8ff0732845caa05a3 |
|
17-Mar-2010 |
Eric Anholt <eric@anholt.net> |
intel: Align untiled buffer pitch to 64B.
This is the largest untiled pitch requirement from gen2 through gen4.
It's only the case for gen3 rendering to color regions with depth, but
it's rare for this to be a significant factor in memory usage -- for
example, gen4 requires 1 or 2 times the element size, or up to 64
bytes depending on the size of the elements. This is easier than
encoding all the various little quirks for untiled pitch alignment,
since we rarely do untiled now.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 21105bc186d188f0bfc2f41c52b4b0ceb6742cf5 |
|
10-Mar-2010 |
Pauli Nieminen <suokkos@gmail.com> |
libdrm: Move intel_atomic.h to libdrm core for sharing.
intel_atomic.h includes very usefull atomic operations for
lock free parrallel access of variables. Moving these to
core libdrm for code sharing with radeon.
Signed-off-by: Pauli Nieminen <suokkos@gmail.com>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| a4041e096ce0faea3dd39b4d78014d45a8cacec0 |
|
07-Mar-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Repeat execbuffer if interrupted by signal
Repeat while EINTR, not EAGAIN! One more source of corruption
erradicated, hurray!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 1d4d1e6b138aac8bd734c4c20617a43fb3337c63 |
|
05-Mar-2010 |
Eric Anholt <eric@anholt.net> |
intel: Only align Y-tiling pitch to the Y tile width.
Fixes piglit depth-tex-modes on gen4.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 3e21e3ba0090c4dbe976269409b336dc82fe3d36 |
|
04-Mar-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Propagate some more error returns
Ensure that errors from the kernel are propagated back to the caller,
and not masked with return 0;
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 47102863eddee2fa6e28a922c072d0243ece6afd |
|
03-Mar-2010 |
Eric Anholt <eric@anholt.net> |
intel: Update the needs_fence flag of buffers on the validate list.
Fixes fbo-copyteximage on i915 with texture tiling and execbuf2 fenced
relocs.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 766fa7909f3a1af27e60f3529a6a3318cc406f67 |
|
03-Mar-2010 |
Eric Anholt <eric@anholt.net> |
intel: Don't enable execbuf2 fenced relocs unless we have execbuf2.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 292a5d73a244cec8f4d1042c6fec6618333c1e0e |
|
03-Mar-2010 |
Eric Anholt <eric@anholt.net> |
intel: Don't tile-align pitch for untiled buffers.
This allows Mesa to use drm_intel_bo_alloc_tiled() for its tiled
buffers, since it makes its decision about pitch before telling
libdrm. They happen to be the same choices for the tiled case.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| acbaff24e071dce0d23c057c9890f3aec732b8ec |
|
03-Mar-2010 |
Eric Anholt <eric@anholt.net> |
intel: Fix typo in conversion from IS_GEN to bufmgr_gem->gen.
Luckily I caught the bug with the first consumer of the interface.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| a0abb1b14ef60abfd1d5aacd83f06d6f94dc13a4 |
|
03-Mar-2010 |
Eric Anholt <eric@anholt.net> |
intel: add a comment about tiled buffer alloc height alignment from Mesa.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| a1f9ea765ddc5cad45e36c4931663b21992727ee |
|
02-Mar-2010 |
Eric Anholt <eric@anholt.net> |
intel: Use an integer for chipset generation instead of many conditionals.
Saves a bunch of comparisons in hot paths.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| b50964027bef249a0cc3d511de05c2464e0a1e22 |
|
15-Sep-2009 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
libdrm/intel: execbuf2 support
This patch to libdrm adds support for the new execbuf2 ioctl. If
detected, it will be used instead of the old ioctl. By using the new
drm_intel_bufmgr_gem_enable_fenced_relocs(), you can indicate that any
time a fence register is actually required for a relocation target you
will call drm_intel_bo_emit_reloc_fence instead of
drm_intel_bo_emit_reloc, which will reduce fence register pressure.
Signed-off-by: Eric Anholt <eric@anholt.net>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| f6dc964e1d4d43e4053b84b31e76d974af128276 |
|
23-Oct-2009 |
Eric Anholt <eric@anholt.net> |
intel: Add initial support for Sandybridge, and clean up the #defines.
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 4f0f871730b76730ca58209181d16725b0c40184 |
|
10-Feb-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Handle resetting of input params after EINTR during SET_TILING
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| fdcde592c2c48e143251672cf2e82debb07606bd |
|
09-Feb-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Account for potential pinned buffers hogging fences
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 973d8d6bd04230da801a8bc19af41dbc60e1918d |
|
02-Feb-2010 |
Dave Airlie <airlied@redhat.com> |
intel: check return value for calloc
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 08371bc29013370558728dcbeeed6a23ad2f5a70 |
|
08-Dec-2009 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Clear virtual after failing to mmap_gtt.
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 9707733a130098a7d9959e72ebd782d8119a23d3 |
|
02-Dec-2009 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Expect caller to guarantee thread-safety of bo during reloc
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 57473c7f523f476ffa54c34e0c6312ffa66dcc5c |
|
02-Dec-2009 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Free memory before inserting bo into cache.
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 792fed1e2460f96459141b5a628dd5ab4fbb87db |
|
02-Dec-2009 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Check and propagate errors from building reloc-tree
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| b73612e4fd69565aa2c5c2e9677f3e0af1945f7d |
|
02-Dec-2009 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Repeat execbuffer after EINTR
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| acb4aa671507aa181b3ff50ccf26a1c0d705a309 |
|
02-Dec-2009 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Review use of errno.
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 9fec2a8cb28d814da4fdd97b25e9cc5c10768c87 |
|
02-Dec-2009 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Make bo_reference() inline for internal use.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 9c8ad05e8bb1c954b804e40f2f975fed23c24550 |
|
02-Dec-2009 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Remove the extra reference while validating the reloc tree
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 8ffd2e142e38d19326a40ff66dc99d052ce22100 |
|
01-Dec-2009 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Wrap a few more syscalls with EINTR protection
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| b666f4151ab934d3083fa8b5f14ce19bbf999b15 |
|
01-Dec-2009 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Clear bo->used_as_reloc_target flag on destroy
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| e22fb797728c07fd05b195bd345fdf91bab47855 |
|
30-Nov-2009 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Apply pessimistic alignment to in-aperture buffer size
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 60aa803dc76bbdfac72da4de4cdc3018717b0884 |
|
30-Nov-2009 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Only store a buffer in the cache if it is retained.
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>
/external/libdrm/intel/intel_bufmgr_gem.c
|
| 10ce0ec18806ae32a5d615c693626a085b0dd7b8 |
|
20-Nov-2009 |
Kristian Høgsberg <krh@bitplanet.net> |
Merge remote branch 'origin/master' into libdrm
|
| 4f57abfe66091281c9f59c14e6ea27b524b55d5b |
|
17-Nov-2009 |
Kristian Høgsberg <krh@bitplanet.net> |
Move libdrm/ up one level
/external/libdrm/intel/intel_bufmgr_gem.c
|