intel/compiler: Get rid of struct gen_disasm It's just a container around a devinfo. The one useful purpose it did serve is that gen_disasm_create initialized the compaction table singletons. Now that those no longer exist, this isn't necessary. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6244>
intel/decoder: Make get_state_size take a full 64-bit address and a base i965 wants to use an offset from a base because everything is in a single buffer whose address may be relocated, and all base addresses are set to the start of that buffer. iris wants to use a full 64-bit address, because state lives in separate buffers which may be in the shader, surface, and dynamic memory zones, where addresses grow downward from the top of a 4GB zone, So it's very possible for a 32-bit offset to exist relative to multiple bases, leading to the wrong state size.
intel/gen_decoder: Decode <group> inside <group>. Now we can decode a <group> tag inside another <group> tag, and properly print its indices and content. v2: Use push/pop stack to fields, groups and iters (Lionel). v3: Add assert(iter->level < DECODE_MAX_ARRAY_DEPTH) (Lionel). Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
intel/gen_decoder: Add the concept of array "levels". We currently only support one level, which is the basic level of a <group> tag. Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
intel/gen_decoder: Add array field. We currently use the group->next pointer to iterate through the <group> tags. This change them to be a type of field, so we can descend into them while iterating, and then go back to the original position. Will be useful when we want to decode <group>'s inside <group>'s, and when there are more <field>'s after a <group> tag. Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
intel/gen_decoder: Rename internally "group" to "array". A gen_group (group in most of the code) can be of several types: - instruction - struct - register - group (?!?) The <group> tag actually represents an array of elements. So at least in our code, lets call it an array to avoid confusion with gen_group. Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
intel/gen_decoder: Add gen_spec_load_filename() function. Refactor the code from gen_spec_load_from_path() into a separate function, that can be used with a xml file that doesn't fit the genX.xml filename format. Will be used soon for implementing unit tests for gen_decoder. Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
intel/decoders: limit number of decoded batchbuffers IGT has a test to hang the GPU that works by having a batch buffer jump back into itself, trigger an infinite loop on the command stream. As our implementation of the decoding is "perfectly" mimicking the hardware, our decoder also "hangs". This change limits the number of batch buffer we'll decode before we bail to 100. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
intel/decoders: handle decoding MI_BBS from ring An MI_BATCH_BUFFER_START in the ring buffer acts as a second level batchbuffer (aka jump back to ring buffer when running into a MI_BATCH_BUFFER_END). Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
intel/decoders: add address space indicator to get BOs Some commands like MI_BATCH_BUFFER_START have this indicator. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
intel/decoder: tools: Use engine for decoding batch instructions The engine to which the batch was sent to is now set to the decoder context when decoding the batch. This is needed so that we can distinguish between instructions as the render and video pipe share some of the instruction opcodes. v2: The engine is now in the decoder context and the batch decoder uses a local function for finding the instruction for an engine. v3: Spec uses engine_mask now instead of engine, replaced engine class enums with the definitions from UAPI. v4: Fix up aubinator_viewer (Lionel) Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
intel/decoder: Engine parameter for instructions Preliminary work for adding handling of different pipes to gen_decoder. Each instruction needs to have a definition describing which engine it is meant for. If left undefined, by default, the instruction is defined for all engines. v2: Changed to use the engine class definitions from UAPI v3: Changed I915_ENGINE_CLASS_TO_MASK to use BITSET_BIT, change engine to engine_mask, added check for incorrect engine and added the possibility to define an instruction to multiple engines using the "|" as a delimiter in the engine attribute. v4: Fixed the memory leak. v5: Removed an unnecessary ralloc_free(). Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
intel/decoder: Use 'DWord Length' and 'bias' fields for packet length. Use the 'DWord Length' and 'bias' fields from the instruction definition to parse the packet length from the command stream when possible. The hardcoded mechanism is used whenever an instruction doesn't have this field. Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
intel: decoder: remove unused variable Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
intel: Make the decoder just store addresses for bases, not buffers. The various base addresses are simply addresses. There may or may not be a buffer located at those addresses. So, it doesn't make much sense to request one. Just save the raw address so we can add it later, when asking about BOs at the final <base + offset> address. Suggested-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
intel: Make the decoder handle STATE_BASE_ADDRESS not being a buffer. Normally, i965 programs STATE_BASE_ADDRESS every batch, and puts all state for a given base in a single buffer. I'm working on a prototype which emits STATE_BASE_ADDRESS only once at startup, where each base address is a fixed 4GB region of the PPGTT. State may live in many buffers in that 4GB region, even if there isn't a buffer located at the actual base address itself. To handle this, we need to save the STATE_BASE_ADDRESS values across multiple batches, rather than assuming we'll see the command each time. Then, each time we see a pointer, we need to ask the driver for the BO map for that data. (We can't just use the map for the base address, as state may be in multiple buffers, and there may not even be a buffer at the base address to map.) v2: Fix things caught in review by Lionel: - Drop bogus bind_bo.size check. - Drop "get the BOs again" code - we just get the BOs as needed - Add a message about interface descriptor data being unavailable Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
intel: decoder: limit to the number decoded lines from VBO By default we set no limit, but the debug batch decoder in i965 sets it to 100. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
intel: Give the batch decoder a callback to ask about state size. 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>
intel: decoder: document when fields should be used Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
intel: decoder: identify groups with fixed length <register> & <struct> elements always have fixed length. The get_length() method implies that we're dealing with an instruction in which the length is encoded into the variable data but the field iterator uses it without checking what kind of gen_group it is dealing with. Let's make get_length() report the correct length regardless of the gen_group (register, struct or instruction). Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>