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>
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>
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>
We want to be able to use the bufmgr from multiple threads for GL, and thus
we need to protect the internal structures.
The pthread-stubs package is used so that programs not linked against
pthreads get weak symbols to stubs and don't eat most of the cost.
We want to be able to use the bufmgr from multiple threads for GL, and thus
we need to protect the internal structures.
The pthread-stubs package is used so that programs not linked against
pthreads get weak symbols to stubs and don't eat most of the cost.
This patch allows you to --enable-udev, and will avoid having libdrm
make device nodes. If you are using udev, you should really --enable-udev
your libdrm.
We need a version to depend on from the other components that require GEM and
the bufmgr code. Some interfaces will be removed before the 2.4.0 release.
