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>
v2: Fold libpciaccess and libdrm into a single local_shared_libraries
Acked-by: Jan Vesely <jan.vesely@rutgers.edu>
Signed-off-by: Chih-Wei Huang <cwhuang@linux.org.tw>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
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>
v2: Add more PCI IDs (Michael H. Nguyen)
v3: Synchronize one more with the kernel PCI IDs (Damien)
Reviewed-by: Thomas Wood <thomas.wood@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: Michael H. Nguyen <michael.h.nguyen@intel.com>
Autotools is already smart enough to pick the *.pc.in files but it
needs some help with the Android.mk ones.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.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>
Contains the following patches squashed in:
commit 99247a5bd724ddcf0f06a5518baad207c53f1e2b
Author: Haitao Huang <haitao.huang@intel.com>
Date: Fri, 27 Apr 2012 13:20:53 -0500
Android.mk: use LOCAL_COPY_HEADERS to export headers.
Export necessary header files used by other components for
Android, such as libva intel-driver, gralloc, hwcomposer, etc.
Change-Id: I2feabf6941379ef4d756e942f30eba059de641f1
Signed-off-by: Haitao Huang <haitao.huang@intel.com>
[chad: Fixed inconsistent indentation.]
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
commit 7d0b528cb69995d7ea4e29b2daa1e3b28a362f42
Author: Emil Velikov <emil.l.velikov@gmail.com>
Date: Sun, 27 Jul 2014 18:22:41 +0100
android: reuse headers lists, separate libdrm from intel headers
Rather than having a duplicate copy of the headers list(s),
reuse the existing one(s). Distinguish that the intel headers
should be copied when libdrm_intel is used.
v2 Rename the headers variable(s) to *_H_FILES.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
commit 361de3ba4cadd5357596d1537bb3f216d281532b
Author: Piotr Luc <piotr.luc@intel.com>
Date: Fri, 14 Jun 2013 13:00:39 +0200
Export include dir from libdrm
BZ: 116218
Google introduced new method of specifying include path(s)
between modules. This allows a module to include header from a
library without directly specifyining by includer the path where
headers are located.
The method requires from library that holds headers to export
include path(s) in LOCAL_EXPORT_C_INCLUDE_DIRS variable.
These exported include path(s) are automatically added to
include path(s) of modules that have name of the library in the
LOCAL_SHARED_LIBRARIES or LOCAL_STATIC_LIBRARIES list.
This change sets LOCAL_EXPORT_C_INCLUDE_DIRS to folders that
contain headers file that used by other modules in order to
export these paths.
Change-Id: Id1ac885b31ef2efe194e0289fbcaecd9eb533df0
Signed-off-by: Piotr Luc <piotr.luc@intel.com>
Reviewed-on: http://android.intel.com:8080/113562
Reviewed-by: cactus <cactus@intel.com>
Reviewed-by: Luc, Piotr <Piotr.Luc@intel.com>
Reviewed-by: Purushothaman, Vijay A <vijay.a.purushothaman@intel.com>
Reviewed-by: Stimson, Dale B <dale.b.stimson@intel.com>
Tested-by: Stimson, Dale B <dale.b.stimson@intel.com>
Reviewed-by: buildbot <buildbot@intel.com>
Tested-by: buildbot <buildbot@intel.com>
commit 2bf22fcbd4cbb9e7c7764d5eff0bb4e75ab1a005
Author: Emil Velikov <emil.l.velikov@gmail.com>
Date: 27 Jul 2014 18:27:21 +0100
android: Separate libdrm and intel LOCAL_EXPORT_C_INCLUDE_DIRS
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Contains the following patches squashed in:
commit f340a8b9f2b84d5762553bef046914e0bde20795
Author: Chad Versace <chad.versace@linux.intel.com>
Date: Wed, 21 Dec 2011 11:43:57 -0800
libdrm,intel: Add Android makefiles (v2)
This enables libdrm.so and libdrm_intel.so to build on Android
IceCreamSandwich.
v2: Link libdrm_intel to libpciaccess.
Change-Id: Ie5ed4bc0e6b4f9f819e3ec44488e385c35e97128
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
commit 8fb3f42389dea34218ed1fe59550ec2abb4d6953
Author: Andrew Boie <andrew.p.boie@intel.com>
Date: Wed, 26 Sep 2012 13:32:05 -0700
libdrm, libdrm_intel: Skip driver name checks
These libraries have 'optional' tags, which means they won't get
built unless something else depends on them or they are added to
PRODUCT_PACKAGES. There's no need for additional filtering.
Change-Id: I5d90969f38671f8144c0dc27d47144b3f09a15ce
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Will be used to consolidate the required sources lists as well as the
install-able headers. This is turn will help us to avoid the
duplication with the upcoming Android build support.
v2: Rename the headers variable to *_H_FILES.
v3: Rebase on top of symbol visibility patches.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
No exports changed for this driver.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some of the format strings for debug messages use the wrong modifier to
print sizes.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Thierry Reding <treding@nvidia.com>
These functions all take a format string and either a list of variable
arguments or a va_list. Use the new DRM_PRINTFLIKE macro to tell the
compiler about it so that the arguments can be checked against the
format string.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Thierry Reding <treding@nvidia.com>
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>
Currently the package name and description duplicate that of the
core libdrm. Update those to reflect reality.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
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>
Jeff McGee
Daniel Vetter
Kristian Høgsberg
Chih-Wei Huang
Thomas Klausner
Zhenyu Wang
Chris Wilson
Thomas Meyer
Damien Lespiau
Emil Velikov
Rafal Sapala
Tvrtko Ursulin
Lionel Landwerlin
Maarten Lankhorst
Ville Syrjälä
Thierry Reding
Kenneth Graunke
Eric Anholt
Ben Widawsky
Keith Packard
Ian Romanick
Dave Airlie
Ben Widawsky
Chia-I Wu