If we have 2 pipelines that consume the same push constant data
but where one of them only uses direct access and the other has
indirect access, a draw with the first pipeline would clear the
dirty flag without updating the UBO and by the time we bind and
draw with the second pipeline we won't upload the constants either
because the first draw cleared the dirty flag.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17536>
Since we allocate this ourselves we can immediately add it to the
job at the time we allocate it.
This also fixes a bug we introduced when we implemented inline
uniforms because since that commit, if we had an inline uniform
buffer at index 1 which happend to have indirect access we would
track it in slot 0 instead of slot 1, potentially overwriting
the push constant buffer reference.
Fixes: ea3223e7a4 ('v3dv: implement VK_EXT_inline_uniform_block')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17536>
We have code in there to allocate various segments of MAX_PUSH_CONSTANTS_SIZE
to handle the case of various draw calls in the same command buffer requiring
different push constants, so we are implicitly expecting it to be larger than
this. In fact, this only works now because when we allocate a BO we are always
at least allocating a full page, so the least we ever allocate is 4096 bytes,
so be explicit about it to avoid confusion.
Also, since we were always mapping MAX_PUSH_CONSTANTS_SIZE and the mapping
always starts at the beginning of the BO, it looks like after the first copy
when the resource offset is not zero, we would be writing outside the mapped
range. Always map the full size of the BO instead to ensure this doesn't
happen.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17536>
Those fields have confusing names. They hold non dynamic state,
specified at pipeline creation that we copy into the dynamic state of
the command buffer whenever we bind a pipeline. This non dynamic state
might get picked up in the dynamically emitted instructions of the 3D
pipeline because our HW packets are not exactly splitted like the
Vulkan API.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17601>
This implements the "tortoise and the hare" algorithm for detecting
cycles in graphs. We use the caller's iterator as the hare and our own
internal copy as the tortoise. Conveniently, VkBaseOutStructure (and
VkBaseInStructure which is identical except the pointer type on pNext)
have a pointer we can use for the tortoise and an sType which we can use
for a counter to ensure we only increment the tortose every other loop
iteration.
There are more efficient algorithms than tortoise and hare but they
require allocating memory for something like a hash set of seen nodes.
Since this for debug purposes only, it's ok for it to be a bit
inefficient in the case where it hits the assert. In the usual case of
no loops, it's the same runtime efficiency as the unchecked version
except that it does a tiny bit of math and 50% more pointer chases.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17596>
In addition to hopefully generating shorter code, this optimizes out a
comparison of a mediump-cast value in
dEQP-GLES2.functional.shaders.algorithm.rgb_to_hsl_fragment passed
through ANGLE, and allows the test to pass. We believe it to be a
test bug, but emitting better code like apparently everyone else does
is also a fine result.
No change on GLES gfxbench shaders.
Fixes: #6585
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17546>
dri3_glx.c includes xshmfence and glxcmds.c includes xf86vm, neither of
which are listed as dependencies of the glx lib in the meson.build file.
Consequently, those files would fail to compile on machines that did not
have xshmfence and xf86vm installed globally. This commit rectifies the
issue by adding the missing dependencies
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17585>
GL drivers have an implicit default of "in bounds" for unwritten clipdistance
values, but some (layered) drivers have to deal with api mismatch which
prevents that implicit value from being used after the shader
gets mangled by various compiler passes
to avoid issues here, write out all members of the clipdistance array
with zeroes at the very start of the shader such that any values the
shader actually writes will naturally overwrite the implicit zero and
any unwritten values will now be written as zero
fixes#6845
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17498>
this can get called from multiple threads with the recent llvmpipe
overlapping rendering changes, so make sure to lock around the
map/unmapping so they can't race.
This should fixes some crashes seen with kwin.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Tested-by: Adam Williamson (Fedora)
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17531>
