The PACK32 Vulkan formats need to map to the corresponding XYZWxxxx pipe
formats, since the latter take endianness into account.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8394>
The gcc we're using (and quite possibly newer ones) throws a really
stupid error:
../src/gallium/drivers/nouveau/nouveau_buffer.c:765:22: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
buffer->address = (uint64_t)user_ptr;
Which... address is a uint64_t, and user_ptr is a void *, so this is
completely unambiguously safe to do. Apparently casting to uintptr_t
squelches this, so do that instead.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8394>
When running gles3 deqp's with ETNA_MESA_DEBUG=deqp we fake streamout support.
CSO thinks that streamout is supported and calls ctx->pipe->set_stream_output_targets(..)
in cso_destroy_context(..) which results in a null-pointer access.
Add a stub to make development easier.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8382>
The general convention we use is "pscreen" for the pipe_screen, and
"screen" for the zink_screen, so let's stick with that here also.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8402>
To match hash_alu_src(), this should return false if both are different
non-const ssa defs.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8391>
NetBSD's variant has a different prototype from the Linux version
the code expects. It might make sense to add support for NetBSD's
version, however, since NetBSD defaults to not allowing non-root
users to set processor affinity, there would be little gain here.
This is a build fix for NetBSD.
Signed-off-by: Nia Alarie <nia@NetBSD.org>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
CC: 20.3 <mesa-stable@lists.freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7947>
Fix defect reported by Coverity Scan after commit 95527fe229
("clover/module: add a printf support to module (v5)").
Uninitialized scalar variable (UNINIT)
uninit_use_in_call: Using uninitialized value
m.printf_strings_in_buffer when calling module.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8322>
For color buffers, conditional fast clears can cause aux-state tracking
to lose information necessary for resolves later on.
For depth buffers, they never actually worked because they occurred
unconditionally. Even if they were conditional, they would suffer from
the same issues as color buffers.
Enables iris to pass the nv_conditional_render-clear-bug piglit test.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3565
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7762>
Apart from an issue with fast clears that will be addressed soon,
aux-state tracking with conditional rendering works because the
aux-state info needed for performing required resolves is never lost.
Add comments explaining how this works. Assertions are omitted to avoid
having to pass render_condition variables into
iris_resource_prepare_access and iris_resource_finish_write.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7762>
Cleaned up a bit of addressing math in the shader I just had to debug.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8373>
Until just recently ("vrend: Fix TGSI UIF/IF behavior"), virgl does "if
(any(bvec4(src0)))" instead of "if (src0.x != 0)", despite the tgsi.rst
documentation and tgsi_exec agreeing on the second form. It's harmless to
work around it, since apparently NTT was the only one to not have scalar
swizzled the if condition.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8373>
BRK/CONT don't take a label, as shown by tgsi_opcode_tmp.h and the lack of
any users of a label on those instructions in tree. I can't find any user
of ENDLOOP's label. Additionally, GLSL-to-TGSI apparently never set up
the BGNLOOP label, so even nvfx's usage probably wants us to not set it.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8373>
This doesn't set the atomic flag the way the old TGSI path used to,
leaving us with a possible delta in caching modes on nv50 tgsi.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8373>
GLES3 supports pause/resume of xfb. However since there's no geometry
shader support in ES3, it's a lot easier to figure out the offsets to
use. This makes it work for the dEQP tests at least.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8346>
In DXIL, the FMA instruction only supports 64-bit operations. However,
back when we implemented support for this, there were only a single
switch for lowering all ffma instructions, so we couldn't easily use it.
But now that there's separate flags to lower ffma on 16, 32 and 64 bit,
we can lower 16 and 32 bit ffmas, and leave 64 bit ffmas alone.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8349>
When I originally added the FFMA opcode here, I added the FMAD opcode
instead of the FMA opcode. The reason for this is that it works on
32-bit values as well, so that seemed like a better fit.
But that's not correct, as the FMA opcode isn't a fused operation, so
let's correct the opcode.
This isn't currently in use, because we currently lower away all ffma
opcodes on the NIR level, but that's about to change.
While we're at it, let's also update the opcode name to match the DXIL
documentation.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8349>
We don't support stencil-exports yet, and even when we will, we might
not support it on all hardware. So we really need an alternative plan
here, even when render_condition_enable is true.
Fixing this properly is much more involved, and depends on reworking
render-condition along the lines that we do in !7746 to support pausing
and resuming properly first. So let's do the minimal thing, which is to
allow this to work in cases where no render-condition is active.
Fixes: 767f70dfe1 ("gallium/util: fix util_can_blit_via_copy_region for conditional rendering")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4056
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8379>
To properly support multi-planar images, we don't want to set metadata
on anything other than the first plane. To achieve this radv currently
checks for the image TILING and assumes LINEAR means it's not the first
plane.
However this doesn't account for images with a single LINEAR plane. We
still want to set metadata on those, e.g. to properly set the scanout
bit in the tiling flags.
Instead of checking for LINEAR, check if the offset is zero. Only the
first plane has a zero offset on AMD.
This mirrors the radeonsi logic [1].
While at it, move the metadata declaration into the if block.
[1]: 6fecdc6dda/src/gallium/drivers/radeonsi/si_texture.c (L710)
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8086>
