This will be used later when implementing Tile-based blit function.
v1:
- Fix commit title (Iago)
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7816>
This adds an enum to the load tile buffer that forces the alpha channel
to be set to 1. This will be required later to load RGBX formats.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7816>
Function that checks if the format has its alpha component forced to 1.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7816>
Should help some compilers/static analyzers understand this code and avoid
things like this:
../src/intel/tools/aubinator_error_decode.c:850:19: warning: "path" may be used uninitialized in this function [-Wmaybe-uninitialized]
850 | ret = asprintf(&filename, "%s/%d/i915_error_state", path, minor);
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7994>
Fix defects reported by Coverity Scan.
uninit_member: Non-static class member m_interpolate is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member m_lds_pos is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member m_mask is not initialized in this constructor nor in any functions that it calls.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7909>
This patch fixes this Meson build error.
$ meson builddir \
-Dshared-llvm=disabled
-Ddri-drivers=''
-Dbuild-tests=true \
-Dgallium-drivers=swrast \
-Dvulkan-drivers=''
[...]
/usr/bin/ld: src/gallium/auxiliary/libgallium.a(gallivm_lp_bld_misc.cpp.o): in function `llvm::InitializeNativeTarget()':
llvm/Support/TargetSelect.h:118: undefined reference to `LLVMInitializeX86TargetInfo'
/usr/bin/ld: llvm/Support/TargetSelect.h:119: undefined reference to `LLVMInitializeX86Target'
/usr/bin/ld: llvm/Support/TargetSelect.h:120: undefined reference to `LLVMInitializeX86TargetMC'
/usr/bin/ld: src/gallium/auxiliary/libgallium.a(gallivm_lp_bld_misc.cpp.o): in function `llvm::InitializeNativeTargetAsmPrinter()':
llvm/Support/TargetSelect.h:132: undefined reference to `LLVMInitializeX86AsmPrinter'
/usr/bin/ld: src/gallium/auxiliary/libgallium.a(gallivm_lp_bld_misc.cpp.o): in function `llvm::InitializeNativeTargetDisassembler()':
llvm/Support/TargetSelect.h:156: undefined reference to `LLVMInitializeX86Disassembler'
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7777>
We've been getting spurious failures from the new VC4 CI, which I believe
are due to this set of tests (which have been showing up along with a GPU
hang report in the list of flaky tests in the failing jobs). This was a
known issue I had in vc4.
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7998>
There are many issues with SDMA across many generations of hardware.
A recent example is that gfx10.3 suffers from random GPU hangs if
userspace uses SDMA.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7908>
This is an issue on the cheza platform, the theory is due to some old
firmware bug that will be fixed in future platforms. Given that cheza was
a target that didn't get released and we expect future platforms to be
fixed, just detect the issue and restart.
I've noticed this error in my CI monitoring less than once a week.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7993>
among all Android gen rules '::' was used only here to declare dependencies;
mesa development and stable branch are worth receiving the fix
Fixes the following building errors with Android 7:
obj/STATIC_LIBRARIES/libmesa_nir_intermediates/spirv/gl_spirv.P:184: *** target file
gen/STATIC_LIBRARIES/libmesa_nir_intermediates/spirv/vtn_generator_ids.h' has both : and :: entries. Stop.
Cc: "20.3" <mesa-stable@lists.freedesktop.org>
Fixes: 1070bba19e ("android: fix SPIR-V -> NIR build")
Reported-by: youling257 <youling257@gmail.com>
gets rid of: WARNING: Newline character in a string detected, use '''
(three single quotes) for multiline strings instead.
Reviewed-by: Yevhenii Kharchenko <yevhenii.kharchenko@globallogic.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7946>
Apparently LRZ will be read/written regardless of depth being enabled or
not, so we have to make sure these registers are zero.
Fixes: 1d83f5ae84 ("turnip: disable LRZ on vkCmdClearattachments() 3D fallback path")
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7899>
There is an early return if cmd->state.predication_active is true, so do
the LRZ invalidate before that.
Fixes: 2f79e00664 ("turnip: disable LRZ on vkCmdClearAttachments()")
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7899>
This avoids a possible issue with MSAA sysmem clears, which use a 3D clear
path which assumes draw states are disabled, and are emitted in draw_cs in
BeginRenderPass.
(checking for TU_CMD_DIRTY_DRAW_STATE also allows not emitting the draw
states if they will be re-emitted on the next draw anyway. the previous
patch makes it so TU_CMD_DIRTY_DRAW_STATE is always set outside of
renderpasses)
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7899>
* do the disable in EndRenderPass2 to fix the missing disable for sysmem
* we don't need a disable at the end of every tile, or between binning pass
and gmem pass (the first draw in draw_cs emits all the draw states)
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7899>
The packet size is constant and assumes all states, except for the 2 input
attachment states. (this means we get an invalid packet if DIRTY_LRZ isn't
set when DIRTY_DRAW_STATE is set).
Fixes: 3c07a14998 ("turnip: enable LRZ")
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7899>
This avoids emitting compute-related state in the graphics pipeline
(tu6_emit_xs_config was being called for compute stage).
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7899>
Allow for separate rules to be used to generate the .c and .h (partially
to make it easier for scons build, and partially because that is just a
better practice).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7974>
Avoids unnecessarily creating an extra thread when tracing is not
enabled. Which also side-steps a chrome/ium sandbox issue with
the setscheduler call in u_queue.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7974>
If ACCESS_NON_UNIFORM is not specified, we can assume the resource is
uniform. This requires nir_lower_non_uniform_access to remove that flag.
A few Detroit: Become Human shaders use a index sourced from a fragment
input which is expected to be uniform.
shader-db (Navi):
Totals from 8 (0.01% of 127638) affected shaders:
SGPRs: 224 -> 384 (+71.43%)
VGPRs: 208 -> 112 (-46.15%)
CodeSize: 5360 -> 5344 (-0.30%); split: -1.49%, +1.19%
Instrs: 1036 -> 1028 (-0.77%); split: -1.93%, +1.16%
VMEM: 1320 -> 608 (-53.94%)
SMEM: 384 -> 336 (-12.50%); split: +14.58%, -27.08%
VClause: 24 -> 16 (-33.33%)
SClause: 48 -> 56 (+16.67%)
PreSGPRs: 124 -> 216 (+74.19%)
PreVGPRs: 168 -> 88 (-47.62%)
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5201>
In the Chrome WebGL Aquarium stress test, 20 instances of Chrome will run
Aquarium simultaneously over 20+ hours. That causes Chrome crash.
During the stress, glBeginQueryIndexed is called frequently.
1.Each query will only use 32 bytes from query_buffer_uploader. After the offset
exceed 4096, it will alloc new buffer for query_buffer_uploader->buffer
and release the old buffer.
2.But iris_begin_query will call u_upload_alloc when the offset changed, and it
will increase the query_buffer_uploader->buffer->reference.count every time
when it called u_upload_alloc.
3.So when u_upload_release_buffer try to release the resource of
query_buffer_uploader->buffer, its reference.count is
already equal to 129. pipe_reference_described will only decrease its reference
count to 128.So it never called old_dst->screen->resource_destroy.
4.The old resouce bo will never be freeed. And chrome will called mmap every time
when it alloc new resource bo.
5. Chrome process map too many vmas in its process. Its map count exceed the
sysctl_max_map_count which is 65530 defined in kernel.
6. When iris_begin_query want to alloc new resource bo, it will meet NULL pointer
because mmap return failed. Finally chrome crashed when it access this NULL resource
bo.
The fix is decrease the reference count in iris_destroy_query.
Patch is verified by chrome webgl Aquarium test case for more than 72 hours.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: Yang Shi <yang.a.shi@intel.com>
Reviewed-by: Alex Zuo <alex.zuo@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7890>
avoids errors seen when building on OpenBSD/amd64
../src/amd/compiler/aco_instruction_selection.cpp:1677:62: error: ambiguous conversion for functional-style cast from 'unsigned long' to 'aco::Operand'
bld.vop3(aco_opcode::v_mul_f64, Definition(dst), Operand(0x3FF0000000000000lu), tmp);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
glibc uses unsigned long for uint64_t on LP64 archs and unsigned long long for
uint64_t on ILP32 archs. On OpenBSD unsigned long long is used for uint64_t
on all archs.
The Operand constructors are uint8_t uint16_t uint32_t uint64_t
use UINT64_C so lu or llu suffix will be used as needed.
Fixes: df645fa369 ("aco: implement VK_KHR_shader_float_controls")
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Tony Wasserka <tony.wasserka@gmx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7944>
The fp64 emulation is not prepared for vectorized 64 bit code, so
if the driver doesn't ask for lowering to scalar by itself, do it before
lowering to soft-fb, and run a vectorizazion pass afterwards.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7961>
Juan A. Suarez Romero
Marcin Ślusarz
Vinson Lee
Eric Anholt
Marek Olšák
Mauro Rossi
Mike Blumenkrantz
Michel Zou
Ian Romanick
Jonathan Marek
Witold Baryluk
Rob Clark
Rhys Perry
yshi18
Jonathan Gray
Gert Wollny