With shader objects, we won't have the pipeline layout available. This
means that the current way we implement dynamic offset descriptors in
combination with fast-linking and independent descriptor sets, where we
use the pipeline layout when fast-linking that has pre-computed offsets
for each descriptor set, won't work. Instead we need to piece together
the sizes of the descriptors in each descriptor set from the shaders.
This is already effectively what we do when we stitch together the
pipeline layout when fast-linking, but we need to make it work with just
the shaders.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25679>
Allows for the descriptor set count to vary at runtime depending on
the specific GPU to allow for 7 usable descriptor sets on A7XX with
one reserved for dynamic offsets.
Passing VK-CTS: dEQP-VK.binding_model.*
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25534>
New push consts loading consist of:
- Push consts are set for the entire pipeline via HLSQ_SHARED_CONSTS_IMM
array which could fit up to 256b of push consts.
- For each shader stage that uses push consts READ_IMM_SHARED_CONSTS
should be set in HLSQ_*_CNTL, otherwise push consts may get overwritten
by new push consts that are set after the draw.
- Push consts are loaded into consts reg file in a shader preamble via
stsc at the very start of the preamble.
OPC_PUSH_CONSTS_LOAD_MACRO is used instead of directly translating NIR
intrinsic into stsc because: we don't want to teach legalize pass how
to set (ss) between stores and loads of consts reg file, don't want for
stsc to be reordered, etc.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25086>
For dynamic states that are precompiled from static state, just set the
corresponding dynamic draw state directly, and keep a record of which
ones are precompiled when we go to emit states at draw time so we don't
accidentally re-emit them.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25276>
These draw states are things that depend on pipeline-only state:
- The load state depends on knowing the pipeline layout, which we won't
know for a shader that's loaded from a binary. This is going away on
a7xx anyway, and we should be able to use the a7xx strategy of
prefetching the descriptors in the preamble on a6xx too.
- The prim order state depends on feedback loops and raster order
attachment access, which isn't supported at the moment.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25276>
Now that the FS-specific parts are split out, the only remaining part is
the blend state part. Use the same state that we use for dynamic
blending for static blending, eliminating the last use of the pipeline
in the LRZ code. While we're at it fix a bug where dynamic blending
didn't always disable LRZ writes (even though it only mattered with a
non-conformant debug flag because we invalidated LRZ anyway).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25276>
There are a couple pieces of state that we can't calculate until we know
all of the shaders:
- The actual variants to use (i.e. whether to use safe-const variants)
- Program config and VPC draw states
- Const layout, which depends on the variants
- Whether per-view viewports should be enabled
Now that these are all combined in tu_pipeline::program, move these into
a separate struct that can be referenced directly without a pipeline.
The next step is to refactor the code filling it out so that it can be
called at draw time when given just the shaders.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25276>
The way this works now is awkward to map to shader objects. We don't
have the pipeline layout when "linking" shaders at draw time, so we have
to piece it together from the shaders. Store the information we need in
the shaders and piece it together.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25276>
Before this, we combined the modes after compiling the shaders when
constructing the pipeline. But that's a bit awkward with shader objects,
where there is no good place to put state derived from TCS and TES but
not the other stages. However, shader objects leaves us with an out:
when compiling separately, the modes must be on one of the shaders. So
instead we just copy the modes earlier, in the NIR shaders, and then get
them from the appropriate shader later. That way there is no extra
overhead when fast-linking, as there currently is, and we don't need to
create an awkward separate object just for this.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25276>
We will gradually transition over users of cmd->state.pipeline and
TU_CMD_DIRTY_PIPELINE to shaders and derived state from shaders. This
just puts in place the framework to start doing that.
When importing a library with all of the shader state, we now have to
import the shaders in addition to the program, so that they are
available when we bind the pipeline.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25276>
This completely rewrites how uploading variants and emitting the program
state works, which will make fast linking significantly faster and lays
some of the groundwork for EXT_shader_objects. Variants are now
compiled and uploaded as part of creating a tu_shader, and a
a per-stage draw state is also created that contains all registers that
are only set based on one stage. The program state is split into
per-stage states, which come from the shaders, and VPC state which is
emitted at linking time. Pipelines now contain shaders, and importing
shaders from libraries when fast-linking just involves taking a
reference on the shader. While the command buffer code still uses the
old pipeline structures, the plan is to switch more and more things to
directly use the shaders or derived state from the shaders that gets set
by the pipeline, so that we can eliminate pipeline usage from
tu_cmd_buffer.cc to enable ESO.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25076>
We only need to emit MSAA state once per subpass at most, unless the
pipeline switches primitive types or for framebuffer-less subpasses
(which always use sysmem anyway). Therefore it seems like draw state
skipping isn't going to bring much benefit here, and having it as a draw
state in the first place is a remnant of how this used to be part of the
pipeline state.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25076>
On a7xx DI_SRC_SEL_AUTO_INDEX is used instead of DI_SRC_SEL_AUTO_XFB.
On a7xx the counter value and offset are shifted right by 2, so
the vertexStride should also be in units of dwords.
CTS doesn't test this though.
Fixes:
dEQP-VK.transform_feedback.simple.draw_indirect_*
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23217>
The set of magic regs is different between generations and even
sub-gens. Adding a new one and/or emitting one on specific generation
takes much more code than necessary. Doing this in a single place is
much nicer.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23217>
A future spec clarification will state that pipelines will not have to
fill out the blend attachment count if every blend state is dynamic.
Instead, this comes from the subpass/rendering/inheritance info. To fix
this while still being able to use the same code to emit dynamic and
precompiled state, we have to set the attachment count in the blend
struct at the beginning of the subpass.
This will also help with ESO where it already worked like this.
Closes: #9709
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24957>
This is a partial fix for the case where
VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT and the aliased attachment clears
the attachment that was last used in a previous subpass (we have to move
the stores to the last used subpass, as well).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20994>
This will help us share gmem space between attachments that aren't used at
the same time. It's also a correctness fix for
VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT, because they're supposed to
happen at the first subpass using the attachment, not the start of the
renderpass.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20994>
For delaying clears to subpass begin time, I needed to save these until
later. Turns out this cleans up a good bit of threading these values all
through the command buffer setup.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20994>
Based on the previous commit, this isn't actually a bug and is expected
behavior. Turnip should already be handling it correctly for user
flushes, we just have to make sure to handle it for flushes we insert
ourselves in turnip and freedreno.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24162>
When I wrote this code, I was under the impression that at most one
context from each cluster could be executing at a time. This would mean
that we could treat clusters as pipeline stages and only insert a WFI if
there was a bubble where an earlier stage depends on the result of a
later stage.
This mental model was wrong, though. Experiments on a6xx show it's
possible for two contexts to be executing simultaneously, even though
there are only two contexts - register writing is just stalled until the
earliest-launched context finishes.
This means that the mental model is now much simpler. Any draw can, in
theory, execute in parallel with any previous draw, blit, flush, etc,
although it seems that flushes do wait for any earlier work to finish.
Clusters are mostly just an implementation detail that only matter in
some corner cases, like setting a non-context register (written in the
last cluster) that is used by an earlier cluster that can race ahead of
the write.
An example where this makes a difference is a fragment shader that
writes an image via stib followed by a blit from that same image.
Because both operations happen in the same cluster and use the same
cache, we wouldn't emit anything in the barrier, however actually we
still need to WFI.
This was getting worse on a7xx because later clusters now have 4
contexts, making it easier for draws to be executed in parallel. However
AFAICT it was already a problem on a6xx.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24162>
a610/a608 has less pipes, so we need to make it configurable.
In particular we need to program all of the VSC_PIPE_CONFIG_REG[n]
rather than leaving garbage values for the unused pipes. Pointing
multiple VSC pipes at the same bin makes the hw angry.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20991>
There is no .gmem field, there is a ccu color cache size field
which tells the size as a fraction of depth cache used in direct
rendering.
There is also GMEM_FAST_CLEAR_DISABLE flag which is set on a608/a610.
Since these values will stop being the same between models,
make them configurable.
Credits to Connor Abbott for deciphering color cache size meaning.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20991>
We don't use draw states for dispatches, so the bound pipeline
could be overwritten by reg stomping in a renderpass or blit.
The solution is to re-emit pipeline's IB on every dispatch if
reg stomping is used.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23881>
The common state code expects you to use a different struct for state in
graphics pipelines and in pipeline libraries. This means we need to
copy the approach radv uses in order to be compatible. This also allows
us to shrink the structs a bit by moving compute-only things to the
compute pipeline and library-only things to the library pipeline.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22301>
Danylo Piliaiev