For a future extension we want to be able to list the counters. Our
existing sets counters might contain the same counters multiple times.
This is a side effect of the fixed OA counters in the HW. We track
thoses with a mask so that we know when a counter is available from
multiple metrics.
v2: Use BITFIELD64_BIT() (Jason)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2775>
This change adds a call/return execution mode for secondary command
buffer rather than the existing copy into the primary batch mode.
v2: Rework convention to avoid burning an ALU register (Jason)
v3: Use anv_address_add() (Jason)
v4: Move command emissions to anv_batch_chain.c (Jason)
v5: Also move last MI_BBS emission in secondary command buffer to
anv_batch_chain.c (Jason)
v6: Fix end secondary command buffer end (Jason)
v7: Refactor anv_batch_address() to remove additional emit functions
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2775>
This instruction has a group with the same name than another field above :
<field name="Data DWord" start="64" end="95" type="uint"/>
<group count="0" start="96" size="64">
<field name="Register Offset" start="2" end="22" type="offset"/>
<field name="Data DWord" start="32" end="63" type="uint"/>
</group>
The script was replacing the offset of the field first with the second
one in the group.
This change ignore anything a group within an instruction.
v2: Drop unused variable (Rafael)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2775>
We can just set the extent and not bufferRowLength/bufferImageHeight,
and the extent may not be a multiple of the block size if it covers the
entire image. In this case we have to first divide to get the
width/height in terms of blocks, and then multiply by the block size to
get the buffer's pitch and layer size. Multiplying and dividing instead
won't get the correct result when the extent covers the entire image and
isn't a multiple of the block size. This also makes the code easier to
follow because we don't calculate a pitch in non-sensical units (bytes
times the block width) as an intermediate step.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5098>
Previously we only supported BLIT_SRC_BIT and BLIT_DEST_BIT together, so
we didn't have to worry about initializing blit-related fields for
texture-only formats, but it turns out that 2d blits work out just fine
with these formats and we'll need to enable BLIT_SRC_BIT for
texture-only formats due to a Vulkan requirement on compressed formats.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5098>
All it takes are a couple small tweaks to the clone infrastructure to
allow us to use it without any remap table at all. This reduces code
duplication and the chances for bugs that come with it. In particular,
the hand-rolled nir_alu_instr_clone didn't preserve no_[un]signed_wrap,
or source/destination modifiers.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5094>
It sure looks like it should be a Boolean value, but it's not. The
values that we really want for later platforms are either 2 or 3. The
old intel_stub.c in shader-db just always returns 3
(I915_GEM_PPGTT_FULL). This returns the same set of values per platform
that kernel 5.6.13 would.
When using the shim for ICL with i965 driver, this fixes:
i965 requires softpin (Kernel 4.5) on Gen10+.
Fixes: 0f4f1d70bf ("intel: add stub_gpu tool")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5061>
Rather than heuristically guessing what PIPE formats correspond to what
in the hardware, hardcode a table. This is more verbose, but a lot more
obvious -- the previous format support code was a source of endless
silent bugs.
v2: Don't report RGB233 (icecream95). Allow RGB5 for texturing
(icecream95).
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5069>
This has the downside of putting block successor validation in two
places that are a bit further apart. However, handling them as a
special case makes the code more confusing than needed. At least two
different people have not noticed that we don't have jump instruction
validation in the last week or two and added it. Being able to search
for validate_jump_instr is useful.
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5101>
For 16-bit bank LDS (ie. Kabini/Stoney) we need a slightly different
path. It's completely untested though because I don't have these
chips but according to vkpipeline-db the generated assembly seems fine.
Note that 16-bit I/O is currently only exposed on GFX9+ for both
compiler backends.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4966>
Lionel Landwerlin