Since PIPE_CAP_TGSI_TEXCOORD is now set in SVGA vgpu10 driver,
we need to add a new parameter need_texcoord_semantic to
tgsi_add_point_sprite and tgsi_add_aa_point
to allow setting texcoords using tgsi texcoord semantic.
Reviewed-by: Neha Bhende <bhenden@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16598>
Now that our IR is much more strongly typed, and RA code quality depends on
correct typing, add a validation pass to make sure we didn't screw it up. This
pass found a massive number of bugs in early versions of this series.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16585>
We tightened the rules around preloading substantially and take advantage of the
rules in RA. The safe helpers it introduced should ensure the rules are
followed, but just in case, add a validation pass to check our work. This pass
found (multiple) bugs in early versions of this series.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16585>
In the current IR, any register may be preloaded by reading it anywhere, and any
register may be precoloured by writing it anywhere. This is convenient for
instruction selection, but requires the register allocator to do considerable
gymnastics to ensure it doesn't clobber precoloured registers. It also breaks
the purity of our SSA representation, which complicates optimization passes
(e.g. copyprop).
Let's trade some instruction selection complexity for simplifying register
allocation by constraining how register precolouring works. Under the new model:
* Registers may only be preloaded at the start of the program.
* Precoloured destinations are handled explicitly by RA.
Internally, a stronger invariant is placed for preloading: registers may only be
preloaded by MOV.i32 instructions at the beginning of the block, and these moves
must be unique. These invariants ensure RA can trivially coalesce the moves.
A bi_preload helper is added as a safe version of bi_register respecting these
invariants, allowing a smooth transition for instruction selection.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16585>
Move can take in a vector and write a scalar, depending on the swizzle. We need
to handle this case. Split out mov and pack_32_2x16 so we can specify correct
behaviour for both. Also drop unused 1-bit boolean stuff which obscured the fix.
Fixes: 76cea8e27b ("panfrost: Fix pack_32_2x16 implementation")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16585>
These move-like instructions will be generated during instruction selection and
lowered before/after register allocation.
These need special printer support until we get dynamic sources/destinations.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16585>
In preparation for dynamic allocation, as needed for phi nodes and parallel
copies. For now, it just serves to simplify the semantics of splits and
collects.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16585>
"Revisiting Out-of-SSA Translation for Correctness, Code Quality, and
Efficiency" discusses "value-based interference": two variables interfere if and
only if there exists a point in the program where they are both live *with
different values*. In particular, the source and destination of a move do not
interfere a priori, because they have the same value at that point in the
program. (If a later instruction overwrites one, the required interference will
be added there).
We can use this idea to avoid some extra interferences, avoiding a regression in
moves from split/collect.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16585>
If we don't lower phis to scalar, when we go out of SSA, we can get vector
nir_registers. In particular, we can get code like:
r0 = vec2 r0.y, r0.x
This code looks like a move, but is in fact a swap. The trivial lowering of vec2
would not work -- the following fails to swap correctly:
r0.x = r0.y
r0.y = r0.x
Currently, we generate temporaries to handle these cases. It's easy to move the
complexity to NIR, though, and we'll want to scalarize phis for SSA-based RA
anyway.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16585>
Minor ISA detail missed in the Bifrost scheduler. I hit this in an early version
of this series (where a move feeding into a blend shader return was not
coalesced). Let's get it fixed in the scheduler.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16585>
Texture instructions on Valhall take 64-bit sources. Now that we have
infrastructure to handle this properly, we don't need to use a non-SSA node to
hack around the optimization.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16585>
This ensures Valhall 64-bit constraints are respected in a simple way. It's not
the most efficient, though. Optimization is deferred until full Valhall support
is upstreamed and the RA is overhauled.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16585>
This source size information will be consumed by the 64-bit lowering pass, so
ensure it's accurate. That means marking 32-bit and 64-bit sources explicitly on
message passing where it wouldn't match up with the type size suffix of the
instruction.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16585>
We add some new instructions on Valhall with special register requirements
(texturing, atomics). Handle these appropriately so we can do RA on Valhall.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16585>
This can happen if an object is serialized whose object type isn't in
the pipeline cache import ops. In this case, we generate a raw data
object and plan to turn it into the right object type later.
Fixes: d35e78bb85 ("vulkan/pipeline_cache: Implement deserialize for raw objects")
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16584>
This should make it clear whether a validation failure happens in RADV or
zink.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12448>
Danylo Piliaiev
Charmaine Lee
Lionel Landwerlin
Dylan Baker
Alyssa Rosenzweig
Jason Ekstrand
Rhys Perry