LLVM uses __declspec(restrict) which breaks because Mesa define restrict
as __restrict. Move the LLVM headerse up to dodge the macro.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6180>
packing_16 with floats assumed 1 (shadow) or 4 components. But query
lod operations return 2.
Fixes the following test with v3dv:
dEQP-VK.ycbcr.query.lod.fragment.r8g8b8a8_unorm
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5863>
ACCESS_COHERENT may be set for a specific load/store in the case of
atomic loads/stores.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6063>
Similar to other skips for texture queries that don't actually sample
the texture and which results are not packed.
We can't use nir_tex_instr_is_query() here to skip the lowering for all
queries since that causes regressions in Piglit. Apparently, we do want
to lower some of the query results. In particularly, the LOD query.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6169>
This gets us consistent hcN access with our drivers, for experimenting.
We don't know what the other bit does yet, but let's not have to debug
that later.
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6179>
Trying to figure out how uniforms were working, I found that computerator
had different behavior from our GL fragment shaders. Given that 3xx had
an SP_ bit for this (thanks flto@ for the note), it was a matter of
pasting bits of SP_* setup into computerator until I got the GL behavior.
I named it the same as the a3xx register.
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6179>
We would be making a MOV from a u32, when we should be loading from a
16-bit value. This likely didn't bite us because we only do mediump in FS
and CS so far, and indirect uniforms are usually in a VS (and usually
highp).
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6179>
We should probably dump the constants, too, but this is useful to me for
now.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6179>
I think everyone trips over "how does this relate to nir_const", and I was
curious if I could redefine the units of the constant_data_size / indirect
offsets.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6179>
Now that num_ubos is correctly maintained, we can just trust it. Fixes an
assertion failure in freedreno I triggered on
dEQP-GLES31.functional.ubo.random.all_per_block_buffers.1 for reasons I
don't really understand.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6179>
This moves the semaphore implementation and tu_QueueSubmit to
tu_drm.c, such that that's the only file including xf86drm.h and
msm_drm.h. This way, the entire kernel interface is contained in
tu_drm.c
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5999>
Turns out that respecting the order of parameters is important.
Reported-by: Michael Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Fixes: 5425968d2e ("anv: Implement VK_EXT_custom_border_color")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6175>
This field enables MSAA, either writing samples to separate surfaces, to
a single large-bpp surface, or implicitly resolved and to a single
surface.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6161>
RADV_PERFTEST=aco no longer exists, ACO is the default compiler.
RADV_PERFTEST=llvm is deprecated, use RADV_DEBUG=llvm instead.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5662>
This patch fixes the case where less number of reference surfaces created and destoyed
on need basis. The problem comes when we are refereing old assoiciated data for newly
created target buffer with same address. Here old target buffer destroyed as that
surface is no more used as reference for next frames and when we create a new surface
for the next frame to process we will get the surfaceid and same target address
of destroyed surface.
When new surface/surface->buffer/target ,target->codec is null as we cleared when we
destroy this surface, but per ref_mapping logic, it was taking null associated data
i.e.0 as curr_ref_idx. Hence total reference mapping table goes wrong with wrong data.
Beacuse of this, we have seen corrupted vp9 decoded frames.
Signed-off-by: SureshGuttula <suresh.guttula@amd.corp-partner.google.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5452>
Incorrect implementation has been found during code surfing.
v3d implementation used for reference.
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Icenowy Zheng <icenowy@aosc.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6076>
This was meant to handle incoherent accesses by always flushing them,
but it accidentally checked for the coherent variant instead. As a
result e.g. a vkCmdClearImage() followed by a renderpass using the image
didn't get any flushes, resulting in the same sort of corruption seen
with sysmem renderpass clears. This happened to be exposed via some
tests that used multiview.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6009>
The OpenGL flavor of SPIR-V allows for samplers inside structs. This
means that our simple array-of-array handling isn't sufficient and we
need something substantially more complex for generating NIR types.
Fixes: 14a12b771d "spirv: Rework our handling of images and samplers"
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6065>
