According to VK_KHR_depth_stencil_resolve spec (see
VUID-VkSubpassDescriptionDepthStencilResolve-pDepthStencilResolveAttachment-03182):
"If the VkFormat of pDepthStencilResolveAttachment has a stencil
component, then the VkFormat of pDepthStencilAttachment must have a
stencil component with the same number of bits and numerical
type"
The issue with D32_SFLOAT_S8_UINT format is that it is implemented as
two planes, so we need to execute the separate_stencil path in
tu_emit_blit() to resolve its stencil component into S8_UINT image.
Fixes the following tests:
dEQP-VK.renderpass2.depth_stencil_resolve.image_2d_32_32.samples_2.d32_sfloat_s8_uint.compatibility_depth_zero_stencil_zero_testing_stencil
dEQP-VK.renderpass2.depth_stencil_resolve.image_2d_32_32.samples_2.d32_sfloat_s8_uint_separate_layouts.compatibility_depth_zero_stencil_zero_testing_stencil
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8527>
According to VK_KHR_depth_stencil_resolve spec (see
VUID-VkSubpassDescriptionDepthStencilResolve-pDepthStencilResolveAttachment-03182)
"If the VkFormat of pDepthStencilResolveAttachment has a stencil
component, then the VkFormat of pDepthStencilAttachment must have a
stencil component with the same number of bits and numerical type"
That means that we can resolve MSAA depth/stencil to a stencil only
image only if the stencil component matches with same number of bits
and type.
Although the driver only supports VK_RESOLVE_MODE_SAMPLE_ZERO_BIT
resolve mode, it was doing a sample average when resolving a MSAA
D24_UNORM_S8_UINT image to S8_UINT.
Fixes the following tests:
dEQP-VK.renderpass2.depth_stencil_resolve.image_2d_32_32.samples_2.d24_unorm_s8_uint.compatibility_depth_zero_stencil_zero_testing_s
tencil
dEQP-VK.renderpass2.depth_stencil_resolve.image_2d_32_32.samples_2.d24_unorm_s8_uint_separate_layouts.compatibility_depth_zero_stenc
il_zero_testing_stencil
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8527>
tu_GetBufferMemoryRequirements() ends up wrapping the UINT64_MAX size
to 0 when aligning.
Fixes:
dEQP-VK.api.buffer.basic.size_max_uint64
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4493>
According to Vulkan spec, "Table 46. Required Limits", as sparse
binding is unsupported, we need to return unsupported limit for
sparseAddressSpaceSize, which is zero.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4493>
Don't ignore logic op for integer formats.
Blend also doesn't need this path, because it isn't valid for blendEnable
to be true for integer formats.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8707>
Now that all the drivers are converted, it's set to 'vk' by everyone so
there's no point in having the parameter.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8676>
Now that all drivers are converted over, we can make a few changes.
First off, vk_device_init no longer takes two separate allocators
because we can assume that the parent instance is non-null and it can
pull the instance allocator from that. Second, dispatch tables and the
instance extension table are no longer optional. We leave the device
extension table optional for now because we don't do any verification at
vk_init_physical_device time and some drivers find it more convenient to
set the extensions later in their own physical_device_init for various
reasons.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8676>
Things are going to start getting more complicated so let's avoid the
single mega-file approach.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8676>
If tess consts aren't used they don't get included in constlen,
and we risk overrunning consts of the next stage.
Fixes:
dEQP-VK.tessellation.invariance.outer_edge_index_independence.quads_fractional_even_spacing_ccw
dEQP-VK.tessellation.invariance.outer_triangle_set.quads_fractional_odd_spacing
dEQP-VK.tessellation.invariance.primitive_set.isolines_fractional_odd_spacing_ccw
dEQP-VK.tessellation.invariance.primitive_set.quads_fractional_odd_spacing_cw
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4117
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8578>
Fixes GPU hangs in dEQP-VK.renderpass2.depth_stencil_resolve.* tests
on A630.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8381>
Fixes the following building error:
FAILED: out/target/product/x86_64/obj/SHARED_LIBRARIES/gallium_dri_intermediates/LINKED/gallium_dri.so
...
ld.lld: error: undefined symbol: isa_assemble
>>> referenced by ir3_shader.c:151 (external/mesa/src/freedreno/ir3/ir3_shader.c:151)
...
ld.lld: error: undefined symbol: isa_decode
>>> referenced by ir3_shader.c:668 (external/mesa/src/freedreno/ir3/ir3_shader.c:668)
Fixes: 5cae4779c ("freedreno/ir3: Switch over to new encoder/decoder")
Signed-off-by: Mauro Rossi <issor.oruam@gmail.com>
Acked-by: Rob Clark <robclark@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8538>
Necessary to build libir3decode and libir3encode for Android
Fixes: 6d94f575d ("freedreno/hw/isa: Add description of ir3 ISA")
Signed-off-by: Mauro Rossi <issor.oruam@gmail.com>
Acked-by: Rob Clark <robclark@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8538>
When cross compiling with clang, `1ul` would end up 32b instead of 64b,
resulting in 32b fields (like branch/jump offsets) being encoded as
zero. Which results in infinite loops.
Fixes: e7630ec278 ("freedreno/hw: Add isaspec mechanism for documenting/defining an ISA")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8528>
IR3_SHADER_DEBUG=vs,tcs,tes... now also prints shader's sha1.
When there is a file named %sha1%.asm in IR3_SHADER_OVERRIDE_PATH
directory - ir3 assembly from file would be parsed, assembled, and
will override the shader with corresponding sha1 hash.
Parsing failure is considered unrecoverable error.
Upon successful override shader's assembly is printed with:
"Native code (overridden) for unnamed ..."
This debug option allows easier testing of small changes in
assembly without modifying the compiler or using computerator.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8388>
SpvOpAtomicLoad and SpvOpAtomicStore are translated into
nir_intrinsic_image_deref_store/load instead of some separate
atomic intrinsics, however they don't have src or dest type
specified. Turnip doesn't support shaderImageFloat32Atomics
so type is just integer.
Fixes:
dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_local.image.guard_local.image.frag
dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.workgroup.payload_local.buffer.guard_local.image.comp
dEQP-VK.memory_model.write_after_read.core11.u32.coherent.fence_fence.atomicwrite.device.payload_local.buffer.guard_local.image.comp
dEQP-VK.memory_model.write_after_read.core11.u32.coherent.fence_fence.atomicwrite.workgroup.payload_local.image.guard_local.image.comp
dEQP-VK.memory_model.write_after_read.core11.u32.coherent.fence_fence.atomicwrite.workgroup.payload_nonlocal.workgroup.guard_local.image.comp
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8476>
Note that we can't actually remove the packed structs themselves yet,
because tu still uses them in some hand-coded blit shaders.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7997>
Also, uncomment the `stc` test vectors (since the new decoder decodes
these properly) and comment out an instruction which looks suspiciously
like -6.0 in hex.
This also switches the parser back to `atomic.b.op` from `atomic.op.b`
which was a short-term workaround to make it easier for the legacy
disassembler.
Also switch the binary encoding for ldib to clear b0, because the new
disassembler warns about unexpected dontcare bits (which cases the
disasm to not match).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7997>
Drops decoding an ~850KB collection of instructions from ~4min to ~1sec.
Granted for normal sized shaders, this probably doesn't matter.. but it
at reduces my cycle time for fixing things to match existing disasm
syntax using this massive collection of unique instructions.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7997>
Once we switch over to the xml based ir3 ISA definition, the opcodes
will be decoupled from instruction encoding. Which will let us better
handle cases where a single "opcode" (from instruction encoding stand-
point) means different things on different generations. And also cases
like the different variations of `b`ranch instructions, which share a
single hw "opcode" plus a separate "brtype" field. When we start using
these in ir3, we'd like to treat them as separate instructions and not
have to care about the details of how they are encoded.
For now, these are only used internally within the new xml generated
instruction encoding, but once the existing "packed struct" encoding/
decoding is replace, we'll update ir3 to start using the new opcode
enums directly (except for the `mov` variants).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7997>
We'll want to re-use this when cutting over to the new XML based
instruction encoding. So untangle it from instruction packing.
Also, move handling of the appended constant data out of the
assembler, since this isn't much related to instruction encoding.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7997>
