It only supports blending mode that va frontend expects, so prefer the old
fragment shader and only use the compute shader when gfx is not supported.
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32794>
There were a couple of issues this fixes:
- Using the env "RUSTICL_DEVICE_TYPE" variable made no device be default.
- If multiple GPUs were detected, multiple devices were default.
- If zink was used, no default device was advertized either.
The spec requires that there must be one and only one default device.
Cc: mesa-stable
Reviewed-by @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32875>
It caused the Blender corruption, but the previous commit likely fixes it.
The workaround regressed performance for Furmark and Plot3D with 8xMSAA.
If you want to enable the workaround again in the future, just add this
line back: sscreen->info.gfx_level >= GFX11 ||
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32885>
It looks like it was broken and might have been responsible
for the Blender corruption.
Just do a full decompression and change to TC-compatible HTILE after
that even if we don't end up doing fast clear here.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32885>
this was copypasted from the wrong function. fixes on asahi
KHR-Single-GL46.arrays_of_arrays_gl.SubroutineArgumentAliasing4_var_type_index_13
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Mary Guillemard <mary@mary.zone>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32871>
Some lowering passes can leave dead code behind, but dead IO intrinsics
are still counted as enabled IO, which breaks things.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32779>
If you want to set it to int/uint, set .src_type or .dest_type. If you want
to set it to float, you don't need to set the type at all. It's implicitly
set to float.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32779>
It was hard-coded to 64k but Xe2 platforms and newer supports
larger SLM sizes.
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Dylan Baker <dylan.c.baker@intel.com>
Cc: mesa-stable
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32874>
Applications typically use one globak max_anisotropy value.
Moving it to static state should save a could of instructions.
Reviewed-by: Aleksi Sapon <aleksi.sapon@autodesk.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31748>
This is based on the example given by the Vulkan specification: https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#textures-texel-anisotropic-filtering
The basic idea is to compute the axis in which the uv coordinates
change the fastest in screen space (rho_y and rho_y). If rho_x is larger
than rho_y, samples are summed up along the x-Axis and the y-Axis
viceversa. The x/y offsets are mapped back into texture (u/v) space
using a linear approximation of u(x,y) and v(x,y).
This approach does not use a nested loop and the number of samples is
basically limited to max_anisotropy (+/-). The sample count of the
previous approach could explode in some situations, leading to
frametimes >1s.
Reviewed-by: Aleksi Sapon <aleksi.sapon@autodesk.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31748>
Currently the list of buffer usage bits specified is hardcoded with
transform feedback bits, which leads to a validation layer error report
with ID VUID-VkBufferCreateInfo-None-09499 when EXT_transform_feedback
is not available.
Only set these bits when EXT_transform_feedback extension is really
available to suppress this error.
Cc: mesa-stable
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32386>
One new rv410 flake and one new rv530 fail which I can't reproduce
locally. Also remove the vs-varying-array-mat3* flakes, those were
failing because we run out of varyings, however this should no longer be
an issue since nir_opt_varyings was enabled for everyone.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32897>
The push_constant_loc[] array is always an identity mapping these days,
so it's kind of pointless. Just use the original uniform number and
skip the unnecessary "remap" step. With that gone, and shrinking UBO
ranges gone, assign_constant_locations() is now empty and can be removed
as well.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32841>
Now that we never shrink ranges in the backend, we never lower push
constants to pull constants late in the backend either. get_pull_loc
will never return true, and so all of brw_lower_constant_loads becomes
a noop.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32841>
Back in the bad old days (vec4?) we had a bunch of smarts in the backend
to dead code eliminate unused vector components and re-pack regular
uniforms, so we really couldn't decide how much data we were pushing
until very late in the backend. Nowadays we have none of that - we do
all of our elimination and packing in NIR. anv shrinks ranges to deal
with Vulkan API push constants, and iris treats everything as a UBO and
as of the previous commit will also shrink appropriately.
So we don't need to do this anymore...which will let us simplify quite
a bit of code.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32841>
anv already does this limiting, since it needs to handle non-UBO push
constants as well. iris treats everything as a UBO, but doesn't have
a limiter and was relying on the backend to handle it.
Do this in the NIR pass so that we can eliminate the backend code.
It's not necessary for anv, but handling it here is simple and less
error prone for iris, which calls this in a number of places. We know
we need to limit things to this much; anv can limit more if needed.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32841>
