With that we can easily add a restriction to the not + flt -> fge
optimization to handle NaNs like it was done before.
Fixes: 51d8ca2dff ("r600/sfn: optimize comparison results")
v2: use SPDX license identifier (austriancoder)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37450>
This is all dead code since we weren't even seting the cap in iris/crocus!
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37447>
I see no point, we allocate for every shader stage anyway. This is a bit
simpler.
I'm not a fan of the brw_compiler singleton at all but torching that is not on
today's agenda. Flattening it a little bit very much is.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37447>
The main challenge is handling tile status (TS) correctly. Full clears
simply mark tiles as "cleared" in TS metadata without touching pixels.
Scissored clears must first decompress existing TS tiles using the
current clear color, then apply the new color to the scissor region.
The implementation maintains the original surface clear color for TS
decompression operations while using the new color for actual clearing.
This prevents rendering artifacts when mixing BLT and 3D operations.
BLT engine operates directly with pixel positions and handles all TS
tile complexity automatically.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35956>
On r600 ternary operations can't use the fabs source modifier, so
converting "fadd(fabs(fmul(a, b), c)" to "ffma(fabs(a), fabs(b), c)"
adds one more instruction in the backend, hence avoid this.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37440>
Fixes this error during Shader.cpp build:
..\src\util/format/u_formats.h(33): fatal error C1083: Cannot open include file: 'util/format/u_format_gen.h': No such file or directory
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37316>
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(114): error C2220: the following warning is treated as an error
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(114): warning C5286: implicit conversion from enum type '<unnamed-enum-LVP_CMD_WRITE_BUFFER_CP>' to enum type 'vk_cmd_type'; use an explicit cast to silence this warning
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(114): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(152): warning C5286: implicit conversion from enum type '<unnamed-enum-LVP_CMD_WRITE_BUFFER_CP>' to enum type 'vk_cmd_type'; use an explicit cast to silence this warning
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(152): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(173): warning C5286: implicit conversion from enum type '<unnamed-enum-LVP_CMD_WRITE_BUFFER_CP>' to enum type 'vk_cmd_type'; use an explicit cast to silence this warning
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(173): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(204): warning C5286: implicit conversion from enum type '<unnamed-enum-LVP_CMD_WRITE_BUFFER_CP>' to enum type 'vk_cmd_type'; use an explicit cast to silence this warning
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(204): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(706): warning C5286: implicit conversion from enum type '<unnamed-enum-LVP_CMD_WRITE_BUFFER_CP>' to enum type 'vk_cmd_type'; use an explicit cast to silence this warning
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(706): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(722): warning C5286: implicit conversion from enum type '<unnamed-enum-LVP_CMD_WRITE_BUFFER_CP>' to enum type 'vk_cmd_type'; use an explicit cast to silence this warning
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(722): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings
warnings are introduced with new cl compiler:
Microsoft (R) C/C++ Optimizing Compiler Version 19.44.35214 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
usage: cl [ option... ] filename... [ /link linkoption... ]
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37041>
this reuses some of the machinery from regular gfx shaders, but there
are some key differences:
* separate program/GPL caching
* separate GPL vertex input (technically illegal because spec hasn't caught up)
* in descriptor layouts, task+mesh occupy vs+tcs space (and thus vs+tcs layouts add mesh stages)
* lots of 'is_mesh' checks sprinkled all over
otherwise much of this change is just enlarging arrays
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37427>
Dumb-buffers or imported dmabufs are always linear - otherwise they
couldn't be used by llvmpipe/lavapipe. So far, however, they have been
implicitly reported as DRM_FORMAT_MOD_INVALID when queried through e.g.
`gbm_bo_get_modifier()`.
That is a problem for lavapipe, which requires explicit modifiers. Thus
report modifiers as linear, fixing clients like Westons Vulkan backend
on CI (vkms+lavapipe).
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37374>
Disable detection to match Debian 12 ASan behaviour and prevent a large
number of newly crashing tests on Debian 13.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35853>
Fixes a -Wmaybe-uninitialized warning:
../src/gallium/drivers/llvmpipe/lp_state_fs.c: In function 'generate_fs_twiddle':
../src/gallium/drivers/llvmpipe/lp_state_fs.c:1555:7: error: 'src' may be used uninitialized [-Werror=maybe-uninitialized]
1555 | lp_bld_quad_twiddle(gallivm, type, src, src_count, dst);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/gallium/drivers/llvmpipe/lp_state_fs.c:89:
../src/gallium/auxiliary/gallivm/lp_bld_quad.h:95:1: note: by argument 3 of type 'struct LLVMOpaqueValue * const*' to 'lp_bld_quad_twiddle' declared here
95 | lp_bld_quad_twiddle(struct gallivm_state *gallivm,
| ^~~~~~~~~~~~~~~~~~~
../src/gallium/drivers/llvmpipe/lp_state_fs.c:1474:17: note: 'src' declared here
1474 | LLVMValueRef src[16];
|
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35853>
frontend/mediafoundation: use texture pool for SATD map and Bitsused map
The usage of texture pool depends on the updated mfplat.dll with a fix related to D3DFMT_INDEX32.
If the mfplat.dll on the machine does not have the fix, it falls back to the original implementation without the texture pool.
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37376>
Since b3133e250e ("gallium: add pipe_context::resource_release to
eliminate buffer refcounting") we need to take a reference for every bound
buffer object.
As we create image views on buffers, and kinda take partly reference
already just do it properly for now so we don't end up with
use-after-frees in drivers.
Fixes: dee9600a ("zink: eliminate buffer refcounting to improve performance")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37350>
