Age | Commit message (Collapse) | Author |
|
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>
|
|
We were missing this one and it is being used by Bromolow.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
|
|
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
|
|
These are more cases where valgrind doesn't understand what gets read
or written by our ioctls.
|
|
|
|
|
|
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.
|
|
We've been hacking these constantly.
|
|
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>
|
|
This one doesn't have the 3DSTATE_HIER_DEPTH_BUFFER bug that the
previous one did.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
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>
|
|
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.
|
|
While I'm touching every line of the table, sort it by opcode.
|
|
I want to add packets, without contributing to the switch statement of
doom.
|
|
|
|
It's a lot nicer than using IS_WHATEVER(devid) all over the place, and
we have this in our other projects too.
|
|
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).
|
|
This reduces some of the extra derefs of the pointers.
|
|
Similar to BR00, count was always 1 and was always an index, not a count.
|
|
The count (actually index) was always 0, because BR00 is dword 0.
|
|
We still deref the context at the start of every call, but that will
change next.
|
|
Nothing was consuming it. If something wants this in the future,
would be done using the decode context anyway.
|
|
This is the start of plumbing the context through the decode
callchain instead of the current 4 arguments.
|
|
|
|
The .batch was generated using the dump-a-batch branch of
git://people.freedesktop.org/~anholt/mesa
using glxgears on gen7 hardware, using INTEL_DEVID_OVERRIDE for
non-gen7 (this means that offsets in the buffers for non-gen7 are 0!).
The .ref was generated by:
./test_decode tests/gen7-3d.batch -dump.
The .sh exists because you can't supply arguments to tests using the
simple automake tests driver. Something reasonable could be done
using automake's parallel-tests driver (in fact, a previous version of
the patch did that), but I was concerned that:
1) The parallel-tests driver is documented to be unstable -- they may
change interfaces on us later.
2) The parallel-tests driver hides the output of tests in .log files
scattered all over the tree, which was ugly and more painful to
work with.
v2: Actually add the batch files, add a .gitignore for the *-new.txt
files added after failures, and fix failure mode for undetected
chipset name.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1)
|
|
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Consumers often want to choose stdout vs stderr, and for testing I
want to output to an open_memstream file.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
|
|
It was producing an unused code warning. I'm tempted to just remove
it, since it's unused, but I *might* use it soon.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
|
|
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
|
|
I'd rather be able to use c99 variable declarations (there's a lot of
awful code layout due to being c90ish), but I'll leave that for later.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
|
|
There was plenty of dropped useful data, and some horribly
mis-formatted data.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
|
|
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
|
|
We've got a different (better) set of warning flags in place in this
tree.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
|
|
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
|
|
My plan is to use this drm_intel_dump_batchbuffer() interface for the
current GPU tools, and the current Mesa batch dumping usage, while
eventually building more interesting interfaces for other uses.
Warnings are currently suppressed by using a helper lib with CFLAGS
set manually, because the code is totally not ready for libdrm's warnings
setup.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
|
|
Some comments weren't wrapped, and for some reason uint32_t *data got
an extra space (while other instances of "type *identifier" didn't),
and the indentation of the opcode-list structs got trashed.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
|