| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Up to now we've been lucky that the buffer returned was always exactly
at the address we requested.
Fixes: 144b40db5411 ("intel: aubinator: drop the 1Tb GTT mapping")
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
(cherry picked from commit 35955afa7aa49906fad772b44d3e6357203430ae)
|
|
v2: by Lionel
Fix memfd_create compilation issue
Fix pml4 address stored on 32 instead of 64bits
Return no buffer if first ppgtt page is not mapped
v3: Drop additional memfd_create() (Rafael)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
|
|
We use memfd to store physical pages as they get read/written to and
the GGTT entries translating virtual address to physical pages.
Based on a commit by Scott Phillips.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
|
|
Now that we're softpinning the address of our BOs in anv & i965, the
addresses selected start at the top of the addressing space. This is a
problem for the current implementation of aubinator which uses only a
40bit mmapped address space.
This change keeps track of all the memory writes from the aub file and
fetch them on request by the batch decoder. As a result we can get rid
of the 1<<40 mmapped address space and only rely on the mmap aub file
\o/
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
|
|
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
|
|
On a follow up commit in this series, we stop copying the data from
the mmap'ed file into our big gtt mmap, and start referencing data in
it directly. So reallocating the read buffer and adding more data from
stdin wouldn't work. For that reason, let's stop supporting stdin
process.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
|
|
These memory offsets are stored in the gen_batch_decode_ctx.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
|
|
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
getopt_long flag parameter is an int pointer, so if we use bool to store
those values, when getopt_long writes to one of them, it might end up
overwriting the next one.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 7c22c150c40b3 ("intel: Move batch decoder/disassembler from tools/ to common/")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
Given an arbitrary batch, we don't always know what the size of certain
things are, such as how many entries are in a binding table. But it's
easy for the driver to track that information, so with a simple callback
we can calculate this correctly for INTEL_DEBUG=bat.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
We all know the platform names, and I don't want to update this list
continually.
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
Different registers are used for execlist submission in gen11, so
also watch those. This code only watches element zero of the
submit queue, which is all aubdump currently writes.
Tested-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
|
|
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Scott D Phillips <scott.d.phillips@intel.com>
|
|
Memtrace aubs are similar to classic aubs, with the major
difference being how command submission is serialized (as register
writes instead of a high-level submit message). Some internal
tools generate or consume only memtrace aubs.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
A later patch will use the aubinator_init() function from the
memtrace aub header handler.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
Previously, if a group was nested in another group such that it didn't
start on a dword boundary, we would decode it as if it started at the
start of its first dword. This changes things to work even more in
terms of bits so that we can properly decode these structs. This
affects MOCS, attribute swizzles, and several other things.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
CID: 1373563
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
|
|
We already have a function to dump sampler states, so do that for gen6
too.
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
|
|
The current way of handling groups doesn't seem to be able to handle
MI_LOAD_REGISTER_* with more than one register. This change reworks
the way we handle groups by building a traversal list on loading the
GENXML files.
Let's say you have
Instruction {
Field0
Field1
Field2
Group0 (count=2) {
Field0-0
Field0-1
}
Group1 (count=4) {
Field1-0
Field1-1
}
}
We build of linked on load that goes :
Instruction -> Group0 -> Group1
All of those are gen_group structures, making the traversal trivial.
We just need to iterate groups for the right number of timers (count
field in genxml).
The more fancy case is when you have only a single group of unknown
size (count=0). In that case we keep on reading that group for as long
as we're within the DWordLength of that instruction.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
|
|
Before this commit, when a group with count="0" is found, only one field
is added to the struct representing the instruction. This causes only
one entry to be printed by aubinator, for variable length groups.
With this commit we "detect" that there's a variable length group
(count="0") and store the offset of the last entry added to the struct
when reading the xml. When finally reading the aubdump file, we check
the size of the group and whether we have variable number of elements,
and in that case, reuse the last field to add the remaining elements.
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Tested-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
Decoding with aubinator encountered a command of 0xffffffff. With the
previous code, it caused aubinator to jump 255 + 2 dwords to start
decoding again.
Instead we can attempt to detect the known instruction formats. If the
format is not recognized, then we can advance just 1 dword.
v2:
* Update aubinator_error_decode
* Actually convert the length variable returned into a *signed* integer
in aubinator.c, intel_batchbuffer.c and aubinator_error_decode.c.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
Some packets like 3DSTATE_VF_STATISTICS, 3DSTATE_DRAWING_RECTANGLE,
3DPRIMITIVE, PIPELINE_SELECT, etc... have configurable fields in
dword0, we probably want to print those.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
|
|
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
This way they become part of libintel_common.la so I can use them in
the i965 driver.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
|
|
This lets us use it outside of the aubinator binary itself.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
No longer necessary - the iterator gets it from the group.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
When the iterator encounters a structure field, it now looks up the
gen_group for that structure definition and saves a pointer to it.
This lets us drop a lot of ridiculous code in the caller, which looked
at item->value (<struct NAME dword>), strtok'd the structure name back
out, and looked it up itself.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
The iterator code already computed this value, then we stored it in
the structure name, strtok'd it back out, and also manually computed
it when printing dword headers.
Just put the value in the struct and use it. Way simpler.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
It made more sense when decode_group() took a bunch of extra options,
but now that there's only one...we may as well pass 0 and call it a day.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
I added this flag in 65a9d5eabb05e4925c1c9a17836cad57304210d6 but
it was completely unused. Both callers appear to have printed dword
headers, so we can just drop the flag and continue doing it
unconditionally.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
gen_field_iterator_next() produces a string representing the value of
the field. For enum values, it also produced a separate "description"
string containing the textual name of the enum.
The only caller of this function combines the two, printing enums as
"<numeric value> (<texture enum name>)". We may as well just store
that in item->value directly, eliminating the description field, and
a layer of wrapping.
v2: Use non-overlapping source and destination strings in snprintf.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
This will make it easier to choose an output file. For now, it remains
stdout.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
The code for decoding structures and commands was almost identical.
The only differences are: we print dword headers for commands, and
we skip the first one (with the command opcode and lengths).
So, generalize decode_structure to add a starting DWord, and a flag
for printing the DWord headers, and reuse it.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
handle_struct_decode() is just a wrapper around decode_structure()
with a NULL check. But the only caller already does that NULL check.
So, just use decode_structure() directly.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
Three space, not four.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
Doesn't look like this can work on 32bit, just rids of annoying
warning.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
|
|
This commit does two things. One is to pull useful and/or interesting
information from the AUB file header and display it as a header above your
decoded batches. Second, it is now capable of pulling the PCI ID from the
AUB file comment left by intel_aubdump. This removes the need to use the
--gen flag all the time.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
This requires that a few more state bits become global.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
This makes it just store the pci_id instead of a struct pointer
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
We were reading from the "comment size" dword and incrementing by that
amount. This never caused a problem because that field was always zero.
However, experimenting with actual aub file comments indicates, the
simulator seems to include the comment size in the packet size provided in
the header. We should do the same.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
The helper automatically handles masking for us so we don't have to worry
about whether or not something is in the bottom bits.
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
|
|
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
|
|
This new helper is automatically handles 32 vs. 48-bit GTT issues. It also
handles 48-bit canonical addresses on Broadwell and above.
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
|
