If the shader has multiple payload variables, split passes might not
preserve the order and this can cause the offsets used for the stores to
not match the payload offsets for nir_intrinsic_trace_ray.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31204>
There's never any need for anything higher. If this were too high (such
as NIR_ALIGN_MUL_MAX), it would have caused issues.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31204>
In the RT shader, if there's a executeCallableEXT() in between,
even though the called shader does nothing, the instructions before and
after the executeCallableEXT() is not properly synced.
Patch fixes:
- dEQP-VK.ray_tracing_pipeline.memguarantee.inside.rgen
- dEQP-VK.ray_tracing_pipeline.memguarantee.inside.chit
- dEQP-VK.ray_tracing_pipeline.memguarantee.inside.miss
- dEQP-VK.ray_tracing_pipeline.memguarantee.inside.call
Thank to Kevin for finding out there is a load/store issue.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31201>
In commit 44351d67f8, I needed to change some variables in a check for
compression in anv_can_fast_clear_color_view(). Instead of doing that, I
dropped the check altogether because I thought the call to
anv_layout_to_fast_clear_type() which followed right afterwards would
return ANV_FAST_CLEAR_NONE if the aux usage was ISL_AUX_USAGE_NONE.
That turned out not to be the case, due to special-casing of Xe2+. For
now, make Xe2+ more like other platforms when it comes to enabling
fast-clears. If there comes a reason to actually fast-clear with
ISL_AUX_USAGE_NONE, we can revisit this.
Fixes: 44351d67f8 ("anv: Change params of anv_can_fast_clear_color_view")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11920
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31297>
Instead of unconditionally emitting a warning to applications about
the missing environment variable to enable the driver, only check it
after determining that the device actually matches.
Signed-off-by: Benjamin Otte <otte@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31293>
Kernel does VCN instance scheduling per context, so when we have
multiple instances we should use new context to be able to utilize
all of them.
Another issue is with AV1, VCN 3 and VCN 4 only support AV1 on
first instance. Kernel parses IBs and switches to first instance when
it detects AV1, but this only works for first submitted IB in context.
The CS would be rejected if we first decode/encode other codecs, kernel
schedules on second instance (default) and then we try to decode/encode AV1.
Cc: mesa-stable
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31249>
Instead of re-emitting some dynamic states when a new shader is bound,
only re-emit the user SGPR states. This is slightly more optimal.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31160>
This doesn't change anything in practice because if we have a task
shader, we also have a mesh shader and the state was already re-emitted.
Though, this will prevent a regression from the upcoming patches because
the user SGPR layout will change.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31160>
In an earlier commit, I made us stop counting sync.nops in the shader
statistics we use for shader-db (brw_debug_log_message) and fossil-db
(stats->instructions = ...). However, I missed adjusting the printout
for INTEL_DEBUG.
Fixes: 1497f4e0c2 ("intel/fs: Don't include sync.nop in instruction count statistics")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31311>
... now that gralloc buffer metadata is more widely available
and actually populated.
Test: cvd start --gpu_mode=gfxstream_guest_angle_host_swiftshader
Test: cts -m CtsGraphicsTestCases
Test: cts -m CtsMediaCodecTestCases
Test: cts -m CtsMediaDecoderTestCases
Test: cts -m CtsViewTestCasesTest
Test: Open Youtube in Webview
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31330>
If A8_UNORM isn't specified in the format table, then it is emulated
in the state tracker by RGBA8. This is suboptimal, both because it requires
more memory, and because the blit gets more complicated (and in fact there's
a bug currently in the blit code where we don't mask properly for GL_ALPHA).
Fix this by adding an explicit A8_UNORM format entry.
Fixes piglit test ext_framebuffer_multisample-blit-mismatched-formats.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31322>
For cmd GL_PERFMON_RESULT_SIZE_AMD and GL_PERFMON_RESULT_AMD of
glGetPerfMonitorCounterDataAMD(), the current implementation will
return 0 if the result is not available on HW, but according to the
sepc, if cmd is PERFMON_RESULT_SIZE_AMD, <data> will contain actual
size of all counter results being sampled, instead of 0. And if cmd is
PERFMON_RESULT_AMD, <data> will contain results. The spec doesn't
require the application to wait for the result available on HW before
executing cmd PERFMON_RESULT_SIZE_AMD and PERFMON_RESULT_AMD. So for
cmd PERFMON_RESULT_SIZE_AMD, it should immediately return the correct
result size for the counters enabled by
glSelectPerfMonitorCountersAMD(), and for cmd PERFMON_RESULT_AMD, it
should wait until the result is available on HW and then return the
result.
Without this fix, the Sample Usage in the spec will not work properly
as it always gets size 0 when calling the cmd PERFMON_RESULT_SIZE_AMD
V2: If SelectPerfMonitorCountersAMD is called on a monitor, then the
result of querying for PERFMON_RESULT_SIZE will be 0.
Signed-off-by: Trigger Huang <Trigger.Huang@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31179>
Call gfx10_make_texture_descriptor from si_make_texture_descriptor and
use si_make_texture_descriptor everywhere.
This is more readable.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30904>
Instead of allocating it and then leaking it, store the log context
in si_screen.
Also, the log context was only set for "general" instead of all aux
contexts.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30904>
When no pipeline cache is provided by the application and we rely on the
internal one, cache hits are not counted as such.
This was causing us to return COMPILE_REQUIRED on some cases where all
shaders had been found in the cache, as well as some unnecessary extra
processing in the case that we did have to compile the pipeline.
Fixes: 1dacea10f3 ("anv: implement caching for ray tracing pipelines")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31298>
We have not yet added the shaders to the pipeline->shaders array at
this point. If we couldn't compile (or were asked not to) the
pipeline, we were leaking references to any shaders found in the cache.
This would manifest as an assert on device destruction:
vk_pipeline_cache_destroy: Assertion `cache->object_cache->entries == 0' failed.
Fixes: 58c9f817cb ("anv: fix pipeline executable properties with graphics libraries")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31298>
Use the AMD_IMAGE_OPCODES=0 environment variable to test the lower image
opcode code path used by AMD CDNA/compute devices without graphics.
Runs a very limited subset of GL tests.
Signed-off-by: Thong Thai <thong.thai@amd.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31180>
We don't have a generic v4i8 on Valhall, we have to lower it to two
v2i8. Fortunately, bi_make_vec_to() hides the Bifrost/Valhall
differences, so use that for nir_op_pack_uvec4_to_uint.
Fixes: 934b0f1add ("pan/bi: Respect swizzles for more vector ops")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31280>
We found out that some HW changes on Xe2 make the HW avoid reading the
blend state if we're using the null_rt bit in the extended descriptor.
Since the alpha_to_coverage bit resides in the blend state, that state
is ignored and writes are going through to the depth/stencil buffers.
Disable null_rt in the color outputs if the color outputs can affect
other outputs (through alpha_to_coverage & omask).
Fixes tests in this pattern on Xe2 :
dEQP-VK.pipeline.*.multisample.alpha_to_coverage_no_color_attachment.*
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Backport-to: 24.2
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31196>
We'll want to tune this setting based on other parameters.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Backport-to: 24.2
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31196>
We setup an empty render target when there are no color attachments,
which effectively makes it a different surface state. In most cases
the compiler will insert a null-rt bit in the extended descriptor
which means the RT isn't even accessed. But in some cases like
alpha-to-coverage output + depth/stencil write, we will access the
render target because using the null-rt will prevent alpha-to-coverage
from happening.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 2bd304bc8f ("anv: Skip the RT flush when doing depth-only rendering.")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31196>
Device memory can be allocated from different threads and thus requires
locking when allocating/freeing virtual addresses.
Fixes: 53fb1d99ca ("panvk: Transition to explicit VA assignment on v10+")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31282>
In wave64 for hw with native wave32, ds_append seems to be split in a load for
the low half and an atomic for the high half, and other LDS instructions can
be scheduled between the two.
Which means the result of the low half is unusable because it might be out of date.
I was only able to reproduce this issue in WGP mode, but be conservative and
apply the workaround in CU mode too.
Foz-DB Navi31:
Totals from 13 (0.02% of 79395) affected shaders:
Instrs: 7599 -> 7656 (+0.75%)
CodeSize: 39708 -> 39972 (+0.66%)
Latency: 83174 -> 83572 (+0.48%)
InvThroughput: 8271 -> 8357 (+1.04%)
Copies: 718 -> 717 (-0.14%)
VALU: 3689 -> 3703 (+0.38%)
SALU: 935 -> 965 (+3.21%)
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11921
Fixes: 45e935800a ("aco: implement nir_shared_append/consume_amd")
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31301>
