Our sparse implementation will require us to issue partial unbinds,
but partial unbinds are not supported in synchronous vm_bind ioctls,
requiring us to to have our VM be marked with the ASYNC flag. This is
not properly documented and is subject to change in the next
iterations of the API.
Error handling with async binds is also not documented anywhere and is
being actively discussed in the mailing lists, so whatever we decide
to implement here is likely to end up changing in a few weeks. Also, I
haven't seen these errors happening in the real world, so for now
they're a very corner case. So for now just foward errors to
user-space and hope things work.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24681>
For Sparse Resources we need to be able to specify the address, size
and offsets and we also want to be able to issue multiple binds at the
same time. Extend xe_vm_bind_op() to handle those cases and add
the new vfunc.
v2:
- use STACK_ARRAY() (Lionel)
- no more need to work around xe.ko bug that was fixed (José)
Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (v1)
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24681>
The only driver that has a vm_bind ioctl is xe.ko, and its vm_bind
ioctl is not called GEM vm_bind, it's just DRM_IOCTL_XE_VM_BIND
(without GEM anywhere). Back when i915.ko was going to have a vm_bind
ioctl it had GEM on its name, so I guess that's how "gem" appeared in
the naming here, but now nothing does, so let's get rid of it.
Also, these vfuncs we have are specifically made to bind and unbind
whole BOs, so rename them to vm_bind_bo() and vm_unbind_bo() in order
to try to clarify what they mean. The goal is to add a more generic
vm_bind() later that can do anything.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24681>
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>
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>
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>
