DG2 can only do sample_d and sample_d_c on 1D and 2D surfaces. The
maximum number of gradient components and coordinate components should
be 2. In spite of this limitation, the Bspec lists a mysterious R
component before the min_lod, so the maximum coordinate components is 3.
Fixes the following Vulkan CTS failures on DG2:
dEQP-VK.glsl.texture_functions.texturegradclamp.isampler1d_fragment
dEQP-VK.glsl.texture_functions.texturegradclamp.isampler2d_fragment
dEQP-VK.glsl.texture_functions.texturegradclamp.sampler1d_fixed_fragment
dEQP-VK.glsl.texture_functions.texturegradclamp.sampler1d_float_fragment
dEQP-VK.glsl.texture_functions.texturegradclamp.sampler2d_fixed_fragment
dEQP-VK.glsl.texture_functions.texturegradclamp.sampler2d_float_fragment
dEQP-VK.glsl.texture_functions.texturegradclamp.usampler1d_fragment
dEQP-VK.glsl.texture_functions.texturegradclamp.usampler2d_fragment
The Fixes: tag below is a bit misleading. This commit fixes some test
cases similar to ones fixed by the Fixes: commit. I just want to make
sure this commit gets applied everywhere that commit was also applied.
Fixes: 635ed58e52 ("intel/compiler: Lower txd for 3D samplers on XeHP.")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15781>
(cherry picked from commit c08302670b)
- When resolving d32s8 to s8 we stored stencil with a wrong format.
- For unaligned multi-sample store we used wrong gmem offset for stencil.
If unaligined store is forced this change fixes a hang in:
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
Fixes: b157a5d0d6
("tu: Implement non-aligned multisample GMEM STORE_OP_STORE")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15532>
(cherry picked from commit 72716993b2)
These features require the global bo list and the existing code only checked
if the extensions which were promoted to 1.2 are enabled.
Found by inspection.
Cc: mesa-stable
Signed-off-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15701>
(cherry picked from commit 80a7ed273a)
this was previously only forced if the program pointer changed,
but programs can be freed and reused, and these are definite cases
where the last set cannot be reused, so jam it in
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15591>
(cherry picked from commit d415c28e64)
maybe just being overly paranoid, but make sure that the timeline id
gets compared while the lock is held in every scenario
cc: mesa-stable
Reviewed-by: Omar Akkila <omar.akkila@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15453>
(cherry picked from commit 5461a1cbaa)
We don't need to go to the kernel to synchronize the BO we want to
decode with INTEL_DEBUG=bat, mostly because we'll decode what was
written by the driver in the batch.
This also works around an issue in the simulation environment.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 9ac81f1890 ("iris: decoder fixes")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15517>
(cherry picked from commit a55cc061fd)
Otherwise, if batch->scissor_culls_everything is set for a single draw,
every draw after it in the batch will be skipped because the new
scissor/viewport state will never be processed. Process scissor state
early in draw_vbo to fix this interaction.
We do need to be careful: setting something on the batch can only happen when
we've decided on a batch. If we have to select a fresh batch due to too many
draws, that must happen first. This is pretty clear in the code but worth noting
for the diff.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reported-by: Icecream95 <ixn@disroot.org>
Reviewed-by: Icecream95 <ixn@disroot.org>
Fixes: 79356b2e ("panfrost: Skip rasterizer discard draws without side effects")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5839
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6136
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15365>
(cherry picked from commit d2fb6879a2)
It seems the default D3D behavior and it's complicated to emulate this
in DXVK/vkd3d. Enable it by default to prevent rendering issues in
other games not listed here.
Cc: 22.0 mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15368>
(cherry picked from commit 174d086e8c)
Because we have to maintain two different packages of Mesa, one
specific to RADV and another one for RadeonSI and such, it's a bit
annoying to have to synchronize the drirc entries. Currently, only our
Mesa package installs 00-mesa-defaults.conf which means we have to
backport the drirc RADV changes.
This splits 00-mesa-defaults.conf in two to move the drirc RADV entries
to src/amd/vulkan/00-radv-defaults.conf. Meson will install the file
only if RADV is built.
There is still a caveat for common drirc workarounds like for WSI but
they are rare enough and we could still duplicate them if needed.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15152>
(cherry picked from commit 53ca85ac2a)
Stops gamescope from recompiling pipelines on every start.
Cc: mesa-stable
Signed-off-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15454>
anv_batch_bo has a length field that we use to flush cachelines. Not
having that field initialized properly leads us to access out of bound
memory.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15425>
the fastpath here can only be taken if there is exactly one stream active,
as this will otherwise break nonzero stream primitives generated queries
in truth, this num_vertex_streams thing should be a bitmask so that the case
of num_streams=1,stream_id!=0 could also be fastpathed, but the complexity
probably isn't worth it given the infrequency of use
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15506>
(cherry picked from commit 36373e8e1e)
If you hadn't already called wsi_GetPhysicalDeviceDisplayProperties2KHR or
wsi_GetDrmDisplayEXT before calling
GetPhysicalDeviceDisplayPlaneProperties2KHR, then the connectors list
wouldn't be populated and you'd get no plane properties. Fixes failure of
dEQP-VK.wsi.display.get_display_plane_capabilities when run on its own.
Fixes: #4575
Cc: mesa-stable
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15353>
(cherry picked from commit da834a12cf)
Thix fixes two bugs. First, we stop leaking in/out fences with
multisync. Because the in_syncs and out_syncs parameters to
set_multisync were arrays and not pointers to arrays, the caller's
in_syncs and out_syncs pointers never got set and remained NULL so
multisync_free() always sees to NULL pointers and does nothing, leaking
both arrays. Not sure how this isn't showing up in the dEQP leak check
tests.
Second, the struct drm_v3d_multi_sync was in the scope of the then
clause of the `if (device->pdevice->caps.multisync)` so it goes out of
scope before the ioctl. This is, effectively, a use-after-free and,
depending on stack allocation details, may result in the multisync
extension struct getting stompped before the ioctl.
Fixes: ff8586c345 ("v3dv: enable multiple semaphores on cl submission")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15512>
(cherry picked from commit 688d478045)
It seems that a660 has the same bug. Without the workaround there
are a lot of flakes with depth-stencil tests, e.g. in:
dEQP-VK.pipeline.extended_dynamic_state.*
dEQP-VK.renderpass.depth_stencil_write_conditions.*
dEQP-VK.pipeline.stencil.format.d24_unorm_s8_uint.states.*
Or guaranteed failures like of:
dEQP-VK.pipeline.render_to_image.core.2d.huge.width.r8g8b8a8_unorm_d32_sfloat_s8_uint
Enabling the workaround fixes all of them.
cc: mesa-stable
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15548>
(cherry picked from commit 10734fb748)
With the NIR-to-TGSI transition, we had fewer other immediates and would
end up dereffing past the end of the literals array.
Cc: mesa-stable
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14429>
(cherry picked from commit 955883cf0a)
The two types of instructions get added to the same CF list, but not the
same instr list within the CF list. So, if you SSBO fetched your
texcoord, the emission of the SSBO fetch would come *after* the texcoord
fetch.
Avoids regressions when NIR-to-TGSI starts optimizing more.
Cc: mesa-stable
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14429>
(cherry picked from commit ef151d24ab)
We have to add WFM to pending bits when we are flushing into CP
for indirect draw to know when they should apply WFM workaround.
Fixes CTS tests:
dEQP-VK.draw.renderpass.indirect_draw.*_data_from_compute.indirect_draw_count*
Fixes: abf0ae014a
("tu: Properly handle waiting on an earlier pipeline stage")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15577>
(cherry picked from commit 37939e9c54)
Entry points have to be provided even if the features are not supported.
Helps Doom Eternal.
Fixes: f1095260a4 ("radv: Experimentally enable RT extensions.")
Signed-off-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15573>
(cherry picked from commit 37c0f68500)
Since this entry point is provided by VK_KHR_acceleration_structure, radv has
to implement it even if it doesn't support the indirect build feature.
Helps Doom Eternal.
Fixes: 82de184c3a ("radv: Enable VK_KHR_acceleration_structure with RADV_PERFTEST=rt.")
Signed-off-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15573>
(cherry picked from commit b8c8e3d975)
This is not a valid optimization.
Fixes: fb29cef8dd ("nir: add many passes that lower and optimize 16-bit input/outputs and samplers")
Signed-off-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14895>
(cherry picked from commit 798e47be51)
With LLVM 15 the include of llvm/IR/Constants.h is required for
ConstantInt.
This commit fixes an FTBFS.
Cc: mesa-stable
Signed-off-by: Kai Wasserbäch <kai@dev.carbon-project.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15232>
(cherry picked from commit a5884df949)
this can't be determined from pipe_shader_state::stream_output,
as this only contains xfb info, which is not the same as the vertex
stream info, and may break primitives generated queries
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15506>
(cherry picked from commit 32f117f5f8)
This attempts to apply each commit, one-by-one, and then pushes it to
gitlab for CI results, then if the CI succeeds it considers the commit a
success, otherwise it reverts it and continues.
