It's emitted as part of the MSAA state but re-emitting the NGG culling
state isn't necessary because ps.reads_fully_covered isn't used.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36875>
Like RADV_CMD_DIRTY_CB_RENDER_STATE is dirty when the custom blend mode
is updated. Shouldn't fix anything in practice because dynamic_states
is unlikely 0 but better that way.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36875>
A tu_bo object can be in the process of being dumped during queue submit
while also being destroyed on a separate thread. During destruction, tu_bo
should be removed from the device's dump_bo_list before unmapping, this
way the mapping of any given tu_bo won't disappear while it's being dumped.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Reviewed-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36904>
These ops require more than three source values that could result
in readport conflicts, so check the readport configuration
before issuing alu operations and inject copy operations
when conflicts are identified.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36860>
When checking the readport config for a number of sources that
would be used in a multi-slot instruction, then return the index
of the source for which readport allocation fails.
With that we can later add a mov instruction to change the source
channels configuration.
In addition pass a std::array instead of a C-array to make the interface
more c++-like and prepare for the next patch.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36860>
This has gotten complicated enough that we need somewhere outside of the
driver itself to give an overall flow of how the feature is implemented.
This includes a few things that are enabled in the subsequent commits,
specifically the LRZ parts.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36475>
We don't go through the loop when there are no queues.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 884df891d7 ("anv: allow device creation with no queue")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36910>
This might actually fixes a couple of things because needed dynamic
states are computed before radv_emit_graphics_pipeline(), so dirtying
them too late doesn't make much sense.
This doesn't fix anything known.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36900>
When building as subproject, this will include libdisplay-info tests
when running `meson test` and they incorrectly detect edid-decode
binary being available causing the tests to fail. There are also
issues with 32bit build.
Updating to latest libdisplay-info doesn't seem like a good solution
as that pulls in additional build dependencies.
Since this is an optional dependency, drop the wrap file.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13657
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36897>
Venus renderer side has strict entry points sanitization based on the
app requested app api version + physical device api version. So on the
driver, we should follow the same for legacy client apps.
Meanwhile, VK_PIPELINE_STAGE_NONE can't be used when we hit the sync2
emulation path, so we swap it with VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT
placeholder for the 2nd sync scope there.
Fixes: 07cee75c39 ("venus: layer vkQueueSubmit2 over vkQueueSubmit w/o sync2")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36830>
With UBSan enabled, we get the following issue:
```
../src/compiler/glsl/ir.h:116:4: runtime error: member access within address 0x555637c62c10 which does not point to an object of type 'ir_instruction'
0x555637c62c10: note: object has invalid vptr
5f 76 61 6c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^~~~~~~~~~~~~~~~~~~~~~~
invalid vptr
```
This only happens the first time a ir_variable (which derives from
ir_instruction) is created; next calls don't show the issue any more.
The problem is with the following call in the `new()` operator:
```
((ir_instruction*)((uintptr_t)p))->node_linalloc = ctx;
```
In this case, the ir_instruction structure is not fully constructed and
thus UBSan complains about it. In the next calls, as the structure is
now fully constructed it doesn't complain any more.
The right approach would be fully creating the structure, and afterwards
doing the context assignment. But this would require quite a lot of
changes, passing the context through the constructors to assign it.
A simpler solution is just disabling this check for this case, as we
know what is happening.
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36884>
This specific macro allow to create a new() operator version with a
sanitizer flag disabled.
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36884>
Meson doesn't support for checking no_sanitize attributes, so we do it
manually through testing.
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36884>
Instead of being encoded as a contiguous 64-bit mask of individual registers,
the robustness information is now encoded as a vector of up to 4 bytes that
represent the limits of each of the pushed UBO ranges in 16 byte units.
Some buggy Direct3D workloads are known to depend on a robustness alignment
as low as 16 bytes to work properly.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36455>
The branch offset needs to fit in 8 bits, and with the shr(3) modifier,
this means the max legal value is 2040. Let's verify that while packing.
CID: 1503283
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36724>
We already have a more robust helper for this, so let's use it rather
than open-coding the same.
While we're at it, return early on error for readability here. There's
no need to continue the logic in those cases.
CID: 1444074
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36724>
lseek can return a negative value on error here. While it's not likely
to happen, let's add some error-checking here to prevent bad behavior if
we're unlucky.
CID: 1648299
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36724>
If the shader contains zero words, we would try to use -1 as an index
into an array at the end of this function, which would be bad. But
shaders without any words are, uh, no point in disassembling in the
first place, so this seems like a theoretical bug in the first place.
However, since the only thing we *really* care about last_next_tag is if
is TAG_BREAK or not, let's initialize it to TAG_BREAK instead. This
means we'll avoid a bogus print at the end here, even if we ended up
calling this on an empty shader.
CID: 1458835
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36724>
r1.w should be written, so let's add an assert here instead of making
lcra_add_node_interference() overrun a buffer here.
CID: 1510007
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36724>
