The word offset is already handled by the above code, there's no need to
restrict the further restrict the swizzle. This pattern can come up with OpenCL.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18656>
The following IR is valid NIR:
vec1 16 ssa_0 = ...
vec1 32 ssa_1 = pack_32_2x16 ssa_0.xx
In this case, pack_32_2x16 takes in a two component vector, but the source
itself ssa_0 has only a single component. This is fine due to the shuffle, but
will fail the assert. Remove the assert and all is well.
Fixes test_relational.shuffle_copy.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18656>
These need a simple two-instruction lowering regardless of the size of float
involved. Fixes integer_ops.integer_divideAssign
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18656>
We don't have an 8-bit CSEL, so this is the best we can do. It's easier to write
the lowering as an algebraic rule since we don't need to do anything clever.
Fixes integer_ops.integer_clamp.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18656>
When we lower swizzles, we move source modifiers (except for the swizzle) after
the swizzle operation. In particular, we change the order of composition for
negates and abs. However, copying the source will copy the modifiers unless we
specifically strip the extra modifiers. That's harmless in practice on Bifrost,
which doesn't check for extraneous modifiers, but is incorrect IR and trips an
assertion in the Valhall packing code.
Fixes test_relations.relational_bitselect.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18656>
We're about to extend this pass to support 8-bit swizzles. That will be a
nontrivial change, so let's get some testing for what's already in the pass.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18656>
This is only a theoretical bug fix because, for now, we always reemit
everything. But this aligns launch_grid with draw_vbo and makes the intention
explicit, both seem like good things to me.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18656>
Fixes math_bruteforce.atan2 and contractions tests.
For OpenCL, we want to flush fp32 and preserve fp16, applying to both inputs and
outputs so F16_TO_F32 acts as preserve, which implements CL spec text:
> Denormalized numbers for the half data type which may be generated when
converting a float to a half using vstore_half and converting a half to a float
using vload_half cannot be flushed to zero
Note that our libclc builds flush denorms and rusticl does not advertise denorms
so we're expected to flush to zero. rusticl correctly sets the desired float
controls, we just have to match to the hardware requirements.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18656>
Bump to 2048, the minimum maximum for image support in the full profile of
OpenCL. The relevant hardware limit is 65536 so we have plenty of clearance.
Fixes api.get_image1d_array_info.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18656>
In NIR, txf does not take a sampler. However, in the hardware it does take a
sampler. If there is no sampler bound and we use txf, the hardware will read
back all-0's due to bounds checking. As a workaround, bind a trivial sampler and
use that.
As-is this workaround is Valhall specific, making use of an extra resource
table. I'm punting on generalizing back to Bifrost until I can discuss the issue
in more depth with Jason and Karol and figure out the right fix.
Fixes api.image_properties_query.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18656>
At some point in the future, adding generic variants to libclc will
hopefully no longer be needed. At that point, we don't want the NIR
code adding duplicates. Check if the generic version already exists
and, if it does, don't re-add it.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18675>
v2: Drop old code (Karol)
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18675>
Fix defect reported by Coverity Scan.
Double unlock (LOCK)
double_unlock: dri2_egl_error_unlock unlocks dri2_dpy->lock while it is unlocked.
Fixes: f1efe037df ("egl/dri2: Add display lock")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Rob Clark <robclark@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18655>
..Rather than at backend IR translation time. This is considerably
simpler because we can use the txs lowering instead of special casing
array sizes. Unfortunately it generates worse code, but that gap should
close once nir_opt_preamble is wired in.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18652>
Indirect dispatch does not actually require any dynamic memory allocation, even
with shared memory. We just need to set wls_instances to some (mostly arbitrary)
value, statically allocate memory based on that, and let the hardware throttle
workgroups to fit if needed.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18661>
Intel has different Z interpolation float point rounding
than other mesa gpus
For example gl_Position.z = 0.0 will be interpolated to
gl_FragCoord.z = 0.5 for all gpus
gl_FragCoord = -0.00000001 will be interpolated to
gl_FragCoord.z = 0.4999999702 for Intel
and rounded to gl_FragCoord.z = 0.5 for other gpus
Games with LEQUAL depth func will fail depth test on Intel
and will pass it on other gpus in such case
This workaround lowers translated depth range
and several gl_FragCoord.z coords with extra small difference
will be translated to the same UINT16\UINT24\UINT32
value of an integer depth buffer
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7199
Signed-off-by: Illia Polishchuk <illia.a.polishchuk@globallogic.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18412>
anv_pipeline_get_last_vue_prog_data (used by emit_3dstate_primitive_replication)
doesn't work for mesh stage.
Fixes: ae57628dd5 ("anv: Drop anv_pipeline::use_primitive_replication")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18495>
this will enable direct calling of the right function without the overhead
of having conditionals in the barrier functions themselves
eventually, the '2' variants will be widely enough deployed that
this can be deleted
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18628>
in some apps (hl2), there's a weird sequence like:
* bind attachment with srgb view
* clear
* bind attachment with base format
* draw
rewriting the clear color like this avoids unnecessarily triggering
a renderpass
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18627>
void clears are intended to be the first clear applied to a surface,
so ensure that these don't clobber any scissored clears
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18627>
If memory allocation fails, we look for a suitable sized BO in the BO cache and
wait until we can use its memory. That usually works, but there's a case when it
can fail despite sufficient memory in the system: BOs in the BO cache
contributing to memory pressure but none of them being of sufficient size. This
case is not just theoretical: it's seen in the OpenCL
test_non_uniform_work_group, which puts the system under considerable memory
pressure with an unusual allocation pattern.
To handle this case, try evicting *everything* from the BO cache and stalling
in order to allocate, if the above attempts failed. Fixes the following error:
DRM_IOCTL_PANFROST_CREATE_BO failed: No space left on device
on the aforementioned OpenCL test.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18579>
Example from dEQP-GLES2.functional.shaders.indexing.tmp_array.float_dynamic_write_dynamic_loop_read_fragment
Fragment Program: after 'pair translate'
0: src0.xyz = input[0], src1.xyz = const[5]
MAD temp[0].xyz, src0.xxx, src1.Hyz, src0.000
1: src0.xyz = const[1], src1.xyz = const[6]
MAD temp[1].xyz, src0.xxx, src0.111, -src1.x1z
2: src0.xyz = temp[1]
CMP temp[1].xyz, src0.000, src0.111, src0.xyz
3: src0.xyz = temp[0], src1.xyz = input[0], src2.xyz = temp[1]
CMP temp[2].x, src0.x__, src1.x__, -src2.y__
4: src0.xyz = input[0], src1.xyz = temp[0], src2.xyz = temp[1]
CMP temp[3].x, src0.x__, src1.x__, -src2.z__
5: src0.xyz = temp[1]
MAX temp[4].x, src0.x__, src0.z__
6: src0.xyz = temp[0], src1.xyz = input[0], src2.xyz = temp[4]
CMP temp[4].x, src0.x__, src1.x__, -src2.x__
7: src0.xyz = temp[3], src1.xyz = input[0], src2.xyz = temp[1]
CMP temp[3].x, src0.x__, src1.x__, -src2.x__
8: src0.xyz = input[0], src1.xyz = temp[2], src2.xyz = temp[1]
CMP temp[2].x, src0.x__, src1.x__, -src2.x__
9: src0.xyz = temp[1]
MAD temp[1].x, src0.x__, src0.y__, src0.000
10: src0.xyz = input[0], src1.xyz = temp[0], src2.xyz = temp[1]
CMP temp[1].x, src0.x__, src1.x__, -src2.x__
11: src0.xyz = const[2], src1.xyz = const[6]
MAD temp[5].xyz, src0.xxx, src0.111, -src1.x1z
12: src0.xyz = temp[5]
CMP temp[5].xyz, src0.000, src0.111, src0.xyz
13: src0.xyz = temp[0], src1.xyz = temp[2], src2.xyz = temp[5]
CMP temp[6].x, src0.y__, src1.x__, -src2.y__
14: src0.xyz = temp[3], src1.xyz = temp[0], src2.xyz = temp[5]
CMP temp[7].x, src0.x__, src1.y__, -src2.z__
15: src0.xyz = temp[5]
MAX temp[8].x, src0.x__, src0.z__
16: src0.xyz = temp[0], src1.xyz = temp[4], src2.xyz = temp[8]
CMP temp[4].x, src0.y__, src1.x__, -src2.x__
17: src0.xyz = temp[7], src1.xyz = temp[3], src2.xyz = temp[5]
CMP temp[3].x, src0.x__, src1.x__, -src2.x__
18: src0.xyz = temp[2], src1.xyz = temp[6], src2.xyz = temp[5]
CMP temp[2].x, src0.x__, src1.x__, -src2.x__
....
This will be pair scheduled to:
Fragment Program: after 'pair scheduling'
0: src0.xyz = input[0], src1.xyz = const[5] // original inst 0
MAD temp[0].xyz, src0.xxx, src1.Hyz, src0.000
1: src0.xyz = const[1], src1.xyz = const[6] // original inst 1
MAD temp[1].xyz, src0.xxx, src0.111, -src1.x1z
2: src0.xyz = const[2], src1.xyz = const[6] // original inst 11
MAD temp[5].xyz, src0.xxx, src0.111, -src1.x1
3: src0.xyz = temp[1] // original inst 2
CMP temp[1].xyz, src0.000, src0.111, src0.xyz
4: src0.xyz = temp[1], src1.xyz = temp[0], src2.xyz = input[0]
MAX temp[4].x, src0.x__, src0.z__ // original inst 5
CMP temp[2].w, src1.x, src2.x, -src0.y // original inst 3
5: src0.xyz = input[0], src1.xyz = temp[0], src2.xyz = temp[1]
CMP temp[3].w, src0.x, src1.x, -src2.z // original inst 4
6: src0.xyz = temp[5], src0.w = temp[2], src1.xyz = input[0], src2.xyz = temp[1]
CMP temp[5].xyz, src0.000, src0.111, src0.xyz // original inst 12
CMP temp[5].w, src1.x, src0.w, -src2.x // original inst 8
7: src0.xyz = temp[0], src0.w = temp[5], src1.xyz = temp[2], src2.xyz = temp[5]
CMP temp[6].x, src0.y__, src0.w__, -src2.y__ // original inst 13
8: src0.xyz = temp[5], src0.w = temp[3], src1.xyz = input[0], src2.xyz = temp[1]
MAX temp[8].x, src0.x__, src0.z__ // original inst 15
CMP temp[5].w, src0.w, src1.x, -src2.x // original inst 7
9: src0.xyz = temp[3], src0.w = temp[5], src1.xyz = temp[0], src2.xyz = temp[5]
CMP temp[7].x, src0.w__, src1.y__, -src2.z__ // original inst 14
10: src0.xyz = temp[2], src0.w = temp[5], src1.xyz = temp[6], src2.xyz = temp[5]
CMP temp[2].x, src0.w__, src1.x__, -src2.x__ // original inst 18
11: src0.xyz = temp[7], src0.w = temp[5], src1.xyz = temp[3], src2.xyz = temp[5]
CMP temp[3].x, src0.x__, src0.w__, -src2.x__ // original inst 17
....
The problem is that instruction 11 (which was instruction 17 before the scheduling) now reads
a wrong source for src0. It initially used the result of instruction 8 (now scheduled as 6),
but now it reads from instruction 8 (corresponding to instruction 7 before the scheduling).
The bug is quite subtle and needs few conditions to reproduce:
- there is a loop, therefore we skip the the register rename
pass and hence don't have the ssa-like form,
- there are at least two rgb instructions writing the same register
and both are convertible to alpha instruction,
- there is excess of rgb instructions, so that the conversion actually
happens.
So what happens, while scheduling instructions, the scheduler will
recognize there are no alpha instruction to pair the rgb ones with
and convert some to alpha. It primarily tries to use the same register,
just reuse the alpha channel.
Why it happens? We are tracking the usage of registers in the block
being scheduled and when we rewrite something we move the users tracked
by the reg_value structures to the new register. The problem is that when
we do this, the current code expects that the code is in the ssa-like
form. Here it is not (because of the loop) and when we convert the
original instruction 2, we move the dependency information about the
temp[2].x to temp[2].w. When we later convert instruction 8, which also
writes temp[2].x, the original dependency info is gone, and when we copy
that to the new reg (temp[5].w), we just set it to NULL and it means we
don't mark it as used effectively, and later wrongly use it again when
we look for a next empty register.
Fix this by not deleting the original dependency info. We can't reuse the
reg now, but it doesn't matter, because the regalloc later can sort it out.
There are no changes in the shader-db.
Fixes: dEQP-GLES2.functional.shaders.indexing.tmp_array.float_dynamic_write_dynamic_loop_read_fragment
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6508
Reviewed-by: Filip Gawin <filip@gawin.net>
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18621>
Fix defects reported by Coverity Scan.
Resource leak (RESOURCE_LEAK)
leaked_storage: Variable used going out of scope leaks the storage it points to.
leaked_storage: Variable multiple_uses going out of scope leaks the storage it points to.
Fixes: 8fb415fee2 ("pan/bi: Reduce some moves when going out-of-SSA")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18653>
