Added instructions for the video engine to the genxml files.
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/118
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Dec 04, 2018 at 01:41:37PM +, Eric Engestrom wrote:
> On Tuesday, 2018-12-04 14:14:51 +0200, Toni Lönnberg wrote:
> > ../src/intel/tools/aubinator_error_decode.c: In function
> > ‘instdone_register_for_ring’:
> > ../src/intel/tools/aubinator_error_decode.c:177:4:
../src/intel/tools/aubinator_error_decode.c: In function
‘instdone_register_for_ring’:
../src/intel/tools/aubinator_error_decode.c:177:4: warning: enumeration value
‘I915_ENGINE_CLASS_INVALID’ not handled in switch [-Wswitch]
switch (class) {
^~
---
src/intel/tools/aubinator_error_de
Reviewed-by: Toni Lönnberg
On Fri, Nov 09, 2018 at 04:49:13PM +, Lionel Landwerlin wrote:
> Identical fix to :
>
> commit 70de31d0c106f58d6b7e6d5b79b8d90c1c112a3b
> Author: Jason Ekstrand
> Date: Fri Aug 24 16:05:08 2018 -0500
>
> intel/batch_decoder: Print
Reviewed-by: Toni Lönnberg
On Fri, Nov 09, 2018 at 04:49:12PM +, Lionel Landwerlin wrote:
> Identical fix to :
>
> commit cbd4bc1346f7397242e157bb66099b950a8c5643
> Author: Jason Ekstrand
> Date: Fri Aug 24 16:04:03 2018 -0500
>
> intel/batch_decoder: Fix d
Reviewed-by: Toni Lönnberg
On Fri, Nov 09, 2018 at 04:49:10PM +, Lionel Landwerlin wrote:
> Use this value to limit reading the ring buffer.
>
> Signed-off-by: Lionel Landwerlin
> ---
> src/intel/tools/aubinator.c | 4 +++-
> src/intel/tools/aubinator_viewe
Reviewed-by: Toni Lönnberg
On Fri, Nov 09, 2018 at 04:49:11PM +, Lionel Landwerlin wrote:
> We can only start parsing commands from the head pointer. This was
> working fine up to now because we only dealt with a "made up" ring
> buffer (generated by aub_write) which alway
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added additional engine definitions.
v4: Added missing engine definition t
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added additional engine definitions.
v4: Added more missing engine definit
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added additional engine definitions
v4: Added missing engine to MEDIA_GATE
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added additional engine definitions.
---
src/intel/genxml/gen75.xml | 214
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added additional engine definitions.
---
src/intel/genxml/gen7.xml | 166 +
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added additional engine definitions.
---
src/intel/genxml/gen5.xml | 60 ++
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added addition engine definitions.
---
src/intel/genxml/gen45.xml | 54 +++
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added additional engine definitions.
v4: Added missing engine definition t
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added additional engine definitions.
v4: Added missing engine tag for MI_T
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added additional engine definitions.
---
src/intel/genxml/gen4.xml | 50 ++
On Thu, Nov 08, 2018 at 01:10:54PM +, Lionel Landwerlin wrote:
> On 08/11/2018 13:06, Toni Lönnberg wrote:
> > On Thu, Nov 08, 2018 at 10:47:20AM +, Lionel Landwerlin wrote:
> > > Missing tag on :
> > >
> > >
> > > CS_URB_STATE
> &g
On Thu, Nov 08, 2018 at 10:55:06AM +, Lionel Landwerlin wrote:
> Missing render engine :
>
>
> SWTESS_BASE_ADDRESS
>
> MI_RS_CONTEXT
>
> MI_RS_CONTROL
>
> MI_RS_STORE_DATA_IMM
?!
+
+
+
+
___
mesa-dev mailing list
mesa-dev@lists.freedes
On Thu, Nov 08, 2018 at 10:54:17AM +, Lionel Landwerlin wrote:
> Just SWTESS_BASE_ADDRESS missing render engine
?!
+
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Thu, Nov 08, 2018 at 10:47:55AM +, Lionel Landwerlin wrote:
> Same missing tags a gen4.5
?!
+
+
+
+
+
+
+
+
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Thu, Nov 08, 2018 at 10:47:20AM +, Lionel Landwerlin wrote:
> Missing tag on :
>
>
> CS_URB_STATE
> CONSTANT_BUFFER
> MI_FLUSH
> URB_FENCE
> XY_COLOR_BLT
> XY_SETUP_BLT
> XY_SRC_COPY_BLT
> XY_TEXT_IMMEDIATE_BLT
?!
+
+
+
+
+
+
+
+
__
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: Cha
Removed the gen_engine enum and changed the involved functions to use the
drm_i915_gem_engine_class enum from UAPI instead.
v3: Wrong engine was being used for blocks in video ring
v4: Fixed aubinator_viewer.cpp
---
src/intel/tools/aub_read.c | 22 +++---
src/intel/tool
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: Cha
On Thu, Nov 08, 2018 at 12:57:03PM +0200, andrey simiklit wrote:
> Hello,
>
> Please find my comment below:
>
> On Wed, Nov 7, 2018 at 4:49 PM Toni Lönnberg
> wrote:
>
> > Preliminary work for adding handling of different pipes to gen_decoder.
> > Eac
On Tue, Nov 06, 2018 at 12:40:43PM +, Lionel Landwerlin wrote:
> On 31/10/2018 13:12, Toni Lönnberg wrote:
> > Instructions meant for the render engine now have a definition
> > specifying that so that can differentiate instructions meant for
> > different engines due
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added additional engine definitions.
---
src/intel/genxml/gen10.xml | 224
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added additional engine definitions.
---
src/intel/genxml/gen11.xml | 230
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added additional engine definitions.
---
src/intel/genxml/gen9.xml | 226 +
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added additional engine definitions.
---
src/intel/genxml/gen11.xml | 230
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added additional engine definitions.
---
src/intel/genxml/gen7.xml | 166 +
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added additional engine definitions.
---
src/intel/genxml/gen75.xml | 214
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added additional engine definitions.
---
src/intel/genxml/gen8.xml | 228 +
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added additional engine definitions
---
src/intel/genxml/gen6.xml | 106 ++
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added additional engine definitions.
---
src/intel/genxml/gen5.xml | 60 ++
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added addition engine definitions.
---
src/intel/genxml/gen45.xml | 54 +++
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added additional engine definitions.
---
src/intel/genxml/gen4.xml | 50 ++
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
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: Cha
On Tue, Nov 06, 2018 at 12:40:43PM +, Lionel Landwerlin wrote:
> On 31/10/2018 13:12, Toni Lönnberg wrote:
> > Instructions meant for the render engine now have a definition
> > specifying that so that can differentiate instructions meant for
> > different engines due
On Tue, Nov 06, 2018 at 12:11:16PM +, Lionel Landwerlin wrote:
> On 31/10/2018 13:12, Toni Lönnberg wrote:
> > 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
&g
On Tue, Nov 06, 2018 at 12:07:58PM +, Lionel Landwerlin wrote:
> On 31/10/2018 13:12, Toni Lönnberg wrote:
> > Preliminary work for adding handling of different pipes to gen_decoder. Each
> > instruction needs to have a definition describing which engine it is meant
>
On Fri, Nov 02, 2018 at 09:47:11AM -0500, Jason Ekstrand wrote:
> On Fri, Nov 2, 2018 at 6:05 AM Toni Lönnberg
> wrote:
>
> > On Fri, Nov 02, 2018 at 12:09:54AM -0500, Jason Ekstrand wrote:
> > > On Thu, Nov 1, 2018 at 5:51 AM Toni Lönnberg
> > > wrote:
> &g
On Fri, Nov 02, 2018 at 12:09:54AM -0500, Jason Ekstrand wrote:
> On Thu, Nov 1, 2018 at 5:51 AM Toni Lönnberg
> wrote:
>
> > On Wed, Oct 31, 2018 at 01:18:11PM -0500, Jason Ekstrand wrote:
> > > On Wed, Oct 31, 2018 at 11:10 AM Toni Lönnberg
> > > wrote:
> &
On Wed, Oct 31, 2018 at 01:18:11PM -0500, Jason Ekstrand wrote:
> On Wed, Oct 31, 2018 at 11:10 AM Toni Lönnberg
> wrote:
>
> > When we debug media or 3d+media workloads, we'd like to be able to see
> > what is
> > in the aub dumps for those workloads.
ort other engines for no other reason than to make
> aubinator for blits. It would also likely be useful to have if we wanted
> to start doing media in mesa for some reason. What's your motivation? I
> ask because I can't really have an opinion on the approach unles
Removed the gen_engine enum and changed the involved functions to use the
drm_i915_gem_engine_class enum from UAPI instead.
v3: Wrong engine was being used for blocks in video ring
---
src/intel/tools/aub_read.c | 22 +++---
src/intel/tools/aub_read.h | 11 +++
src/intel
Seems I screwed up with the engine for video and accidentally left *_RENDER as
the engine. Will follow up with v3.
On Wed, Oct 31, 2018 at 03:12:48PM +0200, Toni Lönnberg wrote:
> Removed the gen_engine enum and changed the involved functions to use the
> drm_i915_gem_engine_class enum fro
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
---
src/intel/genxml/gen75.xml | 184 ++---
1 f
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
---
src/intel/genxml/gen9.xml | 208 +++---
1 f
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
---
src/intel/genxml/gen11.xml | 208 ++---
1 f
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
---
src/intel/genxml/gen10.xml | 206 ++---
1 f
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
---
src/intel/genxml/gen8.xml | 202 +++---
1 f
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
---
src/intel/genxml/gen5.xml | 44 +++
1 f
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
---
src/intel/genxml/gen45.xml | 38 +++---
1 f
Removed the gen_engine enum and changed the involved functions to use the
drm_i915_gem_engine_class enum from UAPI instead.
---
src/intel/tools/aub_read.c | 22 +++---
src/intel/tools/aub_read.h | 11 +++
src/intel/tools/aubinator.c | 5 ++---
3 files changed, 16 inserti
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
---
src/intel/genxml/gen4.xml | 36 ++--
1 file
ssed through gen_print_batch().
* Split the genxml changes into multiple patches
Toni Lönnberg (13):
intel/decoder: tools: gen_engine to drm_i915_gem_engine_class
intel/decoder: Engine parameter for instructions
intel/decoder: tools: Use engine for decoding batch instructions
intel/genxml
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
---
src/intel/genxml/gen7.xml | 154 +++---
1 f
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
---
src
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
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
---
src/intel/genxml/gen6.xml | 94 +++
1 f
just like to leave the decode somewhat agnostic about what type of
> engine it's dealing with.
>
> -
> Lionel
>
> On 30/10/2018 16:21, Toni Lönnberg wrote:
> > The engine doesn't change inside a batch but it can change between batches,
> > right? The options are
ntroduce a local find_instruction() function that calls
> gen_spec_find_instruction(ctx->spec, ctx->engine, p).
>
> Thanks,
>
> -
> Lionel
>
> On 30/10/2018 14:32, Toni Lönnberg wrote:
> > The engine to which the batch was sent to is now passed along when decoding
h to use drm_i915_gem_engine_class from
> include/drm-uapi/i915_drm.h and just have macro for class id -> mask.
>
> On 30/10/2018 14:32, Toni Lönnberg wrote:
> > Moved the engine enum from aub_read.h to gen_decoder.h and changed it into a
> > bitmask. The enumeration needs to be de
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.
---
src/intel/common/gen_decoder.c | 9 +
src/intel/common
ngine" to the definition.
Currently the supported engines are "render", "video" and "blitter".
Toni Lönnberg (4):
intel/decoder: tools: gen_engine enum location
intel/decoder: Engine parameter for instructions
intel/decoder: tools: Use engine for decodin
Moved the engine enum from aub_read.h to gen_decoder.h and changed it into a
bitmask. The enumeration needs to be defined in a single place that can be used
by the decoder and tools.
---
src/intel/common/gen_decoder.h | 6 ++
src/intel/tools/aub_read.c | 1 +
src/intel/tools/aub_read.h
The engine to which the batch was sent to is now passed along 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.
---
src/intel/common/gen_batch_decoder.c | 21 ++-
src/
to me. Maybe you'll find something useful from this series :
> https://patchwork.freedesktop.org/series/50135/
>
> Reviewed-by: Lionel Landwerlin
>
> On 29/10/2018 14:05, Toni Lönnberg wrote:
> > Preliminary work for adding handling of different pipes to gen_decoder
Preliminary work for adding handling of different pipes to gen_decoder. We
need to be able to distinguish between different pipes in order to decode
the packets correctly due to opcode re-use.
---
src/intel/tools/aub_read.c | 26 ++
src/intel/tools/aub_read.h | 5 -
2
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.
---
src/intel/common/gen_decoder.c | 30 +++---
src/in
On Fri, Oct 26, 2018 at 03:15:50PM +0100, Lionel Landwerlin wrote:
> On 26/10/2018 15:06, Toni Lönnberg wrote:
> > - Forwarded message from Toni Lönnberg -
> >
> > Date: Fri, 26 Oct 2018 17:03:54 +0300
> > From: Toni Lönnberg
> > To: Lionel Landwerlin
- Forwarded message from Toni Lönnberg -
Date: Fri, 26 Oct 2018 17:03:54 +0300
From: Toni Lönnberg
To: Lionel Landwerlin
Message-ID: <20181026140354.gd3...@intel.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Subject: Re: [Mesa-dev] [PATCH] intel/decoder: Use 'DWord 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.
---
src/intel/common/gen_decoder.c | 16 ++--
src/intel/common/gen
I tried to find a helper function for bit count already available but
apparently I missed it :) No need for a new one if one exists already indeed.
-Toni
On Mon, Oct 15, 2018 at 07:59:58PM +, Roland Scheidegger wrote:
> Am 15.10.18 um 15:19 schrieb Toni Lönnberg:
> > ---
>
Added a new structure for holding SIMD32 heuristics control data. The
control data itself will be fetched from drirc.
---
src/intel/compiler/brw_compiler.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/intel/compiler/brw_compiler.h
b/src/intel/compiler/brw_compiler.h
index
The function goes through the compiled shader and checks how many grouped
texture fetches there are. This is a simple heuristic which gets rid of most
of the regressions when enabling SIMD32 shaders but still retains some of
the benefits.
---
src/intel/compiler/brw_fs.cpp | 26
To be able to test the heuristics with different parameters, they can be
controlled via environment variables through drirc.
---
src/mesa/drivers/dri/i965/brw_context.c | 13 +
src/mesa/drivers/dri/i965/intel_screen.c | 27 +++
2 files changed, 40 insertions(+)
The SIMD32 selection heuristics will use this information for deciding whether
SIMD32 shaders should be used.
---
src/intel/compiler/brw_fs.h | 2 ++
src/intel/compiler/brw_fs_generator.cpp | 12
2 files changed, 14 insertions(+)
diff --git a/src/intel/compiler/brw_fs.h
---
src/util/bitscan.h | 25 +
1 file changed, 25 insertions(+)
diff --git a/src/util/bitscan.h b/src/util/bitscan.h
index dc89ac9..cdfecaf 100644
--- a/src/util/bitscan.h
+++ b/src/util/bitscan.h
@@ -112,6 +112,31 @@ u_bit_scan64(uint64_t *mask)
return i;
}
+/* Cou
There are three simple heuristics for SIMD32 shader enabling:
- How many MRTs does the shader write into?
- How many grouped texture fetches does the shader have?
- How many instructions does the SIMD32 shader have compared to the SIMD16
shader?
For testing purposes, the heuristics can be cont
Added a new DEBUG_HEUR32 flag to INTEL_DEBUG flags for enabling SIMD32
selection heuristics.
---
src/intel/common/gen_debug.c | 1 +
src/intel/common/gen_debug.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/intel/common/gen_debug.c b/src/intel/common/gen_debug.c
index
it is not on by default but has to be
enabled via INTEL_DEBUG, just like forcing SIMD32 on. Further more, the
different mechanisms of the heuristic can be controlled via environment
variables/drirc.
Toni Lönnberg (7):
i965: SIMD32 heuristics debug flag
i965: SIMD32 heuristics control data
Having the disassembly always show the message descriptor and SFID makes it
easier to debug what data is actually fed to the external units. Descriptor
format was changed to unsigned so that immediate values as 'src1' will get
printed out in a readable format.
---
src/intel/compiler/brw_disasm.c
From: "Lonnberg, Toni"
Pre-work for the new shader assember.
To produce the exact same bit representation, the assembler needs to see the
swizzle of the source operands even when RepCtrl is not set.
---
src/mesa/drivers/dri/i965/brw_disasm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deleti
From: "Lonnberg, Toni"
Pre-work for the new shader assembler.
To make it easier to read the shader disassembly, the message descriptor is
typed as
unsigned so it's easier to decode the individual parts from the disassembled
hexadecimal value.
---
src/mesa/drivers/dri/i965/brw_eu_emit.c
From: "Lonnberg, Toni"
If the "disasm" flag is used in the INTEL_DEBUG debug flags, as all immediate
values will be output as hexadecimals, the values are not easily understood
when just looking at the disassembly so now the values are output in a legible
format as a comment field after the instr
From: "Lonnberg, Toni"
Pre-work for the new shader assembler.
To follow more the style of the documentation and for the shader assembler
parser to be able to handle different styles of register region definitions,
the vertical stride is now delimited differently from the width and horizontal
str
From: "Lonnberg, Toni"
This and the previous shader disassembly patches replace these previous
patches:
[PATCH 3/3] Changed shader disassembler number formatting to use integers when
the "disasm" debug flag is used. Register types and regions are also now
formatted morelike in the archite
From: "Lonnberg, Toni"
The shader disassembly now decodes SENDS/SENDSC instructions. Due to ambiguity
in the documentation, the decoding of the version where a scalar register is
used as the extra descriptor, this might need to be re-implemented.
---
src/mesa/drivers/dri/i965/brw_disasm.c | 109
From: "Lonnberg, Toni"
Pre-work for the new shader assembler.
For the assembler to be able to produce the same bit representation for
immediate values used by disassembled shaders, the disassembly needs to output
the values as hexadecimals. To remove any ambiguity between the value and the
type,
From: "Lonnberg, Toni"
The decoded information about the message descriptors in SEND/SENDC
instructions are formatted to the same line as the instruction in shader
disassembly so that it's more readable and easier for the new shader
assembler to parse.
---
src/mesa/drivers/dri/i965/brw_disasm.c
From: "Lonnberg, Toni"
Pre-work for the new shader assembler.
To avoid ambiguity in the shader assembler when parsing, all immediate values
will need a delimiter to describe the type of the value being used. For
consistency, all register values are formatted with the same delimiter.
---
src/mes
From: "Lonnberg, Toni"
Pre-work for shader disassembly label support.
---
src/mesa/drivers/dri/i965/brw_disasm.c | 12 ++--
src/mesa/drivers/dri/i965/brw_eu.h | 2 ++
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_disasm.c
b/src/mesa/dr
From: "Lonnberg, Toni"
Corrected the indentation where tabs were being used.
---
src/mesa/drivers/dri/i965/brw_eu.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu.c
b/src/mesa/drivers/dri/i965/brw_eu.c
index
From: "Lonnberg, Toni"
Shader instructions which use UIP/JIP now get formatted with a label instead
of an immediate value if the "disasm" flag has been set in the INTEL_DEBUG
debug flags, and the jump targets themselves also get printed as labels into
the shader disassembly.
---
src/intel/tools/
From: "Lonnberg, Toni"
Pre-work for shader disassembly label support.
Introduction of the structures and functions used by the shader disassembly
jump target labeling.
---
src/mesa/drivers/dri/i965/brw_context.h | 1 +
src/mesa/drivers/dri/i965/brw_eu.c | 46 ++
From: "Lonnberg, Toni"
Pre-work for shader disassembly label support.
Setting the "disasm" flag in the INTEL_DEBUG flags will enable label support
for the shader disassembly and change the formatting of immediate values to
use hexadecimals for all types.
---
src/mesa/drivers/dri/i965/intel_debu
1 - 100 of 106 matches
Mail list logo
