This is what most logical SEND messages do when they take a variable
number of components. 'inst->mlen' is expected to be zero for logical
SEND opcodes, which are expected to behave like plain arithmetic
operations, so certain automated transformations (like SIMD lowering)
can manipulate them without opcode-specific special-casing.
Guessing the number of components from 'inst->mlen' has other
disadvantages, because it requires duplicating the logic that infers
the message payload size in every use of the instruction -- Instead we
can just do the computation once during logical send lowering. In
addition on LNL platform this causes the 'inst->mlen' field of URB
writes to have units inconsistent with every other SEND instruction,
which is likely to lead to confusion and bugs down the road.
Rework:
* Marcin: update emit_urb_indirect_vec4_write
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25195>
v2: Account for 512b physical registers which causes the URB handle to be in FIXED_GFR 2 instead of 1.
XXX - Use fs_builder::vgrf() instead of open-coded dispatch_width calculations.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25195>
Rework:
* Sqaushed in changes Marcin Ślusarz's patches:
* "intel/compiler: skip adding 0 to payload address"
* "intel/compiler/xe2: drop masking off top 8 bits of URB handle"
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25195>
If the high 32 bits were zero, this would be umin(find_lsb(lo), 31). This
evaluates to 31 if lo is also zero, instead of -1.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Fixes: 9293d8e64b ("nir: Add find_lsb lowering to nir_lower_int64.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25409>
We missed out that ICL+ added a programming requiring a CS_STALL.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25426>
Before this commit, zink_format_clamp_channel_color() ignored the format
swizzle, so it was assuming that for emulated formats like alpha,
alpha-luminance etc. that the color had already been swizzled to match
the internal format rather than the emulated one. It's somewhat confusing
that passing in e.g. A8_UNORM actually means R8_UNORM, and led to a bug
when using VK_FORMAT_A8_UNORM for texture border colors because we
didn't swizzle it back. It also wouldn't have worked for media formats
like R10X6G10X6 due to the void channel in the middle.
In order to fix this, we need to untangle the mess in its users.
For convert_color() used when clearing, this means we now need to clamp
and then swizzle instead of swizzle and then clamp, and we can drop the
hack for A8_UNORM.
For texture border colors, the state tracker duplicates colors for the
emulated formats to help drivers, which zink was previously relying on,
but fixing zink_format_clamp_channel_color() breaks this because it
assumes that those duplicated colors are useless and clamps them.
However, because we know the format we can just swizzle the border color
ourself, which convert_color() was already doing. So, we pull that out
into a common zink_convert_color() function that handles both clamping
and format emulation, and have both clearing and border color handling
use it.
This fixes A8_UNORM in turnip+zink once we enable it.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25001>
When trying to create a headless Vulkan instance without a display
device available, device enumeration would fail.
Part of the physical device creation code already accounts for a missing
display device, allow device enumeration to continue in that case too so
headless instances can be created.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25313>
This GNU extension caused a bug where a void pointer was modified then
interpreted as uint32_t* (instead of the other way round). Force a
compile error to (hopefully) prevent this from happening again.
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
Reviewed-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25327>
Besides being not standard C, one instance (in pvr_cmd_buffer.c) was a
bug caused by adding-then-casting, which would likely have been caught
if void pointer arithmetic were not allowed.
All instances detected by -Wpointer-arith have been fixed here.
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
Reviewed-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25327>
