| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use the external implementation for atomic operations across a wide
range of architectures.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Only build libdrm_intel automatically if we have support for atomic
operations. To force configure to build drm pass --enable-intel, which
will cause the configure to error if no support is found. Or pass
--disable-intel to explicitly prevent libdrm_intel from being built.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
|
|
In conjunction with the atomic operation patch, it may be more
convenient for some people to disable building libdrm-intel and its
dependencies upon the atomic intrinsics then it is for them to use a
supported compiler.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As the target architecture for Intel GPUs is the x86, we can presume to
have reasonable compiler support for Intel atomic intrinsics, i.e. gcc,
and so use those in preference to pulling in a complicated mess of
fragile assembly.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[anholt: hand-resolved against my previous commit. This brings cairo-gl
firefox-talos-gfx time from 65 seconds back down to 62 seconds.]
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
|
|
|
|
|
|
this was giving me a warning on automake 1.11
|
|
Not sure what I was thinking.
|
|
Several POSIX extensions are used in the libdrm code (e.g., mknod and ffs).
Set _XOPEN_SOURCE and _GNU_SOURCE to something reasonable to ensure that
prototypes for these functions are available. This is done in configure.ac
using AC_USE_SYSTEM_MACROS. This requires autoconf 2.60 or later. Eventually
the code should check for the existance of these defines and do something
reasonable if they are not available.
Inspired by a patch by Pauli Nieminen and suggestions from Julien Cristau.
Thanks.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
requires --enable-radeon-experimental-api for now
|
|
The convention is that all APIs are per-bufmgr, so make this one the same.
Then, have it return -1 on failure so that the application can know what's
going on and do something sensible.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
New API, new version.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Who needs 2.4.8 anyway?
|
|
|
|
|
|
|
|
This version includes GTT unmap support for the Intel bufmgr.
|
|
|
|
Tylo.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
|
|
|
|
libdrm isn't supposed to ship APIs not present in a released kernel.
|
