While we're at it, also spell the code-names in allcaps, like NVIDIA
does. One exception is Fermi, which is spelled like a proper noun.
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19297>
The two different swrast drivers we have at the moment are called
LLVMpipe and Softpipe. Let's name the latter instead of the generic
SWRast term that we use to cover *either* of the two.
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19297>
Documentation is worded in a confusing way, which may be understood that
we don't have to set this field to get good results.
MESH part of this commit improves performance of vk_meshlet_cadscene
by a factor of 2 on A380.
Fixes: ef04caea9b ("anv: Implement Mesh Shading pipeline")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19412>
Add unit tests for debug_get_bool_option and debug_get_num_option
Merge env_var_as_boolean and debug_get_bool_option and implement
env_var_as_boolean with debug_get_bool_option in a stricter side.
Merge env_var_as_unsigned and debug_get_num_option and implement
env_var_as_unsigned with debug_get_num_option in a stricter side.
Move debug_control, parse_debug_string, parse_enable_string,
comma_separated_list_contains from debug.* to u_debug.*
Main changes:
os_get_option() is used instead of getenv() for env_var_as_boolean
and env_var_as_unsigned;
also debug_get_bool_option() has logic like "true" always if not "false";
env_var_as_boolean() now uses different logic:
if env variable is neither "true" nor "false" returns the default value,
we left the second one; but if you want the behavior to be the same as in
the old version of debug_get_bool_option() use dfault=true
Signed-off-by: Illia Abernikhin <illia.abernikhin@globallogic.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19336>
This is required when crocus is enabled in rusticl,
the lack of it contributes to this error:
thread '<unnamed>' panicked at 'Context missing features. This should never happen!', ../src/gallium/frontends/rusticl/mesa/pipe/context.rs:44:13
Signed-off-by: Thomas Debesse <dev@illwieckz.net>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19001>
This does the exact opposite of 06e96074 from !16129.
Before LLVM commit 702d5de4 opaque pointers were supported but not enabled
by default when building LLVM. They were made default in commit 702d5de4.
LLVM commit d69e9f9d introduced -opaque-pointers/-no-opaque-pointers cc1
options to enable or disable them whatever the LLVM default is.
Those two commits follow llvmorg-15-init and precede llvmorg-15.0.0-rc1 tags.
Since LLVM commit d785a8ea, the CLANG_ENABLE_OPAQUE_POINTERS build option of
LLVM is removed, meaning there is no way to build LLVM with opaque pointers
enabled by default.
It was said at the time it was still possible to explicitly disable opaque
pointers via cc1 -no-opaque-pointers option, but it is known a later commit
broke backward compatibility provided by -no-opaque-pointers as verified with
arbitrary commit d7d586e5, so there is no way to use opaque pointers starting
with LLVM 16.
Those two commits follow llvmorg-16-init and precede llvmorg-16.0.0-rc1 tags.
Since Mesa commit 977dbfc9 opaque pointers are properly implemented in Clover
and used.
If we don't pass -opaque-pointers to Clang on LLVM versions supporting opaque
pointers but disabling them by default, there will be an API mismatch between
Mesa and LLVM and Clover will not work.
Signed-off-by: Thomas Debesse <dev@illwieckz.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19290>
This reverts commit 06e9607478 from !16129.
Clover passed -no-opaque-pointers option to Clang to workaround the fact
the Clover code was not ported to opaque pointers yet.
Opaque pointers are now implemented thanks to !19103 so passing this
option to tell Clang to not do opaque pointers while Clover does
is actually breaking Clover.
Here is an example of what happens when using opaque pointers while
passing -no-opaque-pointers at the same time:
fatal error: cannot open file 'hawaii-amdgcn-mesa-mesa3d.bc':
Opaque pointers are only supported in -opaque-pointers mode
This fixes one of the last remaining bits to fully support opaque pointers
in Mesa as referenced in #7468, this is the last remaining bit to fully support
opaque points in Clover.
Signed-off-by: Thomas Debesse <dev@illwieckz.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19290>
In issue #3278, Danylo noted that nir_opt_access() could desynchronize
the prog->sh.ImageAccess[] and prog->sh.BindlessImage[].access fields,
which are filled out as part of uniform linking, prior to running this
optimization pass. Those fields are used to fill out pipe_image_view's
shader_access field, which is used by a lot of drivers these days.
There's an easy solution to this issue however: we can simply call the
pass prior to linking, a few lines earlier.
This lets us infer that images are non-readable, which may let drivers
do additional optimizations.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3278
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19162>
We can provide better guidance on when to (un-)set this given that
everyone's on NIR now.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16539>
We want to use nir_opt_large_constants() instead (which is already
enabled), since that doesn't involve uploading the large immediate data
array again on each CB0 update. The downside is a bit of addressing math,
since constant_data is accessed using 64-bit global addresses.
The shader-db results are a bit all over:
All Iris driver platforms had similar results. (Ice Lake shown)
total instructions in shared programs: 19910185 -> 19913931 (0.02%)
instructions in affected programs: 225374 -> 229120 (1.66%)
helped: 3 / HURT: 348
total cycles in shared programs: 856004856 -> 855016808 (-0.12%)
cycles in affected programs: 22832422 -> 21844374 (-4.33%)
helped: 277 / HURT: 101
total spills in shared programs: 6580 -> 6609 (0.44%)
spills in affected programs: 516 -> 545 (5.62%)
helped: 1 / HURT: 4
total fills in shared programs: 8235 -> 8267 (0.39%)
fills in affected programs: 1022 -> 1054 (3.13%)
helped: 1 / HURT: 3
total sends in shared programs: 1039347 -> 1039095 (-0.02%)
sends in affected programs: 16367 -> 16115 (-1.54%)
helped: 251 / HURT: 0
LOST: 5
GAINED: 2
LOST:
- 3 SIMD16 fragment shaders (Superposition)
- 2 SIMD16 compute shaders (Aztec Ruins)
GAINED:
- fake news... 2 SIMD8 compute shaders that replace the lost SIMD16
compute shaders.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16539>
nir_opt_large_constants balks at seeing a store_deref of a variable
where the source is a vecN operation of multiple load_consts, and thinks
that isn't a constant, so it should not bother promoting it.
Unfortunately, we were running nir_lower_load_const_to_scalar before
nir_opt_large_constants, so this prevented a ton of constant promotion.
This commit /used to help/ some shaders in shader-db. Presumably since
!16770 landed, those shaders were already helped. Currently ther are
no shader-db changes on any Intel platform.
Fossil-db results:
All Intel platforms had similar results. (Ice Lake shown)
Instructions in all programs: 141998227 -> 141421756 (-0.4%)
Instructions helped: 12515
Instructions hurt: 237
SENDs in all programs: 7437925 -> 7468033 (+0.4%)
SENDs hurt: 12806
Cycles in all programs: 9161655753 -> 9132869800 (-0.3%)
Cycles helped: 10163
Cycles hurt: 2637
Spills in all programs: 19977 -> 18678 (-6.5%)
Spills helped: 384
Spills hurt: 40
Fills in all programs: 32863 -> 31396 (-4.5%)
Fills helped: 385
Fills hurt: 42
Lost: 1
Lots of Shadow of the Tomb Raider fragment shaders and Batman Arkham
Origins vertex shaders were hurt for SENDs in this commit. A couple
Aztec Ruins compute shaders and Spaceship shaders (multiple stages)
were also hurt.
All of the shaders hurt for spills or fills were Spaceship compute
shaders. Nearly all of the shaders helped were Shadow of the Tomb
Raider fragmenet shaders. One Spaceship shader was reall, REALLY helped:
Spills helped fossils/fossil-db/Spaceship.run.9f90a2a226fcc57f.1.foz/0b507d3abe2e3c28/compute: 321 -> 13 (-96.0%)
Fills helped fossils/fossil-db/Spaceship.run.9f90a2a226fcc57f.1.foz/0b507d3abe2e3c28/compute: 279 -> 21 (-92.5%)
Overall this seems like an improvement, but we may want to actually
run these few benchmarks before landing.
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16539>
We were using the old load_global intrinsic still, which can't be
reordered, limiting optimization opportunities. We know the data here
is constant, so we can use the newer load_global_constant intrinsic.
This doesn't seem to have any impact on shader-db or fossil-db on any
Intel platform.
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16539>
Mainly to get rid of alloc/free in collect_countables. Sampling at 1ms,
perf becomes
- 22.75% pps::FreedrenoDriver::collect_countables
22.59% pps::FreedrenoDriver::Countable::collect
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19427>
It is always possible on a5xx+ and allows Countable::collect to do 1 ldr rather
than 2.
Sampling at 1ms, perf goes from
- 34.44% pps::FreedrenoDriver::collect_countables
25.36% pps::FreedrenoDriver::Countable::collect
3.92% cfree
+ 2.28% operator new
to
- 29.60% pps::FreedrenoDriver::collect_countables
20.70% pps::FreedrenoDriver::Countable::collect
4.01% cfree
+ 2.35% operator new
1.09% memcpy
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19427>
Otherwise, queries might return invalid data because they used
the same offsets as NGG streamout.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19442>
Foz-DB Navi21:
Totals from 2403 (1.78% of 134913) affected shaders:
CodeSize: 25329156 -> 25311244 (-0.07%)
Signed-off-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19413>
The kernel keeps returning -ENOMEM if multiple processes allocate GDS,
this always happen while running VKCTS. This solution is loosely based
on RadeonSI, except that it includes a timeout of 1s to exit the loop.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19440>
Erik Faye-Lund
Marcin Ślusarz
Illia Abernikhin
Thomas Debesse
Alyssa Rosenzweig
Kenneth Graunke
Emma Anholt
Chia-I Wu
Samuel Pitoiset
Georg Lehmann