Looks like m2mf bails if a line is >64k in width for tiled textures
(even if only a sub-section is copied as long as any part is beyond the
64k mark).
Fixes a number of GLES3 accuracy tests which made 8k-wide textures which
were read out as RGBA32_UINT, leading to problems.
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/8396>
This happens during "3d" blit operations, where we must reinterpret it
as color in order to support stencil/depth masking. However the hardware
isn't necessarily amused by this, esp when multiple draws are queued up.
Throw in serialize calls in order to get it to flush out previous draws.
This was noticeable in the test
dEQP-GLES3.functional.fbo.invalidate.sub.unbind_blit_msaa_stencil,
although 3d blit operation had to be forced on nvc0 where it's much
rarer.
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/8396>
Under some very rare circumstances, the OP_EXPORT will refer to a def
provided by a mov. When we then try to make the defining op write to the
export directly, it blows up. Reuse the existing setDst helper which
handles this and more for the long encoding.
Fixes dEQP-GLES3.functional.shaders.precision.int.highp_mul_vertex
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/8396>
This patch also replaces lower_negate with lower_ineg / lower_fneg.
The fneg semantics have been clarified as of Version 1.5, Revision 1
of the SPIR-V specification, which means that the previous lowering
to fsub is not a viable solution anymore, and is replaced with
lowering to fmul(x, -1.0).
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6597>
The Bifrost compiler relies on nir_lower_uniforms_to_ubo() to lower
uniforms to UBOs, and s->info.num_ubos is already incremented when a
UBO #0 is created.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8418>
If the instruction being coalesced would be vectorized but the target
doesn't support vectorizing that op, skip coalescing.
Reuse the callbacks from alu_to_scalar to describe which ops should not
be vectorized.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6506>
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>
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>
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>
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>
some vulkan drivers (e.g., amdvlk) advertise absolutely huge values here,
resulting in bitmask overflows everywhere since gallium assumes a max of
32 for vertex inputs and nir uses 64bit types for others
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8318>
NTT doesn't handle uniforms, and requires them to have been lowered to
UBOs. But for drivers that don't set
nir_shader_compiler_options::lower_uniforms_to_ubo to true, this won't
have happened yet. Neither Zink nor V3D sets this option, and in the
case of Zink this isn't trivial to change.
So let's lower uniforms to UBOs in this case in NTT instead.
Fixes: 03c60762f5 ("gallium/ntt: Fix load_ubo_vec4 buffer index setup.")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4047
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8365>
