For UBO accesses to be the same performance as classic GL default uniform
block uniforms, we need to be able to push them through the same path. On
freedreno, we haven't been uploading UBOs as push constants when they're
used for indirect array access, because we don't know what range of the
UBO is needed for an access.
I believe we won't be able to calculate the range in general in spirv
given casts that can happen, so we define a [0, ~0] range to be "We don't
know anything". We use that at the moment for all UBO loads except for
nir_lower_uniforms_to_ubo, where we now avoid losing the range information
that default uniform block loads come with.
In a departure from other NIR intrinsics with a "base", I didn't make the
base an be something you have to add to the src[1] offset. This keeps us
from needing to modify all drivers (particularly since the base+offset
thing can mean needing to do addition in the backend), makes backend
tracking of ranges easy, and makes the range calculations in
load_store_vectorizer reasonable. However, this could definitely cause
some confusion for people used to the normal NIR base.
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6359>
In LLVM 12 ElementCount constructor is private
and instead of using it explicitly, ::get function
should be used, but in LLVM 11, the constructor
is still the way to go.
Reviewed-by: Krzysztof Raszkowski <krzysztof.raszkowski@intel.com>
Closes: #3490
Fixes: 639605e5ba
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6648>
libfreedreno_common static dependency is need for gallium_dri target
Fixes the following building error:
ld.lld: error: undefined symbol: fd_get_device_uuid
>>> referenced by freedreno_screen.c:836 (external/mesa/src/gallium/drivers/freedreno/freedreno_screen.c:836)
>>> freedreno_screen.o:(fd_screen_get_device_uuid) in archive out/target/product/x86_64/obj/STATIC_LIBRARIES/libmesa_pipe_freedreno_intermediates/libmesa_pipe_freedreno.a
ld.lld: error: undefined symbol: fd_get_driver_uuid
>>> referenced by freedreno_screen.c:842 (external/mesa/src/gallium/drivers/freedreno/freedreno_screen.c:842)
>>> freedreno_screen.o:(fd_screen_get_driver_uuid) in archive out/target/product/x86_64/obj/STATIC_LIBRARIES/libmesa_pipe_freedreno_intermediates/libmesa_pipe_freedreno.a
Fixes: e3c39e505 "freedreno: Implement pipe screen's get_device/driver_uuid()"
Signed-off-by: Mauro Rossi <issor.oruam@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6625>
Fixed-func shaders can contain the output, because their generator
doesn't consider the current primitive type into account.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6620>
ppir_do_one_node_to_instr merges instructions and uses a pipeline reg
to save a reg. It tests if ppir_node_has_single_src_succ, but it should
check if ppir_node_has_single_succ.
The following deqp tests run into this issue because they have a node
with 2 successors in different blocks, where one was merged into the same
instruction and the second one is pointing to a missing predecessor then.
Fixes the following deqp tests:
dEQP-GLES2.functional.shaders.loops.do_while_dynamic_iterations.vector_counter_fragment
dEQP-GLES2.functional.shaders.loops.for_dynamic_iterations.vector_counter_fragment
dEQP-GLES2.functional.shaders.loops.while_dynamic_iterations.vector_counter_fragment
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Andreas Baierl <ichgeh@imkreisrum.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6555>
Compilers may use vector instructions in calculating
hash values of std::string. This happens usualy when
high optimalization level is enabled. SWR had two
static std::map<std::string, T> variables which
lead to crashes on non-AVX systems during the initialization
of those variables. This commit makes those variables
dynamically allocated and fixes this AVX instruction
leak.
Closes: #3077Closes: #198
Reviewed-by: Krzysztof Raszkowski <krzysztof.raszkowski@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6565>
When MCBP is enabled, IB maybe preempted which will also update
the preempted fence field of the user fence. So we need to reserve
enough space for each user fence.
Fixes: 89d2dac554 "radeonsi: enable preemption if the kernel enabled it"
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6577>
so that they can be different depending on the GPU (for 16-bit support)
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6284>
Already set by AC_FLOAT_MODE_DEFAULT_OPENGL.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6284>
This also fixes the inverted last parameter of nir_lower_flrp in most drivers.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6599>
