For export this is handled through the use of the udmabuf driver to
allocate a dmabuf we can control from userspace. For import this is
handled through mmap-ing a dmabuf handle. Please note that you can
only mmap a dmabuf handle if its linear and the dmabuf handle was
created with matching read and write permissions.
Co-authored-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27805>
this comes in two variants:
* util/memfd stuff with a header for metadata
* raw fd passing
for imports, both have to be tried since the import might be from a hw
device, but only the latter needs to be handled in winsys here
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27805>
store_def doesn't use the number of components, so we can drop the
checks for is_shador and simpliy increment the number of components.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28502>
Ubo0 is tricky. It exists if there were any uniforms when
lower_uniforms_to_ubo was run. If we try to run that ourselves,
it might be too late and DCE/remove_dead_variables might've been run,
which removed the uniforms and their accesses, without decrementing
num_uniforms. So we have no good way of knowing whether to declare
ubos from [0, N] or [1, N]. In practice this probably doesn't make
much of a difference but the logic is there so ¯\_(ツ)_/¯
If we use the nir option, then dead code isn't run, and num_uniforms
is a true indicator of whether ubo0 exists or not.
Note that this means we are no longer running this pass for internal
shaders that don't come from the GLSL compiler, so various places are
updated to query the nir info bit that's set by running this pass.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28535>
when set, this disables the use of vk swapchains and lets the dri frontend
manage buffers like any other driver
also document some kopper env vars
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28137>
this adds modes to the cap which allow drivers to opt out of the
frontend injecting gl_PointSize=1.0 into shaders while still getting
the uniform value uploaded
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28162>
Probably a sign that we need a better long term approach for dealing
with vdrm native context drivers driconf.
Fixes: 850267ef99 ("freedreno/a6xx: Add dual_color_blend_by_location")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28531>
shaderdb expects to receive shader info via a glDebugMessageCallback
callback. This patch updates print_pipeline_stats to use the
zink_context::dbg callback.
The format of the shader info is also updated to match what the shaderdb
report.py script expects. In particular, we use what report.py calls
"nv_format" since that is the closest to the current format.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28542>
This helps fix a number of piglit tests that exercise this
functionality, such as:
- piglit.spec.arb_texture_rg.fbo-clear-formats
- piglit.spec.ext_framebuffer_object.fbo-clear-formats
- piglit.spec.ext_texture_snorm.fbo-clear-formats
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23030>
When we dispatch an indirect compute job, the buffer containing
the indirect parameters should be marked as read (since the GPU
will read the parameters from there). Without this there's a
race condition if the CPU later updates the buffer.
Signed-off-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28512>
According to spec 4.6 section 8.14 (TEXTURE MINIFICATION), λ(x, y) is clamped to minLod and maxLod first and then used to choose minification or magnification: “If λ(x, y) is less than or equal to zero the texture is said to be magnified; if it is greater, the texture is minified. “
Prior to this change, Zink hard-coded minLod and maxLod to be [0.0, 0.25]. Some problems can be seen here:
If lambda originally is 0.3, and app sets minLod = 0.0f, maxLod = 0.0f, and minFilter = Linear, magFilter = Nearest:
According to the spec, lambda is clamped to 0.0 first, so magnification should be chosen, but on Zink lambda was clamped to 0.25, minification was chosen incorrectly.
Similarly if app sets minLod = 3.0f and maxLod = 3.0f
According to the spec, minification should be used regardless of lambda, but Zink would allow magnification if lambda was less than or equal to zero.
This is fixed by individually clamping minLod and maxLod to [0, 0.25].
Signed-off-by: daoxiang.gong <daoxiang.gong@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26933>
