Age | Commit message (Collapse) | Author |
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|