I did my stress testing mostly outside of north america work hours, but it
turns out once the runners have 60-70% background CPU usage, these ones
intermittently time out.
Reported-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41163>
There are less than 2^16 lanes within a threadgroup, so it is safe to do
all math at 16-bit. This allows us to use 16-bit integer division which is
much faster than 32-bit integer division (in terms of the lowerings).
In a "hello world" kernel with variable wg size, simd32 goes 72 inst -> 57
inst on jay and 82 -> 67 inst on brw.
OTOH it's a loss for non-variable wg size, so do it only there to avoid
unwelcome stats regresions on Vulkan.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41084>
This reverts commit b83a931cb1 as it causes
regressions with dirty rects enabled on some HW platforms that signal
out of order completion and require individual fence objects per slice
Fixes: b83a931cb1 ("d3d12: Video sliced encode: Use same ID3D12Fence/different per slice values as optimization")
Reviewed-by: Pohsiang (John) Hsu <pohhsu@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41160>
KHR_pipeline_library is a base extension whose semantics can only
be exercised by extensions: EXT_graphics_pipeline_library
and KHR_ray_tracing_pipeline. Both remain gated under LLVM,
so advertising the KHR base extension is inert for conformant apps.
The reason for the change is a hard requirement for KHR_pipeline_library
in DXVK 2.7+. DX games under Proton, which uses DXVK, fail adapter
creation if this extension is absent. DXVK supports scenario when
KHR_pipeline_library is available but two dependent extensions aren't.
The !use_llvm condition originated in f1095260a4 when
KHR_pipeline_library was first wired up for ray tracing only. It was
touched also in 045c96d896 when EXT_graphics_pipeline_library also took
it as a dependency.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41134>
These are a mix of fields whose last used was removed or fields that were
never used, possibly because they remained in a patch while the rest of the
code changed before landing.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41139>
A reshape operation just changes the dimensions of a tensor, but doesn't
change the data at all. So we just point the OFM to the IFM data and
we're done.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39975>
The ethosu_lower_add() function can handle other element wise operations
such as multiply, minimum, and maximum, so rename it in preparation to
add those operations.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39975>
Add support for fully-connected convolution. FC convolution lowering is
nearly the same, so refactor the existing convolution code to support
both.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39975>
For axis 1 concatenation, the OFM strides need to match the IFM strides.
Presumably axis -3 can also be supported, but there haven't been any
models with -3. Not sure what axis 2 would need either.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39975>
Some of the tensor info is needed at various points during lowering.
Instead of storing the tensor index and looking it up every time, store
a point to the tensor struct instead.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39975>
The struct ethosu_operation structure has the same initialization in
multiple ops. More ops with the same duplication are about to be added.
Move this out to a common initializer function.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39975>
The vela compiler defines shift as signed and some upcoming LUT code
allows for negative shifts, so make shift signed everywhere.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39975>
Because of a previous refactor, pco_last_igrp was incorrectly changed to return
the first entry in a linked list instead of the last. Update pco_last_igrp to
return the last entry in a linked list.
The following CTS tests now pass:
dEQP-GLES3.functional.shaders.switch.conditional_fall_through_2_dynamic_fragment
dEQP-GLES3.functional.shaders.switch.conditional_fall_through_dynamic_fragment
dEQP-GLES3.functional.shaders.switch.conditional_fall_through_uniform_fragment
Fixes: 719ece42c0 ("pco: Switch back to util/list")
Signed-off-by: Duncan Brawley <duncan.brawley@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41125>
The Vulkan runtime and panvk already handle unused attachments
correctly. Enable the extension and feature flags.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40920>
Just like the fix for nvk, just drop this in the GL driver as well.
Cc: mesa-stable
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41143>
BTD unit will keep accumulating the threads and then eventually dispatch
those active threads once it reaches the counter.
I guess dispatching too fast will not have full occupancy at the BTD
unit, instead we just pick the half of max value for counter.
This patch also add drirc option to dispatch_timeout_counter and tweak
values internally with respect to HW limits. Default value we have right
now is 512 clocks, we can for sure tune it per app.
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40733>
