Update kernel interface with new I915_GETPARAM ioctl entries for
subslice total and EU total. Add a wrapping function for each
parameter. Userspace drivers need these values when constructing
GPGPU commands. This kernel query method is intended to replace
the PCI ID-based tables that userspace drivers currently maintain.
The kernel driver can employ fuse register reads as needed to
ensure the most accurate determination of GT config attributes.
This first became important with Cherryview in which the config
could differ between devices with the same PCI ID.
The kernel detection of these values is device-specific. Userspace
drivers should continue to maintain ID-based tables for older
devices which return ENODEV when using this query.
v2: remove unnecessary include of <stdbool.h> and increment the
I915_GETPARAM indices to match updated kernel patch.
For: VIZ-4636
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Jeff McGee <jeff.mcgee@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
This reverts commit 080b4929b7.
Chris noticed that "negative values wait forever" is indeed intended
behaviour and the issue is just that we didn't have a testcase (fixed
now) and that a regression slipped through (fixed and on track for all
stable kernels).
So lets undo the documentation change for consistency, since working
around kernel regressions isn't good. Practical impact is nil anyway.
v2: Add a note to docs that some kernels have been broken.
v3: Remove the random garbage included by accident.
Cc: Kristian Høgsberg <krh@bitplanet.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
The kernel doesn't actually wait indefinately when passed a negative,
timeout, it returns immediately. Document this and suggest using INT64_MAX
for indefinite waits.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We really have to do this to avoid surprises when extending the ABI
later on. Especially when growing the structures.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
On recent emulator GTT entry setup for aub dump needs mem type as
GTT_ENTRY instead of NONLOCAL. NONLOCAL would write data in main
memory space which is wrong with new memory layout. GTT_ENTRY write
would setup GTT memory pool and other required internal buffers. With
this I can run aub dump on latest release without crash.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
drm_intel_gem_bo_free() crashes because the list bo_gem->vma_list is not
yet initialised, but the error path tries to free it.
See also https://bugs.freedesktop.org/show_bug.cgi?id=75844
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
When handling the error on GEM_CLOSE, we weren't freeing the allocated
page. Plug that.
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
The changes make sure that members of the bufmgr_gem and bo_gem
name lists are sychronized between threads
when using the create from prime and create from name methods.
Signed-off-by: Rafal Sapala <rafal.a.sapala@intel.com>
Testcase: igt/drm_import_export
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Allow userptr objects to be created and used via libdrm_intel.
At the moment tiling and mapping to GTT aperture is not supported
due hardware limitations across different generations and uncertainty
about its usefulness.
v2: Improved error handling in feature detection per review comments.
v3: Rebase on top of the drm_public addition, minor whitespace addition.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v3)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v1,v2)
When using Mesa and LibVA in the same process, one would like to be
able bind buffers from the output of the decoder to a GL texture
through an EGLImage.
LibVA can reuse buffers allocated by Gbm through a file descriptor. It
will then wrap it into a drm_intel_bo with
drm_intel_bo_gem_create_from_prime().
The problem at the moment is that both library get a different
drm_intel_bufmgr object when they call drm_intel_bufmgr_gem_init()
even though they're using the same drm file descriptor. As a result,
instead of manipulating the same buffer object for a given file
descriptor, they get 2 different drm_intel_bo objects and 2 different
refcounts, leading one of the library to get errors from the kernel on
invalid BO when one of the 2 library is done with a shared buffer.
This patch modifies drm_intel_bufmgr_gem_init() so, given a file
descriptor, it will look for an already existing drm_intel_bufmgr
using the same file descriptor and return that object.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
No exports changed for this driver.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The existing 'offset' field is unfortunately typed as 'unsigned long',
which is unfortunately only 4 bytes with a 32-bit userspace.
Traditionally, the hardware has only supported 32-bit virtual addresses,
so even though the kernel uses a __u64, the value would always fit.
However, Broadwell supports 48-bit addressing. So with a 64-bit kernel,
the card virtual address may be too large to fit in the 'offset' field.
Ideally, we would change the type of 'offset' to be a uint64_t---but
this would break the libdrm ABI. Instead, we create a new 'offset64'
field to hold the full 64-bit value from the kernel, and store the
32-bit truncation in the existing 'offset' field, for compatibility.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
I've seen a number of apps spending unreasonable amounts of time in
drm_intel_bo_busy during the buffer mapping process.
We can't track idleness in general, in the case of buffers shared
across processes. But this should significantly reduce our overhead
for checking for busy on things like VBOs.
Improves (unoptimized) glamor x11perf -f8text by 0.243334% +/-
0.161498% (n=1549), which has formerly been spending about .5% of its
time hitting the kernel for drm_intel_gem_bo_busy().
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The previous code would just use the potentially unallocated variable,
which is probably okay most of the time, but not very nice to the user
of the library.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
If the application sends us a file descriptor pointing at a prime
buffer that we've already got, we have to re-use the same bo_gem
structure or chaos will result.
Track the set of all known prime objects and look to see if the kernel
has returned one of those for a new file descriptor.
Also checks for prime buffers in the flink case.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The ioctl expects that certain fields will be zeroed, so we should allow
the helper function to actually work in non-Valgrind builds.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reported-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I would have just used the drmIoctl interface directly in Mesa, but the
ioctl needs some data from the drm_intel_context that is not exposed
outside libdrm.
This ioctl is in the drm-intel-next tree as b635991.
v2: Update based on Mika's kernel work.
v3: Fix compile failures from last-minute typos. Sigh.
v4: Import the actual changes from the kernel i915_drm.h. Only comments
on some fields of drm_i915_reset_stats differed. There are still some
deltas between the kernel i915_drm.h and the one in libdrm, but those
can be resolved in other patches.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> [v3]
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit 6335e1d28c.
No taxation without representation, in other words no userspace without kernel
stuff being in a stable location, either drm-next but I'll accept drm-intel-next
for intel specific stuff.
I would have just used the drmIoctl interface directly in Mesa, but the
ioctl needs some data from the drm_intel_context that is not exposed
outside libdrm.
v2: Update based on Mika's kernel work.
v3: Fix compile failures from last-minute typos. Sigh.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
The command now takes a 48bits address and is thus 1 dword longer.
v2 (Ben): commit message: s/byte/dword (Eric)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Since our aub file dumping's GTT handling is totally fake, we always put
everything in the low 4GB anyway and shouldn't ever need to set
AddressHigh to anything other than 0.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
[ben: slight commit message change]
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
The various create and open functions set the buffer size, but
drm_intel_bo_gem_create_from_prime() is an exception. In the 3.12 kernel
we can now use lseek on the prime fd to determine the size of the bo.
Use that and override the userprovided size. If the kernel doesn't
support this, we get an error and fall back to the user provided size.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Mark the address ranges as accessible with VALGRIND_MAKE_MEM_DEFINED.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No need to prepare the .aub header and dump in that case, it'll be
done with the next call with true.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We didn't set the ring flag for BLT batches, so they got run on the
render ring. Shenanigans ensued, especially when we sent commands that
were only valid on the BLT ring.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
As we clear the relocs from the bo, we also need to clear the
contribution of the reloc_target_bo from the fence count. Otherwise they
are leaked and prevent any further relocations being added to the bo.
Originally posted to Free Desktop bug #52549 by David Shao.
Resolves Gentoo Bug #433403.
Commit message by Richard Yao.
Reviewed-by: Richard Yao <ryao@gentoo.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
References: https://bugs.freedesktop.org/show_bug.cgi?id=52549
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
intel_bufmgr_gem.c: In function 'drm_intel_bo_gem_export_to_prime':
intel_bufmgr_gem.c:2477:6: warning: unused variable 'ret' [-Wunused-variable]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
commit 92fd0ce4f6
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Aug 31 11:16:53 2012 +0200
intel: properly test for HAS_LLC
missed slightly and in effect had no effect on the outcome of checking
whether the kernel/chipset supported LLC.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It's the same situation as flink and we need take the same precautions.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
If the kernel supports the test, we need to check the param.
Copy&pasta from the above checks that only look at the return value.
Interesting how much one can get such a simple interface wrong.
Issue created in
commit 151cdcfe68
Author: Eugeni Dodonov <eugeni.dodonov@intel.com>
Date: Tue Jan 17 15:20:19 2012 -0200
intel: query for LLC support
Patch even claims to have fixed this in v2, but is actually unchanged
from v1.
Reported-by: Xiang, Haihao <haihao.xiang@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise pad appears uninitialized and valgrind grumbles.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Otherwise we end up with X hitting a fail-loop as the embedded libGL
stacks asserts whilst initialising.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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>
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>
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>
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>
Jeff McGee
Daniel Vetter
Kristian Høgsberg
Zhenyu Wang
Chris Wilson
Thomas Meyer
Damien Lespiau
Emil Velikov
Rafal Sapala
Tvrtko Ursulin
Lionel Landwerlin
Maarten Lankhorst
Kenneth Graunke
Eric Anholt
Ben Widawsky
Keith Packard
Ian Romanick
Dave Airlie
Ben Widawsky
Chia-I Wu
Xiang, Haihao
David Shao
Dave Airlie