| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
We generally go for kernel style in this tree, and this 4-space indent
stuff was bothering me. The new results have some ugly bits, but
they're in places where we desperately want to be using helper
functions anyway.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
|
|
These will be used by intel_decode.c, and were taken from intel-gpu-tools.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
|
|
This will make these macros reusable from intel_decode.c, which
doesn't have a bufmgr_gem context, without faking the struct. We
should generally only be using these macros from bufmgr_gem context
setup anyway.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
|
|
This is from commit dd9a5b4f7fb07c78db4e7481bedca1b981030e3f.
We've been sharing this file between that repo and Mesa, and it's time
to build a real interface using it. I'm also hoping to apply some of
its packet-walking logic for AUB dumping and batch validation
purposes.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
|
|
During free we unconditionally delete the bo from the vma cache. This
relies on the its list member being kept in a sane state. This fails
after the object is purged, as the purge operation performs a pure
deletion and doesn't reset the list member, leaving a pair of dangling
pointers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Hopefully all the bugs in the callers have been found, so time to
handle the failures "gracefully" again.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As the max number of VMA mappings is a hard per-process limit, we need
to include the number of currently active mappings when evicting in
order to make room for a new mmap.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
There is a per-process limit on the number of vma that the process can
keep open, so we cannot keep an unlimited cache of unused vma's (besides
keeping track of all those vma in the kernel adds considerable overhead).
However, in order to work around inefficiencies in the kernel it is
beneficial to reuse the vma, so keep a MRU cache of vma.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As a precautionary measure munmap on buffer free so that we never leak
the vma. Also include a warning during debugging.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We cannot afford to cache the vma per open bo as this may exhaust the
per-process limits.
References: https://bugs.freedesktop.org/show_bug.cgi?id=43075
References: https://bugs.freedesktop.org/show_bug.cgi?id=40066
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Otherwise we blow up on heavy tiled blitter loads (with giant
pixmaps).
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Before this, consumers of the libdrm API that might map a buffer
either way had to track which way was chosen at map time to call the
appropriate unmap. This relaxes that requirement by making
drm_intel_bo_unmap() always appropriate.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This used to be next to some map refcounting code, but that is long dead.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
This lets us replace the current inner drawing loop of mesa:
for each prim {
compute bo list
if (check_aperture_space(bo list)) {
batch_flush()
compute bo list
if (check_aperture_space(bo list)) {
whine_about_batch_size()
fall back;
}
}
upload state to BOs
}
with this inner loop:
for each prim {
retry:
upload state to BOs
if (check_aperture_space(batch)) {
if (!retried) {
reset_to_last_prim()
batch_flush()
} else {
if (batch_flush())
whine_about_batch_size()
goto retry;
}
}
}
This avoids having to implement code to walk over certain sets of GL
state twice (the "compute bo list" step). While it's not a
performance improvement, it's a significant win in code complexity:
about -200 lines, and one place to make mistakes related to aperture
space instead of N places to forget some BO we should have included.
Note how if we do a reset in the new loop , we immediately flush. We
don't need to check aperture space -- the kernel will tell us if we
actually ran out of aperture or not. And if we did run out of
aperture, it's because either the single prim was too big, or because
check_aperture was wrong at the point of setting up the last
primitive.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
A few of the bitfield-based booleans are left in place. Changing them
to "bool" results in the same code size, so I'm erring on the side of
not changing things.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Luckily the kernel has become extremely paranoid about such matters.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Otherwise it's pretty hard to differentiate the different chipset
variants.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
|
