Merge the create_test_buffer() and create_grey_buffer() functions into a
single buffer allocation function that takes the pixel format and fill
pattern as parameters.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
CCLD test_decode
./.libs/libdrm_intel.so: undefined reference to `drmPrimeHandleToFD'
./.libs/libdrm_intel.so: undefined reference to `drmPrimeFDToHandle'
collect2: ld returned 1 exit status
From Adam Jackson's explaination:
most distros have changed it so ld defaults to --no-copy-dt-needed-entries,
so if you use something from libdrm you can't just assume libdrm_intel
will bring it in for you, you have to be explicit
Signed-off-by: Rob Clark <rob@ti.com>
This adds interfaces for the X driver to use to create a
prime handle from a buffer, and create a bo from a handle.
v2: use Chris's suggested naming (well from at least for consistency)
v3: git commit --amend fail
v4: fix as per Chris's suggestions, group assignments, add get tiling
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
These are just basic ioctl wrappers around the prime ioctls,
along with the capability reporting.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This just moves over some missing caps from the kernel.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
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>
Since there is no getparam for hardware context support, Mesa always
tries to obtain a context by calling drm_intel_gem_context_create and
NULL-checking the result. On an older kernel without context support,
this caused libdrm to print an unwanted message to stderr:
DRM_IOCTL_I915_GEM_CONTEXT_CREATE failed: Invalid argument
In fact, this caused every Piglit test to fail with a "warn" status due
to the unrecognized error message.
Change the message to use DBG() rather than fprintf(), so people can
still get the debug message, but it won't spam normally.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Hi list
The recently released libdrm 2.4.37 does not compile the Intel part:
test_decode.c: In function 'compare_batch':
test_decode.c:107: error: implicit declaration of function 'open_memstream'
PS: Please CC me.
Signed-off-by: Lauri Kasanen <cand@gmx.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Add relevant code to set up minimal state and call the appropriate
kernel IOCTLs.
This was missed in the previous cherry-picking for 2.3.36.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
I mistakenly "fixed" a bad decode with
commit 7d0a1d5ebb
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>
To support this we extract the common execbuf2 functionality to be
called with, or without contexts.
The context'd execbuf does not support some of the dri1 stuff.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t timeout_ns)
This should bump the libdrm version. We're waiting for context support
so we can do both features in one bump.
v2: don't return remaining timeout amount
use get param and fallback for older kernels
v3: only doing getparam at init
prototypes now have a signed input value
v4: update comments
fall back to correct polling behavior with new userspace and old kernel
v5: since the drmIoctl patch was not well received, return appropriate
values in this function instead. As Daniel pointed out, the polling
case (timeout == 0) should also return -ETIME.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On r6xx or evergreen z/stencil surface don't support linear or
linear aligned surface, force 1D tiled mode for those.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Valgrind can't understand some of the fields passed to ioctls are overwritten
by kernel, so we need to initialize them. Almost all of our ioctl wrappers
already do it and the cost of remaining 3 is very small.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
A bitmask property is similar to an enum. The enum value is a bit
position (0-63), and valid property values consist of a mask of
zero or more of (1 << enum_val[n]).
Signed-off-by: Rob Clark <rob@ti.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Certain cards report the the wrong bank setup which causes
surface init to fail in the ddx and leads to no accel.
If we hit an invalid tiling parameter, just set a default
value and disable 2D tiling.
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=43448
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
make headers_install in kernel. Copy to here.
v2: signed ns_timeout
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
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.txthttp://lwn.net/Articles/488664/
this patch is based on a link below:
git://anongit.freedesktop.org/mesa/drm
commit id: d72a44c7c4
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>
This patch adds a new function,
drm_intel_bufmgr_gem_set_aub_annotations(), which can be used to
annotate the type and subtype of data stored in various sections of
each buffer. This data is used to populate type and subtype fields
when generating the .aub file, which improves the ability of later
debugging tools to analyze the contents of the .aub file.
If drm_intel_bufmgr_gem_set_aub_annotations() is not called, then we
fall back to the old set of annotations (annotate the portion of the
batchbuffer that is executed as AUB_TRACE_TYPE_BATCH, and everything
else as AUB_TRACE_TYPE_NOTYPE).
Reviewed-by: Eric Anholt <eric@anholt.net>
This is the same list of PCI ids added by Alex Deucher in xf86-video-ati commit
aacbd629b02cbee3f9e6a0ee452b4e3f21376bd3.
This is needed since the addition of the surface allocator helper in
commit c51f7f0e46 ; it needs to differentiate
pre and post-R600 GPUs.
Therefore we should maintain another PCI id list.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=48138
Signed-off-by: Anisse Astier <anisse@astier.eu>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
In the future we'll have more than just connector properties, so create
a dump_prop function that can handle any property (instead of the
current dump_props function that only handles connector properties).
Also, make this function print a lot more information about the existing
properties.
Also change the printed indentation of the modes to make the output more
readable.
The previous function dump_props also segfaulted when we didn't have
enought permissions. The new function does not segfault in this case (by
checking for the return value of drmModeGetProperty).
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
24 (16 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 2 of 7
at 0x402994D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4A25950: drmMalloc (xf86drm.c:147)
by 0x4A2E26D: drmModeGetPlaneResources (xf86drmMode.c:951)
by 0x4025FF: dump_planes (modetest.c:276)
by 0x4052AF: main (modetest.c:1120)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Don't "continue" without freeing the connector.
192 bytes in 6 blocks are indirectly lost in loss record 6 of 12
at 0x4C2779D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4E30DD8: drmMalloc (xf86drm.c:147)
by 0x4E35024: drmAllocCpy (xf86drmMode.c:73)
by 0x4E35D69: drmModeGetConnector (xf86drmMode.c:507)
by 0x402F22: dump_connectors (modetest.c:181)
by 0x40261B: main (modetest.c:801)
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>