cmd_size was changed to size_t in commit 4b2445916e ("glthread:
change sizes to unsigned or size_t where needed").
Fix defect reported by Coverity Scan.
Macro compares unsigned to 0 (NO_EFFECT)
unsigned_compare: This less-than-zero comparison of an unsigned
value is never true. cmd_size < 0UL
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8024>
Fix defects reported by Coverity Scan.
Identical code for different branches (IDENTICAL_BRANCHES)
identical_branches: The same code is executed regardless of
whether 0 is true, because the 'then' and 'else' branches are
identical. Should one of the branches be modified, or the entire
'if' statement replaced?
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8001>
With the block's end_ip accidentally being the ip of the next instruction,
contrary to the comment, you would end up doing end-of-block freeing early
and have the value missing when it came time to emit the next instruction.
Just expand the ips to have separate ones for start and end of block --
while it means that nir_instr->index is no longer incremented by 1 per
instruction, it makes sense for use in liveness because a backend is
likely to need to do other things at block boundaries (like emit the if
statement's code), and having an ip to identify that stuff is useful.
Fixes: a206b58157 ("nir: Add a block start/end ip to live instr index metadata.")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7658>
It made the nir_print_shader() for NIR_TO_TGSI_DEBUG not match up with the
instructions being emitted, confusing me. Given that I'm seeing only like
1/3 shrinking in the SSA indices, just drop the reindexing since it's not
doing much (and we don't store that much per SSA index).
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7658>
Getting the live SSA defs will do it if necessary, and that liveness is
what we use the instr index for. (We used to need to do it manually, and
cleanups for merging resulted in the index being treated as metadata).
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7658>
In 2900f82e19 I mistakenly used tc_set_resource_reference in both
tc_transfer_unmap and tc_call_transfer_unmap.
This causes a leak because tc_call_transfer_unmap clears dst before
acquiring a reference, so it must only be used when initializing
tc_payloads.
This fixes the perf drop reported by Marek in MR 7098.
Fixes: 2900f82e19 ("gallium/u_threaded: fix staging and non-staging conflicts")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8035>
Add support for the half float texel type and pixel types.
This enables the OES_texture_half_float extension.
Tested with piglit test oes_texture_float (half float and with linear
filtering) and passes all deqp half float related tests.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8020>
In targets that support half float textures but not float textures (so
without ARB_texture_float), the previous logic did not allow for
enabling half float texture support in desktop OpenGL.
OES_texture_half_float is only valid for OpenGL ES 2.0 contexts, so
include ARB_half_float_pixel in the logic to cover OpenGL too.
Remove _mesa_is_gles3 from the check since in case of a gles3 context,
OES_texture_half_float is already assumed to be enabled.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8020>
According to the spec for both vkCmd{Begin,End}TransformFeedbackEXT(),
if pCounterBufferOffsets is NULL, then it is assumed the offsets are
zero.
Fixes crash on dEQP-VK.transform_feedback.simple.backward_dependency_no_offset_array
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8057>
TFU can convert from these new formats, but can not autogenerate
mipmaps from them.
Hence we need to set what is the purpose to know if the formats are
supported or not.
v1:
- Use the same and shorter variable name (Alejandro)
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8050>
When loading the depth, we want to store component X of the texel fetch
result into position.Z which can't be expressed without an extra MOV
unless the backend replicates the depth.
Stencil is always expected in the Y component, but some TGSI shaders
assume it will also be available in X, which only works if the backend
replicates the stencil value.
Let's fix those shaders so backend drivers are not forced to replicate
the depth/stencil values.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7922>
The classic OSMesa renders directly into user memory using
src/mesa/swrast, while gallium OSMesa renders using softpipe or llvmpipe
and copies out at glFlush() time. This would make gallium look like a
worse choice for OSMesa, except that swrast is:
1) Painfully slow to render compared to llvmpipe
2) Incorrect at derivatives
3) Limited to GL 2.1 instead of GL 4.6
In my survey of OSMesa users, debian was the remaining holdout with
classic OSMesa in use on hurd and some rare non-LLVM-supported
architectures (sh4, alpha, etc.). As of today, they've switched to
softpipe-based gallium OSMesa for them.
To prevent people from running the wrong OSMesa (to the extent that
running OSMesa can ever be the right thing), delete the classic
version.
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Closes: #320Closes: #877Closes: #2297
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1243>
Since the depth buffer starts out as a malloc, and we weren't clearing it,
you could get undefined values in your top 8 bits. This should fix
intermittent failures of the depth test.
(Sadly, valgrind wasn't catching this, presumably because the 32-bit value
there *is* written, just some bits are left undef)
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1243>
