When vkGetQueryPoolResults() is called with VK_QUERY_RESULT_WAIT_BIT
set, the driver is supposed to wait for the query to become available
before returning.
Currently, radv returns once the query is indeed ready, but it returns
VK_NOT_READY. It also fails to populate the results.
The problem is a missing volatile in the secondary check for query
availability. This patch removes the secondary check altogether since it
is redundant with the preceding loop.
This bug was found with an unreleased version of SteamVR.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
program_invocation_name and program_invocation_short_name are both GNU
extensions. I don't believe one can exist without the other, so only
check for program_invocation_name.
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
It's better to test for needed functions instead of using external
knowledge about presence in this or that C library.
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Same rationale as the previous patch, but additionally these checks just
seem entirely unnecessary. pthread_self() has been used in Mesa since at
least 1999.
Acked-by: Eric Engestrom <eric.engestrom@intel.com>
glibc-2.12 was released in 2010. No one is building new Mesa against 9
year old glibc, and removing these checks allows the code to work on
other C libraries like musl.
Acked-by: Eric Engestrom <eric.engestrom@intel.com>
We can have a access flag already set here so just augment the
existing ones.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 0fb61dfdeb ("spirv: propagate access qualifiers through ssa & pointer")
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
With the help of Sagar, Ian and Ivan.
v2: Fix dependencies (Ian Romanick)
v3: 1) fix function name (Marek Olsak)
2) Add check for extension enable (Marek Olsak)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This will be used to support one of the function from
Ext_texture_shadow_lod specification.
With the help of Sagar, Ian and Ivan.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
With the help of Sagar, Ian and Ivan.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Conceptually, r28-r29 (as used for reading) and r28-r29 (as used for
writing) aren't registers at all, merely push/pull arrangements. So you
can't feed a texture result back into itself without explicitly moving
in the middle.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
instr->type is the type of the array element, not the type of the array
being dereferenced. Rather than fishing out the parent type, just use
parent->num_children which should be the length plus 1. While we're here
add another assert for the issue fixed by the previous commit.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111251
Fixes: 156306e5e6 ("nir/find_array_copies: Handle wildcards and overlapping copies")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
There was an off-by-one error.
Fixes: 156306e5e6 ("nir/find_array_copies: Handle wildcards and overlapping copies")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Added support for avx512 scatter instruction. Non-avx512 will
now call into a C function to do the scatter emulation.
This has better jit compile performance than
the previous approach of jitting scalar loops.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
This move gets us back to parity with global manager
in that we can dump render context buckets now.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
In most cases this is not needed because the usual is that when a
separate stencil is written, the parent resource is also written.
This is needed if we have a separate stencil, no depth buffer, and the
source and destination is the same, as in that case the stencil can be
updated, but not the parent source (like if you are blitting only the
stencil buffer). On that situation, the following access to the
stencil buffer would clear the stencil buffer (so overwritting the
previous blitting) cleared because the parent source has
v3d_resource.writes to 0.
As far as I see, that situation only happens with the
GL_DEPTH32F_STENCIL8 format.
Note that one alternative would consider that if the separate_stencil
has been written, the parent should also be considered written (and
update its "writes" field accordingly). But I found this patch more
natural.
Fixes the following piglit tests:
spec/arb_depth_buffer_float/fbo-stencil-gl_depth32f_stencil8-blit
spec/arb_depth_buffer_float/fbo-stencil-gl_depth32f_stencil8-copypixels
the latter regressed when internally glCopyPixels implementation
started to use blitting. So:
Fixes: 131d40cfc9 ("st/mesa: accelerate glCopyPixels(STENCIL)")
Reviewed-by: Eric Anholt <eric@anholt.net>
This patch decouples radv_shader.h from any LLVM dependency.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
In fact, the description of the workaround states that the mask field
doesn't work correctly on gen10, and we need to set it to 0xffff even we
we only want to update a single field:
"The mask bits are not implemented properly on 3DSTATE_3D_MODE. Driver
must always program bits 31:16 of DW1 a value of 0xFFFF. This means
if it is only updating 1 field, it must update all the fields to the
correct value."
So unless we want to change any of the fields of 3DSTATE_3D_MODE,
there's not need to emit. Additionally, it seems this workaround is not
required on gen11. And last but not least, this workaround is not
implemented on iris or anv, and it doesn't seem to be missed there.
So let's just remove the whole thing.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We accidentally started copying a full 64-bit value rather than copying
a 32-bit offset and zeroing the top 32-bits. This caused us to compute
bogus vertex counts which could lead to GPU hangs in some cases.
Thanks to Clayton Craft for catching the regressions!
Fixes: 0e24d10ff5 ("iris: Use gen_mi_builder to handle CS ALU operations.")
It's kind-of an anomaly that the Intel drivers are still treating
gl_FragCoord as an input. It also makes zero sense because we have to
special-case it in the back-end.
Because ANV is the only user of nir_lower_wpos_center, we go ahead and
just update it to look for nir_intrinsic_load_frag_coord as part of this
patch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This fixes glsl-fcoord-invariant-pass.shader_test on drivers that set
GLSLFragCoordIsSysVal which includes radeonsi among others.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Seems like RB_BLIT_SCISSOR needs to be aligned to (minimum?) tile size.
Fixes intermittent GPU hangs triggered by some of the three.js samples
on https://threejs.org/
Signed-off-by: Rob Clark <robdclark@chromium.org>
fishgl.com has a shader which does roughly:
foo = texture(...);
if (bar)
foo = texture(...);
after lowering phi webs to regs we end up w/ a vec4 reg (array). But
since it was not an indirect access, we try to skip the extra mov. This
results that the per-component fanout (split) meta instructions store
directly to the reg (array). Which doesn't work out in RA.
Signed-off-by: Rob Clark <robdclark@chromium.org>
0.45 has a few annoying bugs (like the one in !358 [1]), and 0.46 is
well over a year old by now, so let's move to it.
[1] https://gitlab.freedesktop.org/mesa/mesa/merge_requests/358
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Arcturus CHIP enum is less than Navi10, since it's still gfx9,
but its VCN version belongs to VCN2.x
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
different internal registers offset from previous HW
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>