Adds a cost field to radv_ir_node and uses it to model the cost of tree
depth. This improves framerates by 2% if my benchmarking is correct.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19756>
Obviously there can't *actually* be memoryless render targets, because
how would partial renders work? The control stream with memoryless looks
like everything would if it went to memory (e.g. full 2D MSAA
attachments for the partial loads/stores even if only a resolved
2D image for the final store). Except the memoryless attachments all
load from the same address 0xeeee0000. Clearly that's not actually what
happens, so what gives? Unclear... but I see the magic bits mentioned
here set, and I assume there are some firmware (or kernel) shenanigans
used to JIT allocate the backing storage for partial renders.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19811>
Stencil texturing is easy: S8_UINT is textured like R8_UINT (with a
little swizzle fixup), and stencil is always S8_UINT thanks to
u_transfer_helper. So we just need to do some fixups to make
u_transfer_helper's seperate_stencil work and everything will work out.
Passes dEQP-GLES31.functional.stencil_texturing.*
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19811>
error message:
In file included from ../../src/gallium/drivers/llvmpipe/lp_test_blend.c:44:
../../src/gallium/drivers/llvmpipe/lp_bld_blend.h:47:21: error: ‘enum pipe_blendfactor’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
47 | enum pipe_blendfactor factor_src,
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19676>
Because uint comes from pipe/p_compiler.h, and that depends will be removed in future
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19676>
As ubyte comes from p_compiler.h, so do not use it,
and the code calles util_copy_rect may use args with type uint8_t*, ubyte* or unsigned char*,
so use the type void* that consistence with memcpy
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19676>
error message:
../../src/gallium/auxiliary/tgsi/tgsi_info.h:92:30: error: ‘enum pipe_shader_type’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
92 | tgsi_get_processor_name(enum pipe_shader_type processor);
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19676>
uint is from pipe/p_compiler.h
error message:
../../src/amd/compiler/aco_instruction_selection.cpp:11061:4: error: 'uint' was not declared in this scope; did you mean 'rint'?
11061 | uint en_mask = 1;
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19676>
Use 0 instead of PIPE_OK in u_hash_table.c
Because pipe_error and PIPE_OK is comes from pipe/p_defines.h that doesn't belong
to src/util/
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19676>
util/u_inlines.h is comes from src/gallium/auxiliary/util/u_inlines.h,
so when possible, do not use it under src/util folder
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19676>
This syncs all our headers with their canonical versions from Khronos.
Of particular note, CL headers repo does not have cl.hpp and cl2.hpp has
been depricated all in favor of opencl.hpp which is the new canonical
header. Fortunately, nothing in Mesa uses any of the C++ headers so
this shouldn't break anything.
Acked-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19816>
This pass can insert if blocks, therefore no dominance/block_index for
you.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19818>
The unsaturated arithmetic won't overflow/borrow, and may be faster.
No fossil-db changes.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19473>
The result should never be larger than uint_max. This doesn't need a
special path.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19473>
