| Age | Commit message (Collapse) | Author |
|---|
|
And hasn't been in a long while.
Reviewed-by: Zack Rusin <zackr@vmware.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
|
|
|
|
|
|
It warns about totally sensible things done in intel_decode.c. I've
never seen this warn do anything useful, and apparently I was the one
to introduce it when I added the giant pile of warning flags back in
2008.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
|
|
There can be scenarios, especially when re-importing an existing buffer,
where you end up with multiple 'struct omap_bo's wrapping a single GEM
object handle. Which causes badness when the first of the evil-clones
is omap_bo_del()'d.
To do this, introduce reference counting and a hashtable to track the
handles per fd.
First, to avoid bo's slipping through the crack if multiple 'struct
omap_device's are created for one drm fd, a hashtable mapping drm
fd to omap_device, and the omap_device itself is reference counted.
Per omap_device, we keep a handle_table mapping GEM handle to omap_bo.
When buffers are imported from flink name or dmabuf fd, the handle
table is consulted, and if an omap_bo already exists, it's refcnt is
incremented and it is returned. For good measure, to avoid the
handle_table being deleted before the omap_bo is freed, the omap_bo
holds a reference to the omap_device.
TODO: check the overhead of the hashtable. If too much we could maybe
get away with only tracking exported and imported bo's in the table.
TODO: all the import/export flink/dmabuf operations are generic DRM
ioctls. Really all this functionality could be handled by a generic
drm_bo and drm_device "base class" that could be extended by omap,
exynos, etc. That would also allow more common userspace code by
avoiding artificial libdrm_omap dependencies.
Signed-off-by: Rob Clark <rob@ti.com>
|
|
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
|
|
I mistakenly "fixed" a bad decode with
commit 7d0a1d5ebbe2c6aecd96eef94b0af038858a0178
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Sun Jun 24 20:35:57 2012 -0700
intel/decode: VERTEX_ELEMENT_STATE, 1 means valid
However the actual fix is just to update the reference file, and
include GEN7 in the decode.
Props to Eric Anholt for putting the test in distcheck, or else I
wouldn't have caught this.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
|
|
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
this patch adds libdrm_exynos helper layer that inclues some intefaces
for exynos specific gem and virtual display driver and also adds exynos
module name to modtest and vbltest.
Changelog v2:
- fixed exynos broken ioctl.
the pointer of uint64_t *edid should be removed.
- removed unnecessary definitions.
- added drm prime interfaces.
this feature is used to share a buffer between drivers or memory managers
and for this, please, refer to below links:
http://www.mjmwired.net/kernel/Documentation/dma-buf-sharing.txt
http://lwn.net/Articles/488664/
this patch is based on a link below:
git://anongit.freedesktop.org/mesa/drm
commit id: d72a44c7c4f5eea9c1e5bb0c36cb9e0224b9ca22
Reviewed-by: Rob Clark <rob@ti.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Rob Clark <rob@ti.com>
|
|
|
|
Redesigned primarily to allow us to better take advantage of BO's having
fixed GPU virtual addresses on GeForce 8 and up, and to reduce the overhead
of handling relocations on earlier chipsets.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Christoph Bumiller <e0425955@student.tuwien.ac.at>
|
|
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
This adds libdrm_omap helper layer (as used by xf86-video-omap,
omapdrmtest, etc).
Signed-off-by: Rob Clark <rob@ti.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
[danvet: pushed for Rob, he doesn't yet have commit access.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
|
|
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
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>
|
