History log of /external/libdrm/intel/intel_bufmgr_gem.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
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&GTA3
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