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>
If you had a group as the first element of a struct, i.e.
<struct name="3DSTATE_CONSTANT_BODY" length="10">
<group count="4" start="0" size="16">
<field name="ReadLength" start="0" end="15" type="uint"/>
</group>
...
</struct>
we would get a group_offset of 0, causing create_field() to think the
field wasn't in a group, and fail to offset forward for successive array
elements. So we'd mark all the array elements as offset 0.
Using ctx->group->elem_size is a better check for "are we in a group?".
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
If you have something like:
<group count="0" start="96" size="32">
<field name="Entry_0" start="0" end="15" type="GATHER_CONSTANT_ENTRY"/>
<field name="Entry_1" start="16" end="31" type="GATHER_CONSTANT_ENTRY"/>
</group>
We would reset ctx->group_count to 0 after processing the first field,
so the second would not have a group count.
This is largely untested, as the only groups with multiple fields are
packets we don't emit in Mesa. Found by inspection.
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
These need special handling because they have no "DWord Length"
parameter and they have an unusual bias of 1.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In the unlikely case the parsing of genxml files fails, we were
leaking an xml parser object.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
We should get either 0 or 1 here.
CID: 1373562 (Control flow issues)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Matt Turner <mattst88@gmail.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>
Starting positions >= 32 are not part of the header, rather than >.
Caught by Coverity, which found that "bits <<= field->start" may shift
by 32, which has undefined behavior.
CID: 1404968
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>
This is pretty much the same tool as what i-g-t has, only with a more
fancy decoding of the instructions/registers. It also doesn't support
anything before gen4.
v2 (from Matt): Drop authors
Remove undefined automake variable
v3: Fix incorrect offsets for dword > 1 (Jordan)
v4: Fix decompression error with large blobs (Jordan)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Matt Turner <mattst88@gmail.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>
Combining all the files into a single string didn't make any
difference in the size of the aubinator binary.
With this change we now also embed gen4/4.5/5 descriptions, which
increases the aubinator size by ~16Kb.
v2 (Lionel): rebase makefiles
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
