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>
Both android-x86 and android-ia versions of libpciacccess correctly
"export" the include. If anyone else is wrapping up their own version
they should do so as well.
Remove this fixed location hack from the build.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Chih-Wei Huang <cwhuang@linux.org.tw>
With earlier changes we've implicitly add the relevant directories
to the includes list, via LOCAL_EXPORT_C_INCLUDES_DIRS.
v2: Update the top Android.mk as well.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Each of the libdrm_${hw} modules pull libdrm for linking as such:
libdrm's LOCAL_EXPORT_C_INCLUDE_DIRS are added to the includes list.
The former of which is already set to ${top} and ${top}/include/drm.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
- Don't add ${hw}/${hw}, but ${hw} to the includes path. The former
does not exist.
- Set the variable for libkms.
Inspired by the work of from Chih-Wei from the Android-x86 project.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
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>
At DDX commit Chris mentioned the tendency we have of finding out more
PCI IDs only when users report. So Let's add all new reserved Haswell IDs.
Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=63701
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
When publishing first HSW ids we weren't allowed to use "GT3" codname.
But this is the correct codname and Mesa is using it already.
So to avoid people getting confused why in Mesa it is called GT3 and here
it is called GT2_PLUS let's fix this name in a standard and correct way.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
It accidentally used the cmd id for the gen7 command and had an
outdated lenght field. Spotted while trying to make sense of an ivb
error_state from mesa 7.11 ...
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The second digit was off by one, which meant we accidentally treated
GT(n) as GT(n-1). This also meant no support for GT1 at all.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Protect the macro argument evaluations with parens.
This is already touching most lines, so while at it, fix up all white
space to uniform style throughout the file.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Intel GPU Tools is newer and arguably better. This change doesn't
completely merge the files because it's a bit simpler if we move the
I9XX macro over to Intel GPU Tools, and don't move over a few macros
from IGT that libdrm doesn't care about.
It has been discussed, and would seem even easier if Intel GPU Tools
simply used the libdrm header files. Whether or not we move to that,
this should help that effort.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
On Gen6, bit 15 is now `Depth Clear Value Valid`. This was being treated
as part of the length, and failing the rest of the batchbuffer decode.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
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>
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>
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>
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>
... and add support to decode MI instructions with functions.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This improves the performance of Mesa's GL_MAP_UNSYNCHRONIZED_BIT path
in GL_ARB_map_buffer_range. Improves Unigine Tropics performance at
1024x768 by 2.30482% +/- 0.0492146% (n=61)
v2: Fix comment grammar.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
drmIoctl returns -1 on error with errno set to the error value. Other
users of it in this file just check for != 0, and only use errno when
they need to send an error value on to the caller of the API.
This will allow the driver to capture all of its execution state to a
file for later debugging. intel_gpu_dump is limited in that it only
captures batchbuffers, and Mesa's captures, while more complete, still
capture only a portion of the state involved in execution.
This is a squash commit of a long series of hacking as we tried to get
the resulting traces to work in the internal simulator. It contains
contributions by Yuanhan Liu and Kenneth Graunke.
v2: Drop the MI_FLUSH_ENABLE setup.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
For example:
export INTEL_DEVID_OVERRIDE=0x162
If this variable is set, don't actually submit the batchbuffer to the
GPU, it probably contains commands for the wrong generation of hardware.
v2: Introduce a getter for the overridden devid, and avoid getenv per exec.
Reviewed-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Note that the regression test complains here: The batch that was
captured included a bug in its packet output, which was later fixed in
Mesa.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This requires pulling the gen6 3DSTATE_WM out to a function so it
doesn't override gen7's handler.
v2: Fix pasteo in interpreting ZW interpolation (thanks danvet!).
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Every access to either the GTT or CPU pointer is supposed to be
proceeded by a set_domain ioctl so that GEM is able to manage the cache
domains correctly and for the following access to be coherent. Of
course, some people explicitly want incoherent, non-blocking access
which is going to trigger warnings by this patch but are probably better
served by explicit suppression.
v2: Also mark the pointers as inaccessible following the explicit unmap
and implicit unmap upon return to the cache.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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>
This adds support for querying the kernel about the LLC support in the
hardware.
In case the ioctl fails, we assume that it is present on GEN6 and GEN7.
v2: fix the return code checking
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
If the pci_device's actual gen was > 4, then we stupidly set
bufmgr_gem->gen = 6. Luckily this caused no bugs, and this fix shouldn't
change any behavior, because all checks against the gen currently have one
of the forms below:
gen == 2
gen == 3
gen >= 4
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
This just gets packet name and length in place, with the remainder
unfinished. I've long since finished the work that got me started
fixing up the decode.
Since CC_STATE_POINTERS for gen6 and 7 are quite different but use the
same opcode, move gen6 out to a helper function too, so we can use a
helper function for gen7.
This puts the error message in a consistent location relative to the
packet, and while I'm here I made the error message a bit more
informative.
Now, most static length packets need to just declare their length in
the table and not worry.
The overflow checks were all thoroughly untested, and a bunch of the
ones I'm deleting were pretty broken. Now, in the case of overflow,
you just decode data of 0xd0d0d0d0, and instr_out prints the warning
message instead. Note that this still has the same issue of being
under-tested, but at least it's one place instead of per-packet.
A couple of BUFFER_FAIL uses are left where the length to be decoded
could be (significantly) larger than a page, and the decode didn't
just call instr_out (which doesn't dereference data itself unless it's
safe).
Tapani Pälli
Kristian Høgsberg Kristensen
Emil Velikov
Anuj Phogat
Damien Lespiau
Tvrtko Ursulin
Chris Wilson
Jeff McGee
Daniel Vetter
Kristian Høgsberg
Chih-Wei Huang
Thomas Klausner
Zhenyu Wang
Thomas Meyer
Rafal Sapala
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
Rodrigo Vivi
Xiang, Haihao
Chris Forbes
Jesse Barnes
David Shao
Paulo Zanoni
Rob Clark
Dave Airlie
Lauri Kasanen
Paul Berry
Eugeni Dodonov
Eugeni Dodonov
Chad Versace