Exposing the u32 context ID makes it possible to define new drm kernel
interfaces based on the same IDs that e.g. execbuf uses to identify a
gem context, that aren't themselves abstracted by libdrm but need to be
used by libdrm/drm_intel_context based clients such as (parts of) i-g-t
or Mesa.
For example this can be used to configure an i915-perf stream to collect
metrics for a specific context.
v2: s/drm_intel_gem_context_get_context_id/drm_intel_gem_context_get_id/
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
As well as allowing a hexadecimal PCI ID number, the
INTEL_DEVID_OVERRIDE environment variable can now contain one of a few
short codenames. The codenames are stored in a small table to map them
to a corresponding PCI ID. This makes it easier to use without having
to look up the PCI IDs manually.
The PCI IDs used are the same as those chosen for the -p option of
run.c in shader-db but SKL has been added as well.
Reviewed-by: Matt Turner <mattst88@gmail.com>
A slightly confused copy'n'paste from the open path where we pass in
handle but use it as a global name, in the prime handle-from-fd pass we
pass in handle and do mean handle!
References: https://bugs.freedesktop.org/show_bug.cgi?id=98416
Fixes: 2f23bf1b7b89 ("intel: Migrate handle/name lookups from linear lists...")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Walking a linear list to find a matching PRIME handle or flinked name
does not scale and becomes a major burden with just a few objects.
That said, the fixed size hash is not much better, it just buckets the
look into a few separate chains rather than one long one.
References: https://bugs.freedesktop.org/show_bug.cgi?id=94631
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Export a set of interfaces to allow the caller to have precise control
over mapping the buffer - but still provide caching of the mmaps between
callers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Update kernel interface with new I915_GETPARAM ioctl entries for
pooled EU and min no. of eus in a pool. Add a wrapping function
for each parameter. Userspace drivers need these values when decide
the thread count. This kernel enabled pooled eu by default for BXT
and for fused down 2x6 parts it is advised to turn it off.
But there is another HW issue in these parts (fused
down 2x6 parts) before C0 that requires Pooled EU to be enabled as a
workaround. In this case the pool configuration changes depending upon
which subslice is disabled and the no. of eus in a pool is different,
So userspace need to know min no. of eus in a pool.
V2: use return value as the query results.
ret < 0 when error, ret = 0 when not support, and ret > 0 indicate
query results.(Chris)
V3: Correct V2 errors.
Signed-off-by: Yang Rong <rong.r.yang@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Currently only some Android Makefiles are included in the release tarball.
To be more consistent one could either add the remaining files or don't
ship Android Makefiles altogether.
According to Emil the Android folk doesn't use our release tarballs.
Thus it makes sense to remove those files from distribution which also
means less work for maintenance in the future.
Suggested-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
AOSP master now errors if LOCAL_SRC_FILES contains headers, so filter
out header files from the source lists.
Signed-off-by: Rob Herring <robh@kernel.org>
This is unusual. Usually IDs listed on early stages of platform
definition are kept there as reserved for later use.
However these IDs here are not listed anymore in any of steppings
and devices IDs tables for Kabylake on configurations overview
section of BSpec.
So it is better removing them before they become used in any
other future platform.
v2: Rebase.
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
The spec has been updated adding new PCI IDs.
v2: Avoid using "H" instead of HALO to keep names uniform - DK.
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
These IDs were already part of the kernel since:
kernel commit 985dd4360fdf2533fe48a33a4a2094f2e4718dc0
Author: Imre Deak <imre.deak@intel.com>
Date: Thu Jan 28 16:04:12 2016 +0200
drm/i915/bxt: update list of PCIIDs
Cc: Venkateswarlu Vinjamuri <venkateswarlu.v.vinjamuri@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Also, following kernel definition Kabylake is skylake.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Softpin allows userspace to take greater control of GPU virtual address
space and eliminates the need of relocations. It can also be used to
mirror addresses between GPU and CPU (shared virtual memory).
Calls to drm_intel_bo_emit_reloc are still required to build the list of
drm_i915_gem_exec_objects at exec time, but no entries in relocs are
created. Self-relocs don't make any sense for softpinned objects and can
indicate a programming errors, thus are forbidden. Softpinned objects
are marked by asterisk in debug dumps.
Cc: Thomas Daniel <thomas.daniel@intel.com>
Cc: Kristian Høgsberg <krh@bitplanet.net>
Cc: Zou Nanhai <nanhai.zou@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
Signed-off-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
Gen8+ supports 48-bit virtual addresses, but some objects must always be
allocated inside the 32-bit address range.
In specific, any resource used with flat/heapless (0x00000000-0xfffff000)
General State Heap (GSH) or Instruction State Heap (ISH) must be in a
32-bit range, because the General State Offset and Instruction State Offset
are limited to 32-bits.
The i915 driver has been modified to provide a flag to set when the 4GB
limit is not necessary in a given bo (EXEC_OBJECT_SUPPORTS_48B_ADDRESS).
48-bit range will only be used when explicitly requested.
Callers to the existing drm_intel_bo_emit_reloc function should set the
use_48b_address_range flag beforehand, in order to use full ppgtt range.
v2: Make set/clear functions nops on pre-gen8 platforms, and use them
internally in emit_reloc functions (Ben)
s/48BADDRESS/48B_ADDRESS/ (Dave)
v3: Keep set/clear functions internal, no-one needs to use them directly.
v4: Don't set 48bit-support flag in emit reloc, check for ppgtt type
before enabling set/clear function, print full offsets in debug
statements, using port of lower_32_bits and upper_32_bits from linux
kernel (Michał)
References: http://lists.freedesktop.org/archives/intel-gfx/2015-July/072612.html
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
Signed-off-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
It defines the prototype of ffs that fixes the building error
on Android 6.0 64-bit image.
Signed-off-by: Chih-Wei Huang <cwhuang@linux.org.tw>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
This removes ones which aren't used, and adds some new ones. I kept the original
names where possible.
Cc: Kristian Høgsberg <krh@bitplanet.net>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
We're about to remove the -Wno flag from configure.ac which will lead
to a lot of unnecessary spam.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
...to minimise misuse of bo_gem.
If the variable is declared at the top of the function and then used
for two (or more) different contexts this can cause confusion and errors.
Just introduce a wrapper, which can be used in a once off situations.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by Chris Wilson <chris@chris-wilson.co.uk>
Just like we do for the original exec()
v2: move bo_gem declaration to the top of the function.
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by Chris Wilson <chris@chris-wilson.co.uk>
v2: keep the bo_gem declaration in exec2() within the loop (Chris)
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by Chris Wilson <chris@chris-wilson.co.uk>
It is possible to hit a race condition in create_from_prime, when trying
to import a BO that's currently being freed. In case of prime sharing
we'll succesfully get a handle, but fail on get_tiling call, potentially
confusing the caller (and requiring different locking scheme than with
sharing using flink). Wrap fd_to_handle with struct_mutex to force
a more consistent behaviour between prime/flink, convert fprintf to DBG
when handling errors.
(From Chris:
The race is that the kernel returns us the same file-private handle as
the first thread, but that first thread is about to call gem_close
(thereby removing the handle from the file completely) and does so
between us acquiring the handle and taking the mutex. If we take
the mutex, then we acquire the refcnt on the bo prior to the first
thread completing its unref (and so preventing the early close). Or we
acquire the handle after the earlier close, in which case we are the new
owner.
)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Testcase: igt/drm_import_export/import-close-race-prime
Signed-off-by: Rafał Sapała <rafal.a.sapala@intel.com>
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
We need this include in porting changes for the OpenGL ES
conformance suite.
v2: remove c_plusplus usage
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
We now have a separate tool for this in intel-gpu-tools and we don't
need to clutter up libdrm with this feature. We leave the entry points
in there to avoid breaking API/ABI.
Install intel-gpu-tools, then run (for example)
$ intel_aubdump --output=trace.aub glxgears -geometry 500x500
See the intel_aubdump man page for more details.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
Follow the approach used through the rest of the project.
Suggested-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
In case of YF/YS tiled buffers libdrm need not know about the tiling
format because these buffers don't have hardware support to be tiled
or detiled through a fenced region. But, libdrm still need to know
about buffer alignment restrictions because kernel uses it when
resolving the relocation.
Mesa uses drm_intel_gem_bo_alloc_for_render() to allocate Yf/Ys buffers.
So, use the passed alignment value in this function to initialize the
align variable in drm_intel_bo. Note that we continue ignoring the
alignment value passed to drm_intel_gem_bo_alloc() to follow the
previous behavior.
V2: Add a condition to avoid allocation from cache. (Ben)
V3: Make no changes in cache allocation strategy. Just update the alignment.
Update the aperture size estimate including the alignment. (Ben, Chris)
V4: Move aperture size adjustments inside drm_intel_bo_gem_set_in_aperture_size()
Don't split sentences across the one-line header and the changelog. (Chris)
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to use userptr, the kernel tracks the owner's mm with a
mmu_notifier. Setting that is very expensive - it involves taking all
mm_locks and a stop_machine(). This tracking lives only for as long as
the client is using userptr objects - so if the client allocates then
frees a userptr in a loop, we will be executing that heavyweight setup
everytime. To ammoritize this cost, just leak the test bo and the single
backing page we use for detecting userptr.
v2: Free the object and memory when bufmgr is destroyed.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Required by intel and drmstat at least. Considering that every compiler
used to build libdrm is C99 compatible, just enable it for the whole
build.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Some compilers (like the Oracle Studio), require that the function
declaration must be annotated with the same visibility attribute as the
definition. As annotating functions with drm_public is no longer
required just remove the macro.
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Michel Dänzer <michel.daenzer@amd.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
With earlier commits we've annotated the private symbols, thus
we no longer require the -fvisibility=hidden CFLAGS.
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Michel Dänzer <michel.daenzer@amd.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
They are less and easier to track than the public ones. The macro
drm_public will be going away by the end of the series.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The function was never part of the public API and a release or so back
was hidden from the global name-space (list of exported symbols).
According to git log this function was never used internally.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Added with commit 57b4c4c32d3(Move the renaming of mm.c symbols to
symbol duplication/collision with ones that are available elsewhere.
As the public/private symbols of libdrm are properly annotated neither
one of the symbols will end up in the global name-space, thus should no
longer be required.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Running __mmu_notifier_register() is surprisingly expensive, so let's
not do that unless we have to.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Michel Dänzer
Robert Bragg
Ben Widawsky
Matt Turner
Neil Roberts
Chris Wilson
Yang Rong
Andreas Boll
Rob Herring
Rodrigo Vivi
Michał Winiarski
Eric Engestrom
Marek Olšák
Kristian Høgsberg Kristensen
Michel Thierry
Chih-Wei Huang
Ben Widawsky
Emil Velikov
Rafał Sapała
Tapani Pälli
Anuj Phogat
Damien Lespiau
Tvrtko Ursulin