V3D can't sample linear images (other than 1D), however, some applications
will require this to work. Particularly, our swapchain images may need to be
linear (for display), so sampling from them won't work.
This change detects the case where we are binding a descriptor which attempts
to sample from a simple 2D linear texture, transparently creates a tiled
copy of the image and rewrites the descriptor to refer to the tiled image
instead. This will be slow but will allow some applications that require this
to work (i.e. some aspects of Android's user interface).
As of this patch, this only supports sampling linear images with a single
miplevel and layer from single-plane images in non-arrayed descriptors. We
could handle other cases too with a bit more work though.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9712
Tested-by: Roman Stratiienko <r.stratiienko@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25048>
Common vk.tiling can have 3 states:
VK_IMAGE_TILING_OPTIMAL = 0,
VK_IMAGE_TILING_LINEAR = 1,
VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT = 1000158000,
The latter is checked by [1]
In this case, actual tiling can be either linear or tiled;
therefore, logic in v3dv_meta_copy will not work correctly.
[1]: 39fca243bb/src/vulkan/runtime/vk_image.c (L158)
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25139>
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>
This started out as a place to set linkage-related registers, but it
gradually became a grab-bag of different things. In the future each
stage will have its own draw state, so we split out the parts that only
depend on a single stage into separate functions. Each piece of state we
can split out is another piece of state that won't have to be emitted
while fast-linking.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25076>
There are a few cross-stage states that we absolutely have to wait to
emit until we know more than one stage. Pull these into the program
config draw state, so that we can split up the program draw state into a
per-stage draw state. For VK_EXT_shader_object, these will have to
emitted at draw time.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25076>
Emit the registers solely based on whether FS reads PrimID, and assume
the HW will do the right thing and disable PrimID passthru when GS is
enabled. This untangles these registers so we can set them from the FS
draw state in the future.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25076>
It turns out that the hardware automatically selects whether PrimID
passthrough needs to happen based on whether GS is enabled, which means
that it's safe to always set these registers based whether PrimID is
read by the FS and the hardware will ignore them when GS is enabled. Use
the real names for these registers to make it less confusing when we
start to do that.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25076>
This removes more draw states that are commonly set together. We still
have a separate draw state for RB_DEPTH_CNTL, because it depends on
other things like the attachment state and depth clamp and it would be
more difficult for layers like zink to use a combined depth/stencil
state.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25076>
There's no need to separate them except that it was easier before, no
one will enable the second without also enabling the first. Now that
mesa will merge the states for us we can go ahead and merge them.
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>
While we don't need to emit all of the unused mesh/task states when mesh
is disabled, if we don't have them we fail some assertions in the
difference checks due to the corresponding state being empty.
This may happen when going from a mesh pipeline to a non-mesh one, or
one that uses task shaders to one that doesn't.
It may be possible to avoid having to do this, but I'd rather start from
a working state and optimize it later.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25109>
Any partially packed instructions should always be pre-packed by
genX_pipeline.c
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25109>
3DSTATE_VFG was moved into a section that only gets emitted for legacy
pipelines, not mesh pipelines.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 0ce772bd19 ("anv: split 3DSTATE_VFG emission")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25109>
For some specific texture sizes, notably some texture sizes with width
4096, block stride calculation could end up calculating stride 256 which
is an invalid value.
In those specific cases, this could cause rendering artifacts or
application/driver crashes.
Cc: mesa-stable
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25084>
In order to compile monolithic shaders with pipeline libraries, we need
to keep the NIR around for inlining recursive stages.
Reviewed-by: Friedrich Vock <friedrich.vock@gmx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21929>
the array dimensionality needs to match nir_add_inlinable_uniforms even if
only the first member is used
Fixes: 0c0fb216dd ("nir/inline_uniforms: Allow possibility of more than one UBO")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25063>
this has a lot of caveats:
* extension must be supported
* resource must have usage bit set
* resource must not have any pending batch usage
* resource must be in supported layout
if all of these conditionals pass, then HIC can be used for direct image subdata
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24775>
