The standard block shapes (and by extension, the tiling formats they
require) are simply incompatible with getting a 2D view of a 3D image.
I couldn't find in the Vulkan spec anything related to what are the
expectations when trying to use both at the same time.
So here we "document" that this case is known non-standard. Please
notice that since we report residencyStandard3DBlockShape as true we
were actually supposed to support this case, but I can't see how this
would be possible, so set is_known_nonstandard_format to true so we
can avoid the assert() that comes right after.
Fixes the following when using Zink:
KHR-GL46.sparse_texture_tests.SparseTextureAllocation
Also "moves forward" the following test on Zink, so it now hits a
different assertion:
KHR-GL46.sparse_texture_tests.SparseTextureCommitment
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/26454>
During vkGetPhysicalDeviceSparseImageFormatProperties(), check first
if the non-sparse version of the image is supported, and return in
case it's not.
On TGL, if we don't do that, we may hit the following assertion:
deqp-vk: ../../src/intel/isl/isl.c:2584: isl_surf_init_s: Assertion `!(info->usage & ISL_SURF_USAGE_CPB_BIT) || dev->info->has_coarse_pixel_primitive_and_cb' failed.
My TGL doesn't has_coarse_pixel_primitive_and_cb.
Fixes the following on TGL:
dEQP-VK.api.maintenance5.flags.sparse_image_format_props
dEQP-VK.api.maintenance5.flags.sparse_image_format_props2
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/26454>
If the size here is not a multiple of the granularity (64kb) then
we'll miss our "pages" estimation by 1. We could fix this with
DIV_ROUND_UP() or by simply putting a "+1" there, but the upper layers
should now be preventing this case so let's just put the assertion
here.
Previously it was possible to hit this case with Zink by running
under certain conditions piglit/arb_sparse_buffer-basic.
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/26454>
From the spec:
"Resources can be bound at some defined (sparse block) granularity."
"The sparse block size in bytes for sparse buffers and
fully-resident images is reported as
VkMemoryRequirements::alignment. alignment represents both the
memory alignment requirement and the binding granularity (in bytes)
for sparse resources."
Not only the upper layer (the Spec) doesn't allow this, the lower
layers (both the vm_bind ioctl and TR-TT) also work on a granularity.
Just check for this case and return an error.
Before this check, what would happen was:
- for the vm_bind backend, the vm_bind ioctl would fail
- for the TR-TT backend, we'd understimate l1_binds_capacity and
fail an assertion, or we'd just silently bind 64kb instead of the
original size
Currently, some Zink tests such as piglit/arb_sparse_buffer-basic can
trigger this behavior, but we're working to fix Zink for this case
(and that commit may be merged before this one).
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/26454>
Adds a venus dri option to advertise support for multi-plane format
modifiers to Vulkan's common WSI. Otherwise, Venus will only support
modifiers with planeCount == 1 to ensure compatibility with Xwayland's
virgl-backed Glamor backend.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26240>
Force the use of single-plane modifiers for tiled wsi images as long as
Venus is integrated with Virgl, which does not support non-format
compression metadata planes (e.g. Intel's CCS or AMD's DCC modifiers).
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26240>
For compositors that advertise modifier support, Vulkan common WSI
modifier support queries still fail in Venus on the Intel ANV driver.
This is due to the presence of VK_CREATE_IMAGE_ALIAS_BIT, without
accompanying wsi_image_create_info struct, which is implicitly excluded
from serialized messages over the venus-protocol.
By removing ALIAS_BIT, modifier queries begin to pass when the host
supports them.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26240>
Without such, Xwayland gets back the implicit modifier token (INVALID)
when calling gbm_bo_get_modifier() for a dmabuf shared by the WSI layer.
Then mistakenly sends INVALID upon wl_buffer creation, rather than the
explicit modifier sent by WSI.
The logic of Xwayland's Glamor gbm backend is a bit circuitous, since
the modifier is sent by WSI alongside the dmabuf fd. Rather than use
that modifier directly when creating wl_buffer (via
zwp_linux_dmabuf_v1), Glamor first imports the dmabuf+modifier with
gbm_bo_import(), then uses the result of later gbm_bo_get_modifier().
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26240>
Instead of blatantly assuming with no assert that they're the same, add
a remap function. Also, be more careful about which enum we use where.
In the AST, we use GLenum and GL_FOO because we also need GL_ISOLINES.
When we translate to shader info, GS gets translated into mesa_prim
and tessellation gets translated into tess_primitive_mode which has
ISOLINES as a valid primitive value.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24821>
RADV compacts all descriptors for multi-planar images into one
combined image sampler, so it should be 96, and not eg. 192 for a two
planes format.
Fixes new CTS
dEQP-VK.binding_model.descriptor_buffer.ycbcr_sampler.*array.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26498>
Save a comparison, and move out the comparison to be more backend friendly.
Saves 2 instrs on AGX (as the remaining comparison now fuses with bcsel).
Results on AGX, all affected shaders in asphalt9.
total instructions in shared programs: 1813003 -> 1812611 (-0.02%)
instructions in affected programs: 119646 -> 119254 (-0.33%)
helped: 333
HURT: 0
Instructions are helped.
total bytes in shared programs: 11870344 -> 11867208 (-0.03%)
bytes in affected programs: 820888 -> 817752 (-0.38%)
helped: 333
HURT: 0
Bytes are helped.
and on Mali-G57:
total instructions in shared programs: 2677538 -> 2677205 (-0.01%)
instructions in affected programs: 206923 -> 206590 (-0.16%)
helped: 333
HURT: 0
Instructions are helped.
total cvt in shared programs: 14667.50 -> 14662.30 (-0.04%)
cvt in affected programs: 1953.64 -> 1948.44 (-0.27%)
helped: 333
HURT: 0
Cvt are helped.
total quadwords in shared programs: 1450664 -> 1450544 (<.01%)
quadwords in affected programs: 5064 -> 4944 (-2.37%)
helped: 15
HURT: 0
Quadwords are helped.
total threads in shared programs: 53282 -> 53309 (0.05%)
threads in affected programs: 27 -> 54 (100.00%)
helped: 27
HURT: 0
Threads are helped.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26489>
Otherwise, we can transition to exact before p_jump_to_epilog, then
transition to WQM again and then back to exact:
p_jump_to_epilog //transitions to exact
p_logical_end //transitions to wqm
p_end_wqm //transitions to exact
We rely on ssa elimination to clean most of this up.
fossil-db (navi21):
Totals from 1 (0.00% of 79330) affected shaders:
Instrs: 111 -> 110 (-0.90%)
CodeSize: 572 -> 568 (-0.70%)
Copies: 16 -> 15 (-6.25%)
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25440>
This creates a function that can be used by both pipelines and shaders.
Note that we cannot yet call tu_CreateShadersEXT directly inside the
pipeline due to things like pipeline feedback, multiview, and so on, but
further extensions will hopefully bring us closer to that ideal.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25679>
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>
OpBreak and OpBSsy aren't very SSA friendly as they require bar_in and
bar_out to be assigned the same register. We need to encure that RA
knows about this restriction. For now, we just special-case these two
instructions. In the future we may want a more generic mechanism for
this but it's not worth it for just two instructions.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26463>
The NIR intrinsics now take and return a barrier whenever one is
modified instead of modifying in-place. In NAK, we give the internal
instructions the same treatment and convert everything to use barrier
SSA values and RegRefs. In nak_from_nir, we move all barriers to/from
GPRs. We'll clean up the massive pile of OpBMov later.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26463>
OpBar and OpBSync both stall the thread until other threads get to that
point. These instructions must have .yld set. Also, warp barrier ops
don't support the usual instruction barrier mechanism so they should be
marked as having a fixed latency. It's unclear if the barrier file is
internally scoreboarded or if warp barrier ops just stall the whole
thread. In either case, this seems necessary.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26463>
