| Age | Commit message (Collapse) | Author |
|---|
|
The empty string used for the not case is replaced by the default
if-else clause and so causes the configure to fail in the absence of
valgrind. Which is not quite what was intended.
Instead use the common idiom of setting a variable depending on whether
the true or false branch is taken and emit the conditional code as a
second step.
Reported-by: Tobias Jakobi <liquid.acid@gmx.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
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>
|
|
|
|
Commit efd6e81e inadvertently broke the build by looking for "i?86" or
"x86_64" in $host_os. The correct variable to check is $host_cpu.
This was preventing libdrm_intel.so from being built.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
|
|
This fixes a failure in 'make check' found by the tinderbox when trying to
build this code on Linux/ppc. This code is only designed to run on
Intel platforms, so don't even bother building it if we're not in that set.
Found-by: Tinderbox
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
|
|
|
|
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Yet another release required for new API
|
|
So that we can pull a couple of Intel bug fixes into xf86-video-intel.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Initial test only include ttm test for stressing ttm memory
allocations.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
Push the new Intel API for use by mesa.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Push the new Intel API for use by mesa.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Replace some deprecated autoconf macros and use the new libtool
syntax
|
|
New kernel headers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
|
|
To export new kernel API for Intel's 2010Q4 release.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
For the upcoming 2.4.22 release.
|
|
|
|
|
|
Simple test for event frequency.
|
|
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
|
A few good fixes landed, get them out there.
|
|
Fixes problem that libdrm_radeon was disabled in Makefile even when configure
claimed that radeon was enabled.
Signed-off-by: Pauli Nieminen <suokkos@gmail.com>
|
|
atomic ops.
|
|
bo->referenced_in_cs is checked if bo is already in cs. Adding and removing
reference in bo is done with atomic operations to allow parallel access to a
bo from multiple contexts.
cs->id generation code quarentees there is not duplicated ids which limits
number of cs->ids to 32. If there is more cs objects rest will get id 0.
V2:
- Fix configure to check for atomics operations if libdrm_radeon is only selected.
- Make atomic operations private to libdrm.
This optimization decreases cs_write_reloc share of torcs profiling from 4.3%
to 2.6%.
Tested-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Pauli Nieminen <suokkos@gmail.com>
|
|
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>
|
|
The primary motivation of this release is to expose the new execbuf2
Intel API.
|
|
|
|
|
|
The primary motivation of the release is the bug fix in commit
4f0f871730b76730ca58209181d16725b0c40184
|
|
|
|
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
|
|
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
|
|
|
|
|
|
Conflicts:
configure.ac
|
|
|
|
|
|
|
|
|
|
|
|
Oops, I assumed intel was always enable, but it just defaults to on.
|
|
|
|
|
|
|
|
|
|
|
|
|
