To simplify the pre-RA merge set code and express the result live-range
splitting in RA, we need to add support for parallel copy instructions,
and for the merge set code these parallel copies need to be in SSA form.
Parallel copies have multiple destinations by necessity, but there was
no way to express this in the existing IR. In particular there was no
support for marking a register as being a destination, and no support
for indicating which destination register out of several an SSA source
refers to. This replaces ir3_register::instr with ir3_register::def and
re-purposes ir3_register::instr. I haven't propagated this into common
helpers, like ssa(), because that would vastly increase the amount of
churn and the number of places that produce such instructions should be
limited -- only RA will create parallel copies and they will be
destroyed right after RA. In the future swz will have multiple
destinations too, but it will only be created after RA via parallel copy
lowering.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9842>
Haven't seen these tests flake, and we don't even run dEQP-GLES2 on G52
in CI anymore. (I still do local runs, and I don't see them flake
there.)
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11123>
We have CI, we're just a few tests away from conformance on v7, and
Midgard is just a few hundred tests behind. Given the branch point isn't
for another month, I think this is a good time to flip the switch.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11123>
Suboptimal but fixes KHR-GLES31.core.compute_shader.pipeline-post-xfb,
which is stubbornly still broken with memory barriers implemented and
cache flush jobs inserted. More investigation needed but probably not
right now.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11123>
This is inefficient but so far I see the DDK doing the same thing. Fixes
KHR-GLES31.core.shader_storage_buffer_object.advanced-usage-sync-vsfs
In the future we should look into cache flush jobs.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11123>
Transform feedback, SSBO writes, and image writes in particular can
affect this and have bad interactions. Fixes
KHR-GLES31.core.shader_atomic_counters.basic-usage-vs
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11123>
Instead just group the fields about validity into a simpler structure in
panfrost_resource. Panvk can do the same. Common code shouldn't be
thinking in terms of this 'larger' structure anyway.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11123>
Job type is alone with bitsize in the bottom byte of the addressed
worse, so if we use an 8-bit store we avoid the RMW complexity.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11123>
In actuality, this just shadows the crc_valid for pan_cs... the
data_valid checks are contained in the caller and just add noise.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11123>
CRC is intended for final render targets and especially for UI, not the
kind of things you'd mipmap. Meanwhile CRC only works for a single
level, meaning at any given point, half the CRC buffer would be wasted
for a full miptree.
"Arm Mali Best Practices Guide" tells developers that the DDK only
enables CRC for non-mipmapped resources (at least the Vulkan DDK), so
let's do the same, save some memory, and simplify our code.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11123>
Somehow XFB gets so little use we never noticed. Fixes:
KHR-GLES31.core.vertex_attrib_binding.basic-input-case9
KHR-GLES31.core.vertex_attrib_binding.basic-input-case11
KHR-GLES31.core.vertex_attrib_binding.basic-inputI-case2
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11123>
It's pointless and confuses the hardware. Fixes (on Bifrost)
KHR-GLES31.core.draw_buffers_indexed.color_masks
Yes, this is a silly edge case. Yes, we still have to handle it
correctly.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11123>
Based on a misunderstanding of how the scissor test works, and in
particular breaks transform feedback and SSBO writes from vertex
shaders.
Replace it with a moral equivalent to rasterizer_discard so vertex
shaders still run.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11123>
If we have per-draw state (vertex ID stuff), there's an ordering
mismatch. Fixes
dEQP-GLES31.functional.draw_base_vertex.draw_elements_instanced_base_vertex.builtin_variable.vertex_id
on Midgard, and I'm not sure why it was passing on Bifrost before. Also
should fix (on both architectures) DRAWID issues.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11123>
Ensures a valid schedule/regalloc is possible when vectors are used in
funny ways, as occurs in dEQP-GLES31 resulting in a scheduler hang (or
with prior patches, an RA failure).
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11123>
Technically we can stick the offset in the vertex ID attribute record,
but this is a faster way to get the test passing and Midgard perf?
what's that?
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11123>