Piglit arb_texture_buffer_object-render-no-bo was generating
gpu resets because the uniform stream was missing the last
Fragment Shader uniform. So it was reading instead of the last
fragment shader uniform the first uniform of the vertex shader.
And using that unrelated VS uniform as the sampler address where
the texture should be read.
So now if a buffer object is not bound for a texture buffer object
we write the texture state base address to 0 (NULL) so the default
texture state is used.
So only is needed to set the 4 lower bits of the tmu_p0 with
the bit-mask of word enables.
Fixes: bb8285c258 ("v3d: add support for no buffer object bound")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35847>
(cherry picked from commit 0f8c681c5c)
As per the old comment:
"These formats correspond to the similarly named MESA_FORMAT_*
tokens, except in the native endian of the CPU. For example, on
little endian __DRI_IMAGE_FORMAT_XRGB8888 corresponds to
MESA_FORMAT_XRGB8888, but MESA_FORMAT_XRGB8888_REV on big endian."
Fixes: 7e10601786 ("dri: Redeclare __DRI_IMAGE_FORMAT_* as PIPE_FORMAT_*")
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35814>
(cherry picked from commit 2ca46c7a7a)
nvidia hardware can't render to linear surfaces except under some
very limited circumstances, one of those is if Z is enabled.
However there appears to be some combination of gnome-shell, and
prime (with 2 nouveau cards) where we end up getting through the
GL API to the situation where we try this. This in a production
build causes the kernel to crash with a GR error.
However there existed a period of time where the hw/kernel due to
some other random hw misconfiguration didn't crash when this happened
and doing this was prefect fine. (linear + tiled Z).
This restores the userspace code to do this and just ignores the
Z buffers if we are asked for linear rendering, and seems sufficient
to fix the problem.
I do understand this is a workaround, but I think it's reasonable to
add to the nouveau GL driver at this time since we don't want to
maintain if for ever and it probably should fix a bunch of wierd
user problems with multi gpu and nouveau.
Cc: mesa-stable
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35221>
(cherry picked from commit 06e8db646a)
The new layout affects the whole buffer so it needs to be done
on a full clear.
This fixes this piglit test on a RX 6800 XT:
ext_framebuffer_multisample-accuracy 6 depth_resolve small depthstencil
Fixes: 75a03d733a ("radeonsi: simplify and fix enable_tc_compatible_htile_next_clear logic")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35582>
(cherry picked from commit 04d283c628)
Otherwise, outputs_read/outputs_written might not be up-to-date
(mostly after nir_remove_dead_variables) and remove_point_size() might
reach an assertion later because the output variable isn't found.
It seems better to run nir_shader_gather_info() at the very end of
radv_optimize_nir() which can change a lot of things anyways.
No fossils-db changes.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35707>
(cherry picked from commit 30ccd97cd2)
`cc: mesa-stable` instead of `fixes:` because several commits have
modified this but keeping this bug:
- 06e57e3231 ("virtio: Add vdrm native-context helper") made
an unconditional copy of subdir(virtio)
- cede4e7ac3 ("meson: Only include virtio when DRM available")
introduced a new condition, which doesn't cover everything that was
needed
- other commits made more changes
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35723>
(cherry picked from commit d0c7bea727)
When panfrost_resource_init_afbc_headers() fails, freeing the newly
created resource is not enough, because we need to unreference its BOs.
This will also take care of freeing its resource label.
Also replace instances of FREE() in error-handling paths with
panfrost_resource_destroy(), as it is capable of handling partially
initialised resources.
Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
Fixes: e3f2bc7963 ("panfrost: handle mmap failures")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34224>
(cherry picked from commit 32b128be01)
The snorm formats are not compatible with the srf flag
which was set by the emit_image_load_or_atomic() function.
In this specific case, "use_const_fields" is not set which
implies that the format definition is local. The other
supported formats do not require the srf flag as well.
This change was tested on cypress, barts and cayman. Here are the tests fixed:
khr-gl4[2-6]/shader_image_load_store/basic-allformats-load: fail pass
khr-gl4[2-6]/shader_image_load_store/basic-alltargets-loadstorecs: fail pass
khr-gl4[5-6]/es_31_compatibility/shader_image_load_store/basic-allformats-loadstorecomputestage: fail pass
khr-gl4[5-6]/es_31_compatibility/shader_image_load_store/basic-alltargets-loadstorecs: fail pass
khr-gles31/core/shader_image_load_store/basic-allformats-loadstorecomputestage: fail pass
khr-gles31/core/shader_image_load_store/basic-alltargets-loadstorecs: fail pass
deqp-gles31/functional/image_load_store/2d/format_reinterpret/r32f_rgba8_snorm: fail pass
deqp-gles31/functional/image_load_store/2d/format_reinterpret/rgba8_rgba8_snorm: fail pass
deqp-gles31/functional/image_load_store/2d_array/format_reinterpret/r32f_rgba8_snorm: fail pass
deqp-gles31/functional/image_load_store/2d_array/format_reinterpret/rgba8_rgba8_snorm: fail pass
deqp-gles31/functional/image_load_store/3d/format_reinterpret/r32f_rgba8_snorm: fail pass
deqp-gles31/functional/image_load_store/3d/format_reinterpret/rgba8_rgba8_snorm: fail pass
deqp-gles31/functional/image_load_store/buffer/format_reinterpret/r32f_rgba8_snorm: fail pass
deqp-gles31/functional/image_load_store/buffer/format_reinterpret/rgba8_rgba8_snorm: fail pass
deqp-gles31/functional/image_load_store/cube/format_reinterpret/r32f_rgba8_snorm: fail pass
deqp-gles31/functional/image_load_store/cube/format_reinterpret/rgba8_rgba8_snorm: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35548>
(cherry picked from commit d27ed38d1a)
The mode r10g10b10a2_snorm processed as vertex on palm at the
hardware level doesn't follow the current standard. Indeed, the .w
component (2-bits) is not calculated as expected. The table below
describes the situation.
This change fixes this issue by adding three gpu instructions at
the vertex fetch shader stage. An equivalent C representation and
a gpu asm dump of the generated sequence are available below.
.w(2-bits) expected palm
0 0.0 0.000000
1 1.0 0.333333
2 -1.0 0.666667
3 -1.0 1.000000
w_out = (4.*w_in > 1. ? 1. : 4.*w_in) - (w_in > 0.5 ? 2. : 0.);
0002 00000008 A0080000 ALU 3 @16
0016 00000C02 A0000CC0 1 y: MOV*4_sat __.y, R2.w
0018 801F8C02 600004A0 w: SETGT*2 __.w, R2.w, 0.5
0020 839FC4FE 60400010 2 w: ADD R2.w, PV.y, -PV.w
Note: The rv770 and cypress don't need this correction. This is
definitely a hardware change between these gpus.
This change was tested on palm, barts and cayman. Here are the tests fixed:
spec/arb_vertex_type_2_10_10_10_rev/arb_vertex_type_2_10_10_10_rev-array_types: fail pass
deqp-gles3/functional/draw/random/124: fail pass
deqp-gles3/functional/vertex_arrays/single_attribute/normalize/int2_10_10_10/components4_quads1: fail pass
deqp-gles3/functional/vertex_arrays/single_attribute/normalize/int2_10_10_10/components4_quads256: fail pass
khr-gl43/vertex_attrib_binding/basic-input-case5: fail pass
khr-gl44/vertex_attrib_binding/basic-input-case5: fail pass
khr-gl45/vertex_attrib_binding/basic-input-case5: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32427>
(cherry picked from commit e8fa3b4950)
`getopt_long()` returns an `int`, not a `char`; putting the value in
a `char` before comparing it to `-1` was making the comparison always
fail, resulting in the invalid codepath taken that then fails with:
option `-' is invalid: ignored
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34756>
(cherry picked from commit 99e8d804bf)
`subprocess.Popen()` returns immediately, and the subprocess might not
have finished by the time `stdout` is read on the next line, spuriously
failing the tests.
`subprocess.check_output()` makes sure the output is available before
returning, solving this issue; it additionally raises an error if the
subprocess failed, giving a better error than a failed diff later in the
script.
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34756>
(cherry picked from commit de6ab1beda)
Clients are expecting the color info to be fully filled when the api
exists. Give proper defaults for the metadata to stay aligned with
legacy backends.
Also amend the missing ChromaSiting cases.
Fixes: ee42e2166d ("android: Introduce the Android buffer info abstraction")
Reviewed-by: Roman Stratiienko <r.stratiienko@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35613>
(cherry picked from commit 64d18f84b0)
The MEMORY_BARRIER instruction has some issues, where we end up
dead-code eliminating it before it gets to do what it's supposed to do.
But even if we fix that, we have issues where we can end up inserting
flow control into it, which isn't going to work because we have nothing
to emit here either.
So let's rework this to a special-cased NOP instruction, which is marked
as a scheduling barrier. The beneft here is that NOPs are already properly
handled when it comes to flow control.
Note that this isn't perfect either; this only prevents memory operations
from crossing the scheduling barrier. We should really prevent any
operation with observable side effects from crossing the barrier. This
includes things like reading clocks etc.
But that's a larger change, and it's a step in the right direction to get
this to no longer be dead-code eliminated. So let's put this band-aid on
for now.
Fixes: f77a50e45e ("pan/bi: add a MEMORY_BARRIER pseudo-instruction")
Reviewed-by: Caterina Shablia <caterina.shablia@collabora.com>
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35502>
(cherry picked from commit 18893a250f)
It might be the case that both the branch and exec mask write in a
divergent branch block are removed. try_remove_simple_block() might then
try to remove it, but fail because it has multiple logical successors.
Instead, just skip these blocks.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Backport-to: 25.1
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35202>
(cherry picked from commit 5344abbc56)
u_blitter sets a viewport transform with depth range [-1,1], which is
outside the [0,1] range that is allowed by opengl.
The mali hardware docs state that setting the LOW_DEPTH_CLAMP register
outside of [0,1] is undefined behavior. We haven't observed any problems
with this so far, but better to fix it.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Fixes: 810135fb42 ("gallium/u_blitter: Fix depth.")
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35225>
(cherry picked from commit b8c7fcda27)
The SPIR-V spec is pretty clear that coordinates on subpass attachments
are relative to the current pixel. They're required to be zero but we
should stay consistent with ourselves (we already do this for image
intrinsics) and with the spec.
Fixes: 84b08971fb ("nir/lower_input_attachments: lower nir_texop_fragment_{mask}_fetch")
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35551>
(cherry picked from commit 2c13e1e655)
There's nothing in NIR which guarantees that the deref is the first
source or that the coordinate is the second. Use
nir_tex_instr_src_index() to get the actual indices.
Fixes: 84b08971fb ("nir/lower_input_attachments: lower nir_texop_fragment_{mask}_fetch")
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35551>
(cherry picked from commit 9a52b9372c)
Turnip when cross-compiled for i386 needs to be built with SSE2 as a
minimum spec, as it uses clflush unconditionally. Make sure to pass in
the sse2_args, which will be empty on Arm64 targets.
Fixes: 7231eef630
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35621>
(cherry picked from commit f872cbea37)
When running `ffmpeg -vaapi_device /dev/dri/renderD128 -f lavfi -i smptebars=duration=5:size=1280x720:rate=30 -vf format=rgba,hwupload,scale_vaapi=format=nv12,hwdownload testout.mp4`,
the vpe is asked to transform into NV12, which cannot be done with a blit. `si_vpe_construct_blt` fails, but then it gracefully falls back into `vlVaPostProcCompositor` and finishes the task correctly, but not before logging the error:
SIVPE ERROR ../mesa-25.1.3/src/gallium/drivers/radeonsi/si_vpe.c:1095 si_vpe_construct_blt Failed in checking process operation and build settings(9)
for each frame that is processed. Since this is expected, my original thought was to demote this to a warning. But looking at all the reasons it could fail for, there already is a warning (or error) logged, so it seems to me the best thing to do is remove the error entirely
There may be a better approach here, and I'm all ears.
Fixes: e85a6b6a63 ("radeonsi/vpe: check reduction ratio")
Reviewed-by: Peyton Lee <peytolee@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35449>
(cherry picked from commit e1bcd0f4a5)
This shouldn't matter if FDM is actually enabled, because in that case
the pipeline must enable the bit and we dirty FDM state at the
beginning, but pipelines can enable FDM even if the renderpass they're
used in doesn't use FDM and in that case we still need to use the FDM
path to duplicate the viewports. Fix the case where a different pipeline
is bound that enables FDM without actually using FDM.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35581>
(cherry picked from commit 60843bc806)
The max dimensions are in units of pixels, not bytes. But the x
coordinate shift is based on aligning the address/offset to 64.
Rework the buffer clear loop to iterate in terms of pixels, but
with the x dimension shift based on converting aligned offset
to pixels.
Fixes OpenCL-CTS test_buffers.
Fixes: dafc4476f7 ("freedreno: Implement fast clear_buffer for Adreno 6xx and 7xx")
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35557>
(cherry picked from commit 8d13fc447e)
DCC tilings info needs to be set for all surfaces, including
depth/stencil. But because this is a C union, settings those fields
for depth/stencil surfaces might accidentally overwrite HiZ info.
This fixes rendering issues with RADV_DEBUG=nohiz.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35515>
(cherry picked from commit 251b23f6c2)
The frontend does not know that etnaviv may keep multiple shadows around
for a resource, so it will always pass in the base resource as blit source
and destination. For those blits to work as expected by the API we need to
work out which shadow is the most recent one and use those as blit source
and destination resources.
CC: mesa-stable
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35526>
(cherry picked from commit ede41372f4)
etna_copy_resource() and etna_copy_resource_box() are used to keep the
internal shadow copies of a resource up to date. They are supposed to
always use the RS or BLT engines to do the copy, never requiring any
fallbacks or fake format handling. They should also work regardless of
the current render condition state. So instead of going through the
pipe_context blit hook, directly call the RS or BLT blit hook on the
etna_context.
CC: mesa-stable
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35526>
(cherry picked from commit d4780f03fc)
This reverts commit 57ea689273.
This optimization is only sound when the operands of iadd are unsigned.
It turns out this is not always the case.
While the particular failure I was seeing was fixed by changing the
unsigned shifts to signed ones, I don't believe this is sound either. So
it's better to disable it for now until we find a better solution.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: 57ea689273 ("ir3: optimize SSBO offset shifts for nir_opt_offsets")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34324>
(cherry picked from commit 29eb9ec7b7)
This prevents a regression from the next commit which would write
garbage for combined image+sampler descriptors and that might break
capture&replay.
It seems also more robust to write zeroes than garbage overall.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35455>
(cherry picked from commit 22e06d65d7)
The referenced commit was a step in the right direction, but not
complete.
ac_build_image_opcode returns a vec<4> or a struct<vec<4>, int>
so we can simplify visit_tex. We just need to map these 4/5 values
to the expected layout from NIR.
eg: depth + TFE would produces "<d, x, x, x>, t" so it has to be
transformed into <d, t>.
nir_texop_fragment_mask_fetch_amd + sparse doesn't exist, so it's
another opportunity for simplification.
This is required to get KHR-GL46.sparse_texture2_tests.SparseTexture2Lookup_texture_2d_depth_component16
working properly.
The same test fails with ACO so it probably needs a change in the
same area.
Fixes: c0ef2aa7f8 ("DEPENDENCY: ac/llvm: fix sparse code handling")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35206>
(cherry picked from commit 4a84ebfcb1)
If the clone_append was to a chunk of the same u_trace that gets
process_chunk()ed after where we're cloning from, then the payloads would
have been unreffed in the previous chunk's cleanup_chunk().
Fixes use-after-frees with turnip gmem rendering that resulted in
corrupted payloads.
Fixes: 14e45cb21e ("util/u_trace: refcount payloads")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35379>
(cherry picked from commit 6e97df1d76)
The previous fix 0cae8d372e is the right way to proceed, but it
should also apply when index_size is non-zero.
This change was tested on palm and cayman. Here is the test fixed:
spec/arb_multi_draw_indirect/arb_draw_elements_base_vertex-multidrawelements -indirect: fail pass
Fixes: 0cae8d372e ("r600: don't set an index_bias for indirect draw calls")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34726>
(cherry picked from commit a640b7233c)
The ISA docs don't mention this, but instead of always truncating
like other integer conversions, this opcode actually uses the single
precision rounding mode.
We could continue to use the opcode and set the rounding mode to rtz
in lower_to_hw_instrs, but I think I should just concede that f2u8
isn't worth the effort.
Fixes: 9bb10b58 ("aco: use v_cvt_pk_u8_f32 for f2u8")
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35391>
(cherry picked from commit d95e90ab5f)
We were allocating these, but never freeing the actual CSOs here.
Let's wire things up so we delete the data when we destroy the
hash-table. Because we don't have access to the context in that
callback, we can't call the pipe-level function to delete a CSO,
but luckily we don't actually need the context for the
driver-logic. So let's add an internal helper for that.
Fixes: ae3fb3089f ("panfrost: Add infrastructure for internal AFBC compute shaders")
Fixes: f39194cdd3 ("panfrost: support MTK 16L32S detiling")
Reviewed-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/35336>
(cherry picked from commit fb0a422be2)
At draw time, if the number of BOs is bigger than 2048, the current
job submission is forced.
The 2048 limit has been validated to be big enough to not be reached
in most of the scenarios. Only a couple of CTS tests get over this
threshold.
So the new V3D_JOB_MAX_BO_HANDLE_COUNT is defines as 2048 and
V3D_JOB_MAX_BO_REFERENCED_SIZE is defined as 768MB.
This forced submission is useful to handle scenarios where the client
application is not calling glFlush() or where SwapBuffers() is a NOP
because of not having a window surface. In this case, the CLE can
grow indefinitely until the system runs out of memory resources.
This approach is followed by different drivers forcing the flush
of CL when it reaches a defined size because of HW limitations.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12227
Cc: mesa-stable
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35042>
(cherry picked from commit ed16884bfa)
Mark when at least one job for the current active FBO has already been
submitted since the last framebuffer state update.
With this we can apply TLB load invalidation only to the first
job that is submitted to the same FBO. Not applying TLB
loads invalidation on follow-up jobs targeting the same framebuffer
state.
With this we avoid doing incorrect invalidations when we force
a job submission for a reason not related with a new framebuffer bind.
Cc: mesa-stable
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35042>
(cherry picked from commit 6ff509593c)
Before we move a UBO load to a previous location in the block we take a
reference to the instruction after it so we can continue the loop from
there, however, if the load we just moved was already the last instruction
in the block we just want to break the loop right there.
Fixes crashes with shaders from http://flightradar24.com
Fixes: 8998666de7 ("broadcom/compiler: sort constant UBO loads by index and offset")
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35333>
(cherry picked from commit c059c721fb)
0e3e5146cf ("intel/brw: Use correct instruction for value change check
when coalescing") enabled some new cases that exposed a pre-existing
bug that would turn something like this :
mul.sat(16) %789:F, %787:F, %788:F
mov.g.f0.0(16) %790:F, %789:F
(+f0.0) sel(16) %800:UD, %790:UD, 0u
into this :
mul.sat(16) %790:F, %787:F, %788:F
mov.g.f0.0(16) null:F, null<8,8,1>:F
(+f0.0) sel(16) %800:UD, %790:UD, 0u
The mov[] array can contain the same instruction because it's repeated
for each REG_SIZE writes and a SIMD16 instruction will write 2
REG_SIZE.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 0e3e5146cf ("intel/brw: Use correct instruction for value change check when coalescing")
Cc: mesa-stable
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35276>
(cherry picked from commit a51d061c00)
in a scenario like:
* begin_rendering(cbuf1:store=DONTCARE, cbuf2)
* draw
* remap(cbuf2, NULL)
* draw
* end_rendering
cbuf1 will be poisoned at the end of the renderpass, but the corresponding
clear call to trigger the poisoning will not be able to detect that this
texture is being written by an async fs, causing a write hazard
unremapping the fb here ensures that all attachments are fb-referenced
as expected in order to guarantee threads sync before memory is poisoned
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35319>
(cherry picked from commit d8a6ec5985)
When binning with a GS, both VS and GS are active. This means that we
could have to use the safe-const variant for the GS. However we only
emitted VPC state for the binning case with the "normal" GS variant.
Emit the VPC state with the safe-const variant too, and select between
the state variants at link time.
This fixes a few tests like
dEQP-VK.spirv_assembly.instruction.graphics.8bit_storage.32struct_to_8struct.uniform_uint_geom
with TU_DEBUG=gmem,forcebin.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35294>
(cherry picked from commit 723a1fabac)
If the render area is restricted to a section of the framebuffer, there
is no need to consider all the framebuffer size when configuring the
supertiles, as only the supertiles coordinates of the affected area will
be submitted.
This allow to create supertiles smaller than the ones in case
considering the full screen, reducing the tiles that need to be
processed.
This also fixes https://gitlab.freedesktop.org/mesa/mesa/-/issues/13218.
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35257>
(cherry picked from commit d30a6f8102)
So far the driver was configuring the supertiles to be less than 256.
But actually, there can be up to 256, not strictly less than 256.
There is one restriction though: the frame width or height in supertiles
must be less than 256.
It also moves this limit to the limits file, which is shared by v3d and
v3dv.
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35257>
(cherry picked from commit 2cac70558d)
This mirrors AMDVLK. 128-byte alignment is possible, but DOOM: The Dark
Ages screws up scratch allocation with alignments <256 bytes.
Fixes hangs in DOOM: The Dark Ages.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35152>
(cherry picked from commit dac6f09451)
This try to mitigate the HiZ GPU hang by increasing a timeout. Loosely
based on PAL but I can confirm it delays the hang when
BOTTOM_OF_PIPE_TS is used as a workaround.
This must be emitted when the GFX queue is idle.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35212>
(cherry picked from commit 47f5d25f93)
Applications using Mesa built with LLVM 20.1.4 fail to start with
strange segmentfaults/bus errors when radeonsi driver is used. The last
piece of stacktrace looks like
- pipe_reference_described
- pipe_reference
- radeon_bo_reference
- radeon_ws_bo_reference
- radeon_lookup_or_add_real_buffer
Coredump shows the pointer dst passed to pipe_reference_described() is
either unaligned or even invalid, which is the reason of crashing. The
crash goes away when Mesa is built without optimization.
Looking through the related functions, it's found that
radeon_ws_bo_reference() contains unsafe type cast from radeon_bo to
pb_buffer_lean: though the former's first field is just the later, this
violates strict aliasing rules as pb_buffer_lean isn't compatible with
radeon_bo. Such violation ultimately results in miscompilation.
Let's take the address of pb_buffer_lean field, avoiding the unsafe
cast. It's still required to cast pb_buffer_lean back to radeon_bo since
radeon_bo_reference may update the pointer, which is safe as radeon_bo
contains a pb_buffer_lean member and C language permits access members
through a pointer in type of the container.
Fixes: 6d913a2bcc ("r300,r600,radeonsi: switch to pb_buffer_lean")
Link: https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Aliasing-Type-Rules.html
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35249>
(cherry picked from commit b1d81a7df1)
In panfrost_clear_depth_stencil and panfrost_clear_render_target, we
start the blit context before binding the clear targets. If we don't
legalize AFBC beforehand, we get a recursive blit crash. panfrost_clear
does not need this because the resource should already be legalized in
panfrost_batch_add_surface.
Fixes the following piglit tests with pan_force_afbc_packing:
- spec@arb_clear_texture@arb_clear_texture-base-formats
- spec@arb_clear_texture@arb_clear_texture-simple
- spec@arb_clear_texture@arb_clear_texture-sized-formats
Fixes: 17a62ff993 ("panfrost: legalize afbc before blitting")
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34992>
(cherry picked from commit 104ea2e4cf)
In 59a3e12039, we changed the UBO->push optimization in panfrost to
only push UBOs that are available in a CPU buffer. We require
first_ubo_is_default_ubo, to ensure that UBO0 will be a user buffer. We
weren't setting this flag for the image conversion shaders, so got an
assertion failure compiling them. This can be triggered by the
panvk_force_afbc_packing driconf option.
The conversion shader info UBO isn't exactly a "default" UBO in the
sense of being lowered from uniforms, but it is a user buffer, so
setting the flag should be fine.
Fixes: 59a3e12039 ("panfrost: do not push "true" UBOs")
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34992>
(cherry picked from commit bed54fa402)
The BSpec page for Structure_RENDER_SURFACE_STATE says:
"For typed buffer and structured buffer surfaces, the number of
entries in the buffer ranges from 1 to 2^27. For raw buffer
surfaces, the number of entries in the buffer is the number of
bytes which can range from 1 to 2^30. After subtracting one from
the number of entries, software must place the fields of the
resulting 27-bit value into the Height, Width, and Depth fields as
indicated, right-justified in each field. Unused upper bits must be
set to zero."
According to the vkd3d-proton developers, this is what is happening
with the applications:
"There's also the problematic case of games using typed descriptors
but passing non-typed buffer descriptors, which is an extremely
common app bug that works on all D3D12 drivers that we need to work
around by creating typed views."
Previously, we had an assert() to check for "num_elements > (1 <<
27)", but that assert was preventing us from running games such as
Marvel's Spider-Man Remastered and Assassin's Creed: Valhalla in Debug
mode. So not only I removed the assert, but I also made the code clamp
num_elements to the maximum of (1 << 27) based on my incorrect
interpretation of the paragraph quoted above from BSpec.
What I did not realize was that num_elements is being used just to
calculate Structure_RENDER_SURFACE_STATE Height, Width and Depth, and
our register bit fields on SKL and newer are big enough to fit any
number of num_elements up to 2^32, not only 2^27. Clamping
num_elements results in an incorrect value for S.Depth, which
generates visual corruption in some games.
On Marvel's Spider-Man Remastered, without this patch the texture of
the asphalt in some streets (like the very first one you jump to when
the game starts) gets rendered incorrectly.
Testcase: vkd3d-proton/d3d12/test_large_texel_buffer_view
Link: https://github.com/HansKristian-Work/vkd3d-proton/issues/2071
Link: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12827
Fixes: f3c7e14f09 ("isl: don't assert(num_elements > (1ull << 27))")
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/35032>
(cherry picked from commit ecc90e1bb3)
We should use the cl_slice code to get proper validation, which also makes
it simpler to read out data and gets rid of some UB there.
This also fixes CL_KERNEL_EXEC_INFO_SVM_PTRS with param_value being null.
Cc: mesa-stable
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32942>
(cherry picked from commit 35a9829391)
Normal fmin doesn't make any promises about NaN, common additionally
doesn't make any promises about infinities. Would be nice to hook that
up to codegen but lowering them to normal works for now.
Cc: mesa-stable
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34941>
(cherry picked from commit 4b1c824b67)
For partial secondary cmdbufs, we emit FBDs/TDs in the primary cmdbuf
before calling the secondary. In order to set the provoking vertex mode
correctly here, we need to look at the mode set by pipelines bound in
the secondary cmdbuf.
This leaves one edge case: reemitting FBDs/TDs in a secondary cmdbuf
after a flush. If the secondary cmdbuf only contains vk_meta draws,
without ever binding a pipeline, we won't know which provoking vertex
mode to use here. This is actually okay, because in that case the
provoking vertex mode doesn't matter for any of the draws in the
secondary, and the FBDs/TDs will be reemitted on the primary with the
correct mode.
Fixes: 7a9f14d3c2 ("panvk: advertise VK_EXT_provoking_vertex")
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Tested-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Ryan Mckeever <ryan.mckeever@collabora.com>
(cherry picked from commit 65406cf500)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35194>
Because we advertise provokingVertexModePerPipeline=false, the provoking
vertex mode must be set the same for all pipelines used in a renderpass.
vk_meta doesn't care about the provoking vertex mode, but the vulkan api
doesn't provide a way to express this, so it always sets
PROVOKING_VERTEX_MODE_FIRST (the vulkan default). This causes an
assertion failure when vk_meta is used in a renderpass where the
application sets PROVOKING_VERTEX_MODE_LAST.
There are a few different cases here, that need different handling. The
simplest is when vk_meta is used after the first application draw, in
which case we can just ignore the state passed by vk_meta and use the
existing state.
Fixes: 7a9f14d3c2 ("panvk: advertise VK_EXT_provoking_vertex")
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Tested-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Ryan Mckeever <ryan.mckeever@collabora.com>
(cherry picked from commit 4d99346477)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35194>
The tiler OOM exception handler allocated a region of memory to dump
save/restored registers. For defining more functions in the future, we
allocate a register dump region for each subqueue, that can hold the
largest number of registers needed by any functions executed on that
subqueue.
This does mean that we cannot have function calls more than one deep. If
we ever need nested function calls, we will have to consider a real
stack.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Tested-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Ryan Mckeever <ryan.mckeever@collabora.com>
(cherry picked from commit d60c688317)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35194>
tc_sync reuses the same batch, which breaks the current disambiguation
methods by returning !busy for work which is currently executing
on the reused batch
by also tracking the completed generation, this scenario is detected
and disambuguated
Fixes: 9cc06f817c ("tc: allow unsynchronized texture_subdata calls where possible")
(cherry picked from commit b89e0fa226)
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35204>
During direct dispatch, we calculate the size of the WLS allocation
based on the number of WLS instances which is an unbounded calculation
on number of workgroups.
This leads to extreme allocation sizes and potentially
VK_ERROR_OUT_OF_DEVICE_MEMORY for direct dispatches with a high amount
of workgroups.
This change adds an upper bound to the number of WLS instances, using
the same value we assume for indirect dispatches.
Additionally, this commit fixes the WLS max instance calculation (which
should be per core).
Fixes: 5544d39f44 ("panvk: Add a CSF backend for panvk_queue/cmd_buffer")
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: John Anthony <john.anthony@arm.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34979>
(cherry picked from commit 0a47a1cb6d)
This update is aimed at fixing pop-free clipping and follows
the advices by Vitaliy Kuzmin: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12440
This functionality requires calculating the value of the following two
registers: PA_CL_GB_HORZ_DISC_ADJ and PA_CL_GB_VERT_DISC_ADJ. These two
registers are available on all the gpus of the r600 family.
This code is built on the backport of radeonsi updates which are relevant
to this very functionality:
57e658d041 "radeonsi: rework how guardband registers are updated to decrease overhead"
146c2b7c28 "radeonsi: adjust clip discard based on line width / point size"
4d74432dd3 "radeonsi: don't discard points and lines"
63680471f9 "radeonsi: remove si_context::{scissor_enabled,clip_halfz}"
This change was tested on rv770, barts and cayman:
deqp-gles[2-3]/functional/clipping/line/wide_line_clip_viewport_center: fail pass
deqp-gles[2-3]/functional/clipping/line/wide_line_clip_viewport_corner: fail pass
deqp-gles[2-3]/functional/clipping/point/wide_point_clip: fail pass
deqp-gles[2-3]/functional/clipping/point/wide_point_clip_viewport_center: fail pass
deqp-gles[2-3]/functional/clipping/point/wide_point_clip_viewport_corner: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35052>
(cherry picked from commit df2c774a83)
We still allow mesh shader promote constant output to flat, but
mesh shader like geometry shader may store multi vertices'
varying in a single thread. So mesh shader may store different
constant values to different vertices in a single thread, we
should not promote this case to flat.
I'm not using shader_info.mesh.ms_cross_invocation_output_access
because OpenGL does not require IO to have explicit location, so
when nir_shader_gather_info is called in OpenGL GLSL compiler to
compute ms_cross_invocation_output_access, some implicit output
has -1 location which causes ms_cross_invocation_output_access
unset for it.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13134
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35081>
(cherry picked from commit 6f2a1e19da)
llvmpipe driver name needs to be added to the list triggering MESON_GEN_LLVM_STUB := true
due to swrast driver name being an invalid gallium driver
swrast driver name is still used for lavapipe vulkan driver
Fixes: a3909092 ("meson: drop deprecated `swrast` alias for softpipe+llvmpipe")
Backport-to: 25.1
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35121>
(cherry picked from commit ff6b181c2d)
When an application issues a sparse binding operation, it may be the
case that the state the app is setting is the state that is already
there. In that case, both n_l3l2_binds and n_l1_binds are zero, so the
batch doesn't contain anything and, since 0802bbd486, we just skip
the batch submission and return.
The problem is that skipping the batch submission and returning
ignores the synchronization: there may be syncobjs that we have to
wait and, more importantly, there may be syncobjs that we have to
signal.
This case is exercised by vkd3d-proton's test suite, but I'm not aware
of any other workload that triggers it. This commit only affects
Meteor Lake and older, as TR-TT is only the default behavior for the
platforms running i915.ko.
Testcase: vkd3d-proton/d3d12/test_sparse_buffer_memory_lifetime
Fixes: 0802bbd486 ("anv/trtt: don't submit empty batches when there are no binds to do")
Reviewed-by: Iván Briano <ivan.briano@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35078>
(cherry picked from commit d77b49eb0a)
Freedreno limits set_global_binding() to 16 resource entries
(MAX_GLOBAL_BUFFERS), however RustiCL can pass more global resources
(e.g. OpenCL CTS test api / min_max_constant_args requires passing of
17). Follow example of other drivers and use dynamic array for global
bindings.
Backport-to: 25.1
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35122>
(cherry picked from commit 5c43cf823c)
The cubemap-to-array pass was changing variable types from samplerCubeArray
to sampler2DArray but leaving the corresponding deref instruction types
unchanged. This caused NIR validation to fail with "instr->type ==
instr->var->type" assertion.
Fix by updating both the variable type and the deref instruction type
to maintain consistency required by NIR validation.
Cc: mesa-stable
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35117>
(cherry picked from commit 86f7ce06be)
Those intrinsics have different semantics in particular with regards
to divergence. Turning one into the other without invalidating the
divergence information breaks NIR validation. But also the conversion
means we get artificially less convergent values in the shaders.
So just handle load_push_constants in the backend and stop changing
things in Hasvk.
Fixes a bunch of tests in
dEQP-VK.descriptor_indexing.*
dEQP-VK.pipeline.*.push_constant.graphics_pipeline.dynamic_index_*
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34546>
(cherry picked from commit b036d2ded2)
Those intrinsics have different semantics in particular with regards
to divergence. Turning one into the other without invalidating the
divergence information breaks NIR validation. But also the conversion
means we get artificially less convergent values in the shaders.
So just handle load_push_constants in the backend and stop changing
things in Anv.
Fixes a bunch of tests in
dEQP-VK.descriptor_indexing.*
dEQP-VK.pipeline.*.push_constant.graphics_pipeline.dynamic_index_*
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34546>
(cherry picked from commit df15968813)
These are benign style warnings. The code is generated by bindgen and it's a bug there that these
names get generated at all.
Silences these warnings since we can't do anything about them:
```
warning: method `use__raw` should have a snake case name
--> src/etnaviv/isa/isa_bindings.rs:358:19
|
358 | pub unsafe fn use__raw(this: *const Self) -> ::std::os::raw::c_uint {
| ^^^^^^^^ help: convert the identifier to snake case: `use_raw`
|
= note: `#[warn(non_snake_case)]` on by default
warning: method `use__raw` should have a snake case name
--> src/etnaviv/isa/isa_bindings.rs:1023:19
|
1023 | pub unsafe fn use__raw(this: *const Self) -> ::std::os::raw::c_uint {
| ^^^^^^^^ help: convert the identifier to snake case: `use_raw`
```
Fixes: 15a784689e ("etnaviv: isa: Generate Rust FFI bindings for asm.h")
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34969>
(cherry picked from commit 040ef8f5c9)
As stated in the OpenCL standard, the lowest allowed values
CL_DEVICE_MAX_PARAMETER_SIZE and CL_DEVICE_LOCAL_MEM_SIZE in case of the
embedded profile are 1K. Limit the check to full profile only, in order
to stop forcing OpenCL 1.0 for embedded-profile device like Qualcomm
Adreno A702.
Backport-to: 25.1
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35073>
(cherry picked from commit 275a39b3c6)
On GFX11+, DISABLE_FOR_AUTO_INDEX=1 automatically disables primitive
restart enable for non-indexed draws.
On GFX10-GFX10.3 the hw considers primitive restart enable for
non-indexed draws and the driver must disable it explicitly.
GFX9 and older gens aren't affected but applying the change for them
simplifies the implementation.
To fix that, move emitting primitive restart enable at draw time
because it needs to know if the draw is indexed or not.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13037
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34996>
(cherry picked from commit 4d1fcd75f9)
`lp_build_round` intends to implement round with ties-to-even behavior,
as can be seen by its test's use of `nearbyint` to generate reference
values and by it use in implementing `nir_op_fround_even`.
Fixes: 0d3b285360 ("gallivm: use llvm intrinsics for 16-bit round/trunc/roundeven")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34937>
(cherry picked from commit eea3ed6a37)
The 2 helpers we're using for doing internal operations (copies,
command generation, etc...) can work on command buffers or lower level
batches.
When working with command buffers, the helpers should set the
preemption using genX(cmd_buffer_set_preemption) so that whatever
operation comes after toggles the state back to what it needs and we
minimize the toggles.
When working with batchs, the helpers should disable preemption using
genX(batch_set_preemption) and turn it back on when done.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35030>
(cherry picked from commit c570740272)
Otherwise we end up removing refcount even when we don't have a color
surface already for applications going from SRGB_NONLINEAR to
PASS_THROUGH dring runtime.
To reproduce the bug, start mpv with "--target-colorspace-hint=yes" then
set it to "no" during runtime with a keybind
Fixes: 789507c99c ("vulkan/wsi: implement the Wayland color management protocol")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34708>
(cherry picked from commit 033ce1bae1)
On v11+, because FROUND.v2f16 is gone we end up with precision issues.
We now lower ffract in bifrost_nir_algebraic instead of during common
algebraic to ensure lower_bit_size has been performed.
This fixes
"dEQP-GLES3.functional.shaders.builtin_functions.common.fract.vec2_lowp_vertex"
and
"dEQP-GLES31.functional.shaders.builtin_functions.common.fract.vec2_lowp_compute".
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Backport-to: 25.1
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34970>
(cherry picked from commit 60b131a712)
When the hardware doesn't natively support 32-bit predication, the
driver has a fallback which allocates a 64-bit predicate to the upload
BO in order to copy the original value.
But when conditional rendering is enabled in the stateCommandBuffer
which is used by preprocess() and the execute() is recorded also in the
stateCommandBuffer. If the preprocess() is recorded in a different
cmdbuf which is submitted before the cmdbuf that contains execute(),
the fallback (ie. alloc + COPY_DATA) will be performed after. This would
cause the predicate value to be always 0.
To fix that, keep track of the user predication VA which is the only
VA that needs to be used by DGC because it reads 32-bit from the shader.
This fixes a very weird corner case with vkd3d-proton.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13143
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34953>
(cherry picked from commit 3ca2f71f3d)
'X4.exe' is the executable. But there is also a script 'X4' that is used to
launch the game. This script is what steam uses.
This updates driconf to match that.
This also brings the executable in line with other configs for the game.
Fixes: 5532f13566 ("driconf: override vendor id for X4 Foundations on NVK")
Fixes: 8654a7727f ("driconf: set vk_zero_vram driconf for X4 Foundations")
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34168>
(cherry picked from commit a87c9bc49e)
This optimization used to optimize the allocated space for descriptors
when immutable samplers are equal. Though, this was basically broken :
- descriptor copies were broken for combiner image sampler (or sampler)
with equal immutable samplers because 96 bytes were copied instead of
64 bytes (cf. the linked ticket). This could be fixed but it's not
worth it.
- the value returned by vkGetDescriptorLayoutSupport() was broken, it
should have been 96 with no immutable samplers (or when they aren't
equal)
This optimization was also not applied for descriptor buffers which is
the default for vkd3d-proton and Zink. DXVK doesn't use db but it
doesn't use immutable samplers, so basically only native vulkan games
would be concerned.
Note that immutable samplers would still be inlined in shaders if no
indirect access which should be 99.9% of the usecase.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11165
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34928>
(cherry picked from commit 69ff204422)
The hardware requires a power of two bpe. To do that, the driver
needs to adjust the pitch/offset/extent based on a texel scale factor
which only applies to 96-bits formats.
This fixes new VKCTS coverage.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34927>
(cherry picked from commit 4b73d7e817)
Storage access to images using LEA_TEX[_IMM] has limitations on some
fields in the texture descriptors, making them incompatible with the
descriptors required for texture access, specifically in the case
non-zero levels.
This change sets up two sets of texture descriptors for image views of
storage images, then picks the correct one when writing the image view
descriptors.
Backport-to: 25.0
Backport-to: 25.1
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34839>
(cherry picked from commit 7451bc3bef)
The width/height fields in the plane descriptors for v13 are missing
their minus(1) modifiers.
This change adds the missing modifiers, which implies also setting
default values to 1 due to how the Two-Plane YUV Overlay interacts with
the plane descriptors.
Fixes: ece01443e1 ("pan/genxml: Add v13 definition")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34839>
(cherry picked from commit 009e4c2eba)
The width/height fields in the plane descriptors for v12 are missing
their minus(1) modifiers.
This change adds the missing modifiers, which implies also setting
default values to 1 due to how the Two-Plane YUV Overlay interacts with
the plane descriptors.
Fixes: b6d5e01120 ("pan/genxml: Add v12 definition")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34839>
(cherry picked from commit e38eb00e4e)
The width/height fields in the plane descriptors for v10 are missing
their minus(1) modifiers.
This change adds the missing modifiers, which implies also setting
default values to 1 due to how the Two-Plane YUV Overlay interacts with
the plane descriptors.
Fixes: 486c341769 ("panfrost: Add architecture description XML for v10")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34839>
(cherry picked from commit 2542857259)
Right now llvmpipe only successfully supports single-plane formats,
limiting the number of supported YCbCr formats to a relatively small
number.
The implicit support for R8G8_R8B8 style subsampled RGB formats
causes the most common ones, YUYV and its variants, to chain up
to to lp_build_fetch_subsampled_rgba_aos() when importing (u)dmabufs
with EXT_image_dma_buf_import.
This code path currently has at least the following issues:
1. It doesn't support the YVYU/PIPE_FORMAT_R8B8_R8G8_UNORM and
VYUY/PIPE_FORMAT_B8R8_G8R8_UNORM, resulting in asserts/crashes.
2. The supported cases, YUYV and UYVY, end up with sub-optimal results
as they always return BT.601/narrow results, ignoring
EGL_YUV_COLOR_SPACE_HINT_EXT and EGL_SAMPLE_RANGE_HINT_EXT.
Stopping advertising support for those formats, as well as native support
for PIPE_FORMAT_YUYV and PIPE_FORMAT_UYVY, results in all four variants
taking fallback paths which happen to be much better supported.
An additional effect is that YUYV and UYVY are correctly advertised as
external only.
Cc: mesa-stable
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34775>
(cherry picked from commit 4051d4ef59)
The vdrm_vpipe_connect() prototype defined in vdrm.c doesn't match
vdrm_vpipe_connect() defined in vdrm_vpipe.c. This leads to a compilation
warning about the wrong proto when Mesa linked with enabled LTO. Fix the
vdrm_vpipe_connect() definition.
Fixes: bf0e3d6274 ("virtio/vdrm: Add vtest backend")
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34819>
(cherry picked from commit daad392d5c)
intel_decoder_init() initializes intel_batch_decode_ctx so later
we can call decode functions but it depends on data stored in
brw/elk_isa_info but that was being allocated in stack
of intel_decoder_init() then when the decode functions were executed
it was accessing garbage at the brw/elk_isa_info memory.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: ec2d20a70d ("intel/tools: Add helpers for decoder_init/disasm")
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34776>
(cherry picked from commit 3e5a735d01)
Or current render target cache setting is to key on the binding table
index, meaning the HW associates a number in the range [0, 7] to a
RENDER_SURFACE_STATE description. If you want change the render target
0 between 2 draw calls, you need to insert a PIPE_CONTROL in between
the 2 draw calls with pb-stall + rt-flush in order to flush an writes
to a previous RENDER_SURFACE_STATE that has now becomed disassociated
with the [0, 7] number.
This PIPE_CONTROL taking care of the flush is dealt with in
cmd_buffer_maybe_flush_rt_writes(). This function diffs the current
BTI setup for render targets (first 0 to 7 BTIs) with what the next
fragment shader wants.
The issue here is we might have a render pass with 0 color attachments
and yet in 98cdb9349a we added one pointing to the render target 0,
but in the emit_binding_table() when we finally program the BTI, we
check the render pass color count and program a null surface state
instead of an actual surface state. And this leads to hangs because
the render target cache will end up with inconsistent state data.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 98cdb9349a ("anv: ensure null-rt bit in compiler isn't used when there is ds attachment")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12955
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34603>
(cherry picked from commit 63f633557f)
On a7xx, the max constlen for compute is increased to 512 vec4s or 8KB,
however the size of the LB was not increased beyond 40KB. A quick
calculation shows that 8KB of consts multiplied by 2 banks plus the
API maximum of 32KB shared memory would exceed 40KB. This means that
we can't always use a constlen of 512, and sometimes have to fall back
to 256 when a lot of shared memory is in use.
In the future, we can use similar calculations to figure out how much
"extra" shared memory is available for the backend to spill to, but we
currently don't support spilling to shared memory.
Fixes: 5879eaac18 ("ir3: Increase compute const size on a7xx")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34746>
(cherry picked from commit ea9d694a7b)
This fixes a compilation issue in Marvel Rivals where the legalization
logic and the encoding logic don't line up, which results in an
assertion failure on this instruction:
r17 = hfma2 r17.xx -r18.xx 0x3c003c00
The fix here is a little overly restrictive because it turns out we
actually do have modifiers for all 3 sources. Those modifiers will
be added in later commits.
Fixes: 567cae69c3 ("nak: Add 16-bits float operations")
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34750>
(cherry picked from commit 1ff7135691)
Most of the churn in this commit is changing unit tests that were
testing things that are now invalid.
shader-db:
All Intel platforms had similar results. (Lunar Lake shown)
total instructions in shared programs: 17122204 -> 17122669 (<.01%)
instructions in affected programs: 120669 -> 121134 (0.39%)
helped: 0 / HURT: 124
total cycles in shared programs: 895602370 -> 895613210 (<.01%)
cycles in affected programs: 17868974 -> 17879814 (0.06%)
helped: 35 / HURT: 85
fossil-db:
All Intel platforms had similar results. (Lunar Lake shown)
Totals:
Instrs: 210736518 -> 210743769 (+0.00%)
Cycle count: 30377733040 -> 30377699060 (-0.00%); split: -0.00%, +0.00%
Max live registers: 66056852 -> 66056966 (+0.00%)
Totals from 1505 (0.21% of 706776) affected shaders:
Instrs: 1890151 -> 1897402 (+0.38%)
Cycle count: 48397408 -> 48363428 (-0.07%); split: -0.11%, +0.04%
Max live registers: 256821 -> 256935 (+0.04%)
Reviewed-by: Matt Turner <mattst88@gmail.com>
Fixes: 020b0055e7 ("i965/fs: Propagate conditional modifiers from compares to adds")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34509>
(cherry picked from commit e26270249b)
When I originally wrote that code, I didn't understand what a jerk NaN
can be.
v2: Remove the brw_type_is_uint stuff. This function is currently only
called for float types. In a later commit, integer types will be
supported but only for NZ and Z conditions. Noticed by Matt.
shader-db:
All Intel platforms had similar results. (Lunar Lake shown)
total instructions in shared programs: 17122197 -> 17122204 (<.01%)
instructions in affected programs: 1691 -> 1698 (0.41%)
helped: 0 / HURT: 4
total cycles in shared programs: 895602484 -> 895602370 (<.01%)
cycles in affected programs: 912964 -> 912850 (-0.01%)
helped: 2 / HURT: 2
fossil-db:
All Intel platforms had similar results. (Lunar Lake shown)
Totals:
Instrs: 210736388 -> 210736518 (+0.00%)
Cycle count: 30377728900 -> 30377733040 (+0.00%); split: -0.00%, +0.00%
Totals from 130 (0.02% of 706776) affected shaders:
Instrs: 169911 -> 170041 (+0.08%)
Cycle count: 18021210 -> 18025350 (+0.02%); split: -0.00%, +0.02%
Reviewed-by: Matt Turner <mattst88@gmail.com>
Fixes: 020b0055e7 ("i965/fs: Propagate conditional modifiers from compares to adds")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34509>
(cherry picked from commit 0dab520a19)
A8_UNORM on v9+ is using RGBA8_UNORM as a pixel format with the
A8_UNORM clump format to dealing with the diffences between
RGBA8 and the actual A8 in-memory layout.
The problem is, LEA_TEX only loads the InternalConversionDescriptor
which contains only the pixel format, and that's what ST_CVT uses
to do the conversion, so we'll actually store 4 components instead
of one.
This shows up with
dEQP-VK.image.load_store.without_any_format.buffer.a8_unorm* after
enabling maintenance5.
For now I've turned off the image storage capability for A8_UNORM
on all gens, but I'd be fine disabling it only on v9+ if you think
that's preferable.
Fixes: d95423686f ("pan/format: Add PAN_BIND_STORAGE_IMAGE flag")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34648>
(cherry picked from commit 9d1262e108)
This is the most serious bug we've had in a long time due to a fundamental
misunderstanding of the hardware (due to incomplete reverse-engineering). It
caught me off guard.
The texture descriptor has "mode" bits which configure two aspects of how the
address pointer is interpreted:
* whether it is indirected, pointing to a secondary page table for sparse
* whether it writes texture access counters (for Metal's idea of sparse).
...Neither of these is a "null texture" mode.
So why did I see Apple's blob using a non-normal mode for null textures, and why
did I copy those settings?
1. Because the hardware texture access counters provide a cheap way to detect
null texture accesses after the fact, which I think their GPU debug tools
use. I'm not sure why release builds of the driver do/did that, but whatever.
2. Because I assumed Cupertino knew best and I didn't bother looking too close.
We can't use them here (without doing extra memory allocations), since then
the GPU will increment access counters. And since our null texture address used
to just be a pointer in the command buffer, that mean the GPU will trash
whatever memory happened to be 0x400 bytes after the start of the null texture
descriptor. The symptom being random faults.
This bug was caught when trying to use the zero-page instead, which raised a
permission fault when the GPU tried to write counts. Then I remembered the
sparse mechanism and had a bit of a eureka moment. Immediately followed by an
"oh, f#$&" moment as I realized how many random bugs could potentially be root
caused to this.
The fix is two-fold:
1. Use normal layout instead.
2. Set the address to the zero-page (which is a fixed VA) and detect null
textures by checking the address, instead of the mode.
The latter is a good idea anyway, but both parts needs to be done atomically to
maintain bisectability.
Backport-to: 25.1
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34703>
(cherry picked from commit 3eb7575679)
Since headless overrides create_mem, it needs to override finish_create
too. Fixes a segfault in nvk that was caused by us mixing
wsi_create_null_image_mem with wsi_finish_create_blit_context, which
would then call CmdCopyImageToBuffer with image->blit.buffer == NULL
Fixes a cts failure on nvk in:
dEQP-VK.image.swapchain_mutable.headless.2d.r8g8b8a8_unorm_b8g8r8a8_unorm_clear_copy_format_list
and several others
Fixes: 579578f10a ("vulkan/wsi/drm: Break create_prime_image in pieces")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34646>
(cherry picked from commit 60452e016e)
Currently mesa-clc bundles OpenCL headers from Clang only if the static
LLVM is used (which means Clang / LLVM are not present on the target
system). In some cases (e.g. when building in OpenEmbedded environemnt)
it is desirable to have shared LLVM library, but skip installing the
whole Clang runtime just to compile shaders. Add an option that forces
OpenCL headers to be bundled with the mesa-clc binary.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34551>
(cherry picked from commit 419a9e9d42)
I don't understand why, but somehow the changes in e38631ad...3d9ac270
is causing this 1) in a file that has not changed, and 2) on lines that
are indented identically, with the `for` in the macro being terminated
with a `;` semicolon by the caller, so it looks all good to me.
Silencing this allows me to get the release through, but I probably
won't look back either, so hopefully there won't be a legitimate
instance of that warning in the future 😇
Xe2 changed the MOCS field in few instructions, those now have a field
for the MOCS index and other the encryption enable bit but ISL returns
the combination of both aka MEMORY_OBJECT_CONTROL_STATE.
To minimize changes I have added 2 macros to extract the values
from the value returned by isl.
From all the instructions changed Mesa only make use of two, so the
other instruction will be handled in the next patch.
Cc: mesa-stable
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34592>
(cherry picked from commit 161c412a82)
si_destroy_context needs to call context->set_debug_callback(...) to
avoid the debug logs to access the destroyed context.
Adding this change introduced a different problem: when an aux context
is destroyed from si_destroy_screen, parts of the screen have been
freed already: the shader_compiler_queue_*.
c467a87e06 ("radeonsi: Destroy queues before the aux contexts") moved
the util_queue_destroy calls above the context destruction, but with
the 59a3f38ff6 change, it's not needed anymore: si_destroy_context
will finish the screen shader queues before proceeding with releasing,
so use-after-free isn't possible.
Fixes: 59a3f38ff6 ("radeonsi: clear the debug callback on ctx destroy")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12035
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34574>
(cherry picked from commit 2a381bbc3c)
Letting the shader offset instanceID by baseInstance works only if
the divisor is one. If the divisor is greater than one, the firstInstance
parameter shouldn't be applied this divisor, but it currently is. Zero
divisors are also problematic, in that they will force use of the
instance zero attribute all the time.
The only way to fix that is to tweak the offsets of the per-instance
attributes instead, like is done in the JM backend.
Fixes: 1570f0172e ("panvk: Fix base_{instance,vertex} handling")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Olivia Lee <benjamin.lee@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34642>
(cherry picked from commit b2a8e3838d)
DRM_FORMAT_MOD_QCOM_COMPRESSED forces the image to be UBWC regardless
of what's better for perf, we should respect that.
The regression is seen in GTK4 when it tries to create tiny swapchain
images.
Fixes: fc50fb35b0
("tu,freedreno: Enable linear mipmap tail for UBWC images")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34628>
(cherry picked from commit 36f22cc951)
When doing the flushing, I forgot that because the staging buffer can be
used with different formats with different cpp, we need to make sure
that CCU is properly flushed and invalidated between each copy to the
staging buffer to prevent stale cache entries from creeping in, as the
CCU seems to rely on the cpp staying the same, even on a7xx which
dropped some of the other restrictions like using the same RT
index/layer. For "normal" user-visible copies this is done via
transitioning from UNDEFINED.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34611>
(cherry picked from commit ee10938bee)
We were forgetting to reset the map count to 0 in case of dyn_bufs in
create_copy_table.
This was causing invalid copy entries to be added to the table causing
invalid copies in most situation with holes in the set definition while
still binding set 0 or at worst an assert to be triggered in
cmd_fill_dyn_bufs.
This fixes "dEQP-GLES3.functional.ubo.*" and
dEQP-GLES31.functional.ubo.*" on PanVK+ANGLE.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Fixes: e350c334b6 ("panvk: Extend the descriptor lowering pass to support Valhall")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34652>
(cherry picked from commit 8d2e16cc11)
Fixes cts tests:
dEQP-VK.conditional_rendering.conditional_ignore.blit_image
dEQP-VK.conditional_rendering.conditional_ignore.blit_image_inverted
dEQP-VK.conditional_rendering.conditional_ignore.resolve_image
dEQP-VK.conditional_rendering.conditional_ignore.resolve_image_inverted
which were introduced in vk-gl-cts commit 4aa277c300
Fixes: 32f2317223 ("nvk: Use meta for doing blits with the 3D hardware")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34644>
(cherry picked from commit 2fc4c98aaf)
On v12+, the hardware report support for 8 levels but
effectively only support up to 4 levels.
In case more than 4 levels are used, it will default to 0xAA when
tile_size is 32x32 or lower, otherwise 0xAC when the tile_size is greater than 32x32.
This patch makes it that we now ensure that the bins can fit inside out
tiler budget and otherwise drop levels until it fit.
This also allows the hardware to decide the hierarchy on v12+
if we know it will fit.
This fixes "dEQP-GLES31.functional.fbo.no_attachments.maximums.all" and
dEQP-GLES31.functional.fbo.no_attachments.maximums.size" on v12+ but
also likely more if we were exhausting the memory budget.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Backport-to: 25.1
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34559>
(cherry picked from commit 92afeb37bf)
When VMMs do not support VIRTGPU_DRM_CAPSET_VENUS the capset data
remains zeroed. By requiring the stable wire_format_version 1 this can
be detected early without initialising the renderer.
Avoids triggering `assert(capset->supports_blob_id_0);` in debug builds
under such circumstances.
Cc: mesa-stable
Signed-off-by: Janne Grunau <j@jannau.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34613>
(cherry picked from commit 3d3ca9b65e)
rather than always early killing and then hitting pathological shuffle
situations, only early-kill when we can prove that we won't need to shuffle. it
turns out that's most of the time.
even with this heuristic, we still get hurt bad in shader-db due to extra moves.
but hopefully, the #s here are small enough that we can move on with our lives
and fix this source of known unsoundness.
this is tagged for backport as it's needed to avoid a perf regression with the
previous patch.
combined stats from this commit and the previous commit:
total instrs in shared programs: 2846065 -> 2852257 (0.22%)
instrs in affected programs: 618734 -> 624926 (1.00%)
total alu in shared programs: 2329477 -> 2335534 (0.26%)
alu in affected programs: 508119 -> 514176 (1.19%)
total gprs in shared programs: 894762 -> 901327 (0.73%)
gprs in affected programs: 36946 -> 43511 (17.77%)
Backport-to: 25.1
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34595>
(cherry picked from commit b1e86b3eae)
shader-db stats combined with next commit. this is the rip off the bandaid, next
is the optimize. split to enable bisecting.
the code we have to shuffle clobbered killed sources is broken and, after
thinking about that for a Long time, I don't see a reasonable way to fix it. But
if we late-kill sources - or model our calculations as-if we were late-killing
souces - we never have to shuffle onto a killed source and the problem goes away
entirely.
this is similar in spirit to what NAK does. it's not "optimal", but it's sane.
Backport-to: 25.1
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34595>
(cherry picked from commit b88fe9b0c5)
This hurts us in two ways:
* slightly more spilling (not actually a big problem)
* slightly worse occupancy (the shaders that are "helped" here are from trying
less hard to fit at higher occupancy levels)
However, in exchange we get a LOT more flexibility in the RA.
total instrs in shared programs: 2847015 -> 2846065 (-0.03%)
instrs in affected programs: 84134 -> 83184 (-1.13%)
total alu in shared programs: 2330406 -> 2329477 (-0.04%)
alu in affected programs: 62305 -> 61376 (-1.49%)
total code size in shared programs: 20497326 -> 20491690 (-0.03%)
code size in affected programs: 586664 -> 581028 (-0.96%)
total gprs in shared programs: 894202 -> 894762 (0.06%)
gprs in affected programs: 8900 -> 9460 (6.29%)
total scratch in shared programs: 13292 -> 13304 (0.09%)
scratch in affected programs: 2924 -> 2936 (0.41%)
total threads in shared programs: 27819712 -> 27814272 (-0.02%)
threads in affected programs: 55296 -> 49856 (-9.84%)
total spills in shared programs: 907 -> 914 (0.77%)
spills in affected programs: 419 -> 426 (1.67%)
total fills in shared programs: 857 -> 862 (0.58%)
fills in affected programs: 389 -> 394 (1.29%)
Backport-to: 25.1
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34595>
(cherry picked from commit 7fad96d194)
Since MR !33891 EGL only supports a software driver (LLVM).
Routine dri3_x11_connect at
src/egl/drivers/dri2/platform_x11.c fails if DRI3 is not
available. So at that location variable *allow_dri2 should be set.
Looking at the major codition, we see it is not executed
if LIBGL_DRI3_DISABLE is set. In that case the hardware driver
is activated as desired. Previously this was not needed.
Also it is not practical, and not necessary.
I do not understand the major condition, so I did not change it.
This causes some duplicate coding.
Fixes: 323bad6b18 ("egl/x11: split out dri2 init entirely")
Signed-off-by: GKraats <vd.kraats@hccnet.nl>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34530>
(cherry picked from commit 995dc61bf5)
This is now basically the same as the original VALUMaskWriteHazard, except
it now considers both VALU and SALU writes.
Now that it's a part of VALUMaskWriteHazard, differences from the original
VALU lanemask workaround are:
- it includes SALU reads after the write
- it includes VALU writes and SALU/VALU reads after the write which are
not lanemasks
- it combines s_waitcnt_depctr instructions when it's a read after both a
SALU write and a VALU write
- non-exec VALU SGPR reads reset the SGPRs read by VALU as a lanemask
- exec SGPRs are ignored
resolve_all_gfx11() is also finished.
fossil-db (navi31):
Totals from 21538 (27.13% of 79377) affected shaders:
Instrs: 27628855 -> 27552972 (-0.27%); split: -0.30%, +0.03%
CodeSize: 145968448 -> 145667616 (-0.21%); split: -0.23%, +0.02%
Latency: 209537805 -> 209509519 (-0.01%); split: -0.02%, +0.00%
InvThroughput: 36304270 -> 36301624 (-0.01%); split: -0.01%, +0.00%
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12623
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11480
Backport-to: 25.0
Backport-to: 25.1
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34529>
(cherry picked from commit ce2be5ab8e)
In a previous iteration of the spilling code, we added an extra check to
only spill across edges if the value being spilled is in the W set.
This was due to a misunderstanding of the modeling of S and W in Braun
and Hack. In the current implementation, we maintain the invariant that
every live value is in at least one of S or W so we don't need that
check but it was left in by mistake.
One exception to this rule was added when we special-cased constant
values. Now the invariant is that every live value is in S, in W, or is
a constant. When we made this change, the check we accidentally left in
bit us because now if a value is constant but not in W, it wasn't
getting spilled across the edge. This can result in a value getting
filled later which was never spilled, leading to undefined values.
Fixes: 7b82e26e3c ("nak: Don't spill/fill const values")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12993
Co-authored-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34563>
(cherry picked from commit de1ed48325)
I accidentally disabled compression on CPS surfaces marked as storage or
color attachment for all platforms, when this should only be limited to
Xe.
Fixes: 80f9b6 ('anv: CPB surfaces that are used as color attachments or for stores cannot be compressed')
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34297>
(cherry picked from commit cbc1ec4f73)
These values are shared with xcb/dri2.h, and can't be changed
without breaking the legacy dri2 compatibility. This change
reverses partially the update done by 3b603d1646.
For instance this issue is triggered on dri2 i915 with
"piglit/bin/glx-copy-sub-buffer -auto" or
"piglit/bin/hiz-depth-read-window-stencil0 -auto".
Fixes: 3b603d1646 ("mesa_interface: remove unused stuff")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34561>
(cherry picked from commit 60a31156b0)
Introduces a backwards dataflow analysis pass to determine when a
certain register is always written to prior to being read in a
similar manner to SSA liveness but performed after RA which we can
use to determine when we can insert (last) on src regs on A7XX.
Passing VK-CTS: dEQP-VK.pipeline.*
Signed-off-by: Mark Collins <mark@igalia.com>
Co-Authored-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25077>
Floating point SEL.CMOD may flush denorms to zero. We don't have enough
information at this point in compilation to know whether or not it is
safe to remove that.
Integer SEL or SEL without a conditional modifier is just a fancy
MOV. Those are always safe to eliminate.
See also 3f782cdd25.
Fixes: fab92fa1cb ("i965/fs: Optimize SEL with the same sources into a MOV.")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34192>
The condition modifier on SEL means something completely different than
it means on MOV. On MOV it means to modify the flags based on the value
written to the destination. On SEL it means to compare the sources using
that mode and pick the result (i.e., as min() or max()) without
modifying the flags.
The resulting MOV should not have a condition modifier for the same
reason it (already) doesn't have a predicate. This bug was found by
inspection, so I added a unit test.
Fixes: fab92fa1cb ("i965/fs: Optimize SEL with the same sources into a MOV.")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34192>
Floating point SEL.CMOD may flush denorms to zero. We don't have enough
information at this point in compilation to know whether or not it is
safe to remove that.
Integer SEL or SEL without a conditional modifier is just a fancy
MOV. Those are always safe to eliminate.
See also 3f782cdd25.
Fixes: fab92fa1cb ("i965/fs: Optimize SEL with the same sources into a MOV.")
No shader-db changes on any Intel platform.
fossil-db:
All Intel platforms had similar results. (Lunar Lake shown)
Totals:
Instrs: 209903490 -> 209903492 (+0.00%)
Cycle count: 30546025224 -> 30546021980 (-0.00%); split: -0.00%, +0.00%
Max live registers: 65516231 -> 65516235 (+0.00%)
Totals from 2 (0.00% of 706657) affected shaders:
Instrs: 3197 -> 3199 (+0.06%)
Cycle count: 361650 -> 358406 (-0.90%); split: -10.05%, +9.15%
Max live registers: 300 -> 304 (+1.33%)
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34192>
The condition modifier on SEL means something completely different than
it means on MOV. On MOV it means to modify the flags based on the value
written to the destination. On SEL it means to compare the sources using
that mode and pick the result (i.e., as min() or max()) without
modifying the flags.
The resulting MOV should not have a condition modifier for the same
reason it (already) doesn't have a predicate. This bug was found by
inspection, so I added a unit test.
No shader-db or shader-db changes on any Intel platform.
Fixes: fab92fa1cb ("i965/fs: Optimize SEL with the same sources into a MOV.")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34192>
I was surprised this had any affect on Intel GPUs because we have been
unconditionally performing this optimization in the backend since June
2014.
Once that error is fixed (later in this MR), this change prevents a
couple dozen regressions in shader-db and around 90 regressions in
fossil-db. Many of the regressions in fossil-db were loss of SIMD32, and
that can be a big deal.
v2: Add 64-bit too. Suggested by Alyssa.
shader-db:
All Intel platforms had similar results. (Lunar Lake shown)
total instructions in shared programs: 16970141 -> 16970139 (<.01%)
instructions in affected programs: 40 -> 38 (-5.00%)
helped: 2 / HURT: 0
total cycles in shared programs: 914617580 -> 914617548 (<.01%)
cycles in affected programs: 3428 -> 3396 (-0.93%)
helped: 2 / HURT: 0
fossil-db:
All Intel platforms had similar results. (Lunar Lake shown)
Totals:
Cycle count: 30546028462 -> 30546025224 (-0.00%); split: -0.00%, +0.00%
Non SSA regs after NIR: 237017827 -> 237017731 (-0.00%)
Totals from 83 (0.01% of 706657) affected shaders:
Cycle count: 3042978 -> 3039740 (-0.11%); split: -0.13%, +0.02%
Non SSA regs after NIR: 78997 -> 78901 (-0.12%)
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34192>
Our strategy of covering the entire address space in buffer views
requires that we be able to create very large buffer views. The
pre-Maxwell texture unit doesn't allow for this.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34542>
If shared RA is used, it may have handled some phis. These are already
ignored by regular RA in handle_phi but were used before that in
potentially dangerous ways. More specifically, the interval of such phis
was accessed which may cause an out-of-bounds read since it was never
created. Fix this by skipping such phis earlier.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: c6a932d4b3 ("ir3/ra: handle phis with preferred regs first")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34503>
There have been multiple issues related to accessing intervals through
invalid register names. This usually results in a (difficult to
diagnose) out-of-bounds access. Wrap all the interval accesses in a
helper where we can assert that the name is in-bounds.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34503>
We can't have merged shaders where the first part is compiled using ACO
and the second part is compiled using LLVM.
Add ACO-specific main shader parts to fix that.
This happens when ACO is enabled for gfx12 streamout where GS can be paired
with a previous shader compiled by LLVM.
Fixes: 8ba718fb7d - radeonsi/gfx12: use ACO for streamout because it's faster
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34491>
TFU units is doing a readahead of 64 bytes. This is causing invalid read
MMU errors that can be observed at the nightly full Vulkan runs on
Broadcom devices.
04:13:59.969: [ 85.623205] v3d 1002000000.v3d: MMU error from client TLB (3) at 0x4869000, pte invalid
04:14:05.408: [ 91.019321] v3d 1002000000.v3d: MMU error from client TLB (3) at 0x5209000, pte invalid
04:14:05.413: [ 91.031662] v3d 1002000000.v3d: MMU error from client TLB (3) at 0x7521000, pte invalid
Although the log reports the TLB the real culprit is the TFU. A fix
to the kernel was submitted to fix AXI ID on V3D 4.2 and 7.1
So doing an over-allocation of 64-bytes at v3dv_AllocateMemory is
the simplest method to make these MMU errors itp disapear.
Running ./deqp-vk for an hour, we can see that ~%40 of allocations
would need an extra page (4096 bytes) to accomodate this 64 bytes
padding.
Fixes: ca330f7f04 ("v3dv: implement VK_EXT_memory_budget")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34475>
Read-only ZS optimization can only happen if the ZS tile buffer is not
written, which can only be known when the fixed-function settings is
set.
Change pan_earlyzs_get() to take an enum instead of a boolean and
differentiate ZS-read and ZS-read-with-readonly-optimization-allowed.
Fixes: 25a993731087 ("pan/earlyzs: Support the shader ZS read-only case and its optimization on v10+")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34480>
The setting of the clean_pixel_write_enable flag in pan_prepare_rt
was not consistent with the crc valid calculations in pan_emit_fbd.
This caused the crc_valid flag to not be accurate, causing transaction
elimination to fail.
Fixes: eac8f1d460 ("Revert "panfrost: Disable CRC by default"")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34408>
When texture_index and sampler_index are over 32, we can't really check
for them in a single 32-bit word. This happens among other things when
Panfrost uses preload shaders on v9 and later. Otherwise, we trigger
undefined behavior.
We're already doing this for textures in one case, let's be consistent.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34365>
In commit 292ac71a4a ("nir/lower_tex: handle deref casts"), we avoided
using texture_index when a texture instruction contained a variable
deref. There's no good reason why this should be done to some of the
lowering, but not all.
So let's fix up code-paths that were added after this change to do the
same.
The first two patches here crossed paths with the commit that introduced
texture_mask, so it's not strange that the change was missed. The last
one seems to have just copied what was done around it, propagating the
issue.
Fixes: 880b00dc59 ("nir/lower_tex: Add support for lowering YUYV formats")
Fixes: 1358d93650 ("nir/lower_tex: Add support for lowering Y41x formats")
Fixes: 65d6f5aed2 ("nir: add options to lower y_vu, yv_yu, yx_xvxu and xy_vxux")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34365>
Log all operations with the information used to decide whether they
are supported or unsupported. Include tensor data types, conv2d fused
activation and dilation parameters to debug output.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34472>
CP is very slow on GFX12 and parsing the packet header is the main
bottleneck. Using paired context regs reduce the number of packet
headers and it should be more optimal.
It doesn't seem worth when only one context reg is emitted (one packet
header and same number of DWORDS) or when consecutive context regs are
emitted (would increase the number of DWORDS).
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34421>
This patch does a couple of things to make CL integration with drivers
as seamless as possible:
- We pull in opencl-c.h and opencl-c-base.h to stop relying on system
headers.
- Parts of libcl.h are moved to new headers that are incomplete CL-safe
variants of libc headers.
- A couple of util headers are changed to remove now unnecessary
__OPENCL_VERSION__ guards and make more headers CL safe.
- Drivers now include src/compiler/libcl and use headers like
macros.h,u_math.h instead of libcl.h.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33576>
This allows us to create temporary VGRFs that are larger than
MAX_VGRF_SIZE(devinfo), which will be split eventually. They may not
be split on the initial pass, because we may need LOAD_PAYLOAD lowering,
copy propagation, and so on to occur first. So we allow registers to
exceed that size initially.
The "Register allocation relies on split_virtual_grfs()" assertion in
brw_reg_allocate.cpp still asserts that all VGRFs which reach the
register allocator have been properly split.
One case where this is useful is for vectorizing convergent block loads.
We create temporaries to splat the SIMD1 values out to SIMD(N), which
can lead to some very large temporaries. However, copy propagation and
so on ultimately eliminate these and they'll get split down to proper
sizes or elided entirely in the end.
(Note: both this and the prior commits from this merge request are
needed to close the linked issue.)
Cc: mesa-stable
Reviewed-by: Matt Turner <mattst88@gmail.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12324
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34461>
Post-RA scheduling doesn't use liveness analysis, so we continue using
MAX_VGRF_SIZE(devinfo). But for pre-RA scheduling, we now use
live->max_vgrf_size.
This helps get us to a place where we can emit arbitrarily large VGRFs
early on in compilation, but which will be split and cleaned up prior to
register allocation. It may also allocate smaller arrays in practice
since MAX_VGRF_SIZE(devinfo) assumes the worst case scenario for things
we actually could need to allocate.
Cc: mesa-stable
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34461>
We're already looking at this data to calculate the per-component
vars_from_vgrf[] and vgrf_from_vars[] mappings, so just record the
largest VGRF size while we're here. This will allow passes to size
arrays based on the actual size needed, rather than hardcoding some
fixed size. In many cases, MAX_VGRF_SIZE(devinfo) is larger than
necessary, because e.g. vec5 sparse sampling results aren't used.
Not hardcoding this means we can also temporarily handle very large
VGRFs which we know will be split eventually, without having to
increase the maximum which is ultimately used for RA classes.
Cc: mesa-stable
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34461>
VK_KHR_sampler_ycbcr_conversion is a dependency from the
VK_EXT_image_drm_format_modifier spec. panvk arch < 10 still
doesn't support it, so VK_EXT_image_drm_format_modifier should
not be exposed.
Otherwise, a Vulkan validation error is triggered for users of
VK_EXT_image_drm_format_modifier and it may cause applications
to fail to create a device.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34458>
This verifies that the requested allocation doesn't exceed the maximum
in cases where the size passed to `clSVMAlloc()` isn't a multiple of the
provided alignment. It also clamps the maximum allocation to `i32::MAX`,
which prevents overflowing `pipe_box`'s `width` field.
Both of these changes prevent possible undefined behavior on 32-bit
systems due to violation of `Layout` prerequisites.
v2: use safe layout creation for maintainability, add a few comments
v3: use Layout utils for aligned size calc, split out max alloc changes
v4: use `checked_compare()` for alloc/size comparison
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Cc: stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34166>
In order to enable higher MSAA modes, we're going to have to perform
some calculations on how to budget the (sometimes) limited tile-buffer
space.
Due to limited tilebuffer space, we need to prioritize a bit here.
First, we reserve space for 4x MSAA for all formats. Then we try to fit
8 color attachments into the tile-buffer. And then finally, we calculate
how many extra multi-sample buffers we can fit into the rest.
The reason we reserve 4x MSAA first, is that this is required by all
Vulkan versions. It also prevents us from regressing existing features.
Then we try to pick 8 color attachments next, because that's required by
Vulkan 1.4 as well as Vulkan Roadmap 2024 and D3D12. Vulkan Roadmap 2022
requires 7 as well.
This adds helpers that implements this, which can be used by both the
Gallium and the Vulkan driver. It's really benefitial if both of these
drivers prioritize the same way here.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33925>
We also have a budget for the tile size for depth-buffers. It's
currently hard to trigger issues with this than for color-buffers,
but this becomes important when we support larger MSAA counts.
We also need to take a bit of care for stencil-only attachments, because
they also count against a limit here. We really only care about the
sample counts here, because the stencil buffer budget is always a
quarter of the depth-buffer budget, and always uses a single byte per
sample.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33925>
There's two limitations we have to cater to:
1. The HW needs at least one render-target. We can disable write-back for
it, but it needs to allocate tile-buffer space for it.
2. The HW can't have "holes" in the render-targets.
In both of those cases, we already set up dummy RGBA8 UNORM as the format,
and disable write-back. But we forgot to take this into account when
calculating the tile buffer allocation.
This makes what we program the HW to do consistent, meaning we don't end
up smashing the tile-buffer space. We might be able to do something
better by adjusting how we program these buffers, but let's leave that
for later.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33925>
These GPUs had their tilebuffer sizes listed at twice their actual
values. While that still works, it ends up disabling pipelining in some
cases. This gives a significant performance hit, compared to using the
correct values.
But, it turns out to be hard or impossible to trigger at the moment, due
to the limited number of MSAA samples we support. Once that changes,
this is a lot easier to trigger, so let's fix it up.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33925>
This is an n-queen pattern, where no two values should be on the same
row or column. But this and the second to last element has the same y
component, and neither has the negative one.
Let's fix this up by setting the first value to the negative value. This
matches the D3D 16x sample pattern.
Fixes: a61fb62966 ("panfrost: Upload sample positions on device init")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33925>
Fixes two known issues:
- We did not lower invalid swizzles for IADD.v4s8, triggered in the CTS by
enabling uniformAndStorageBuffer8BitAccess and storageBuffer8BitAccess in
panvk.
- We did not lower invalid swizzles for IMUL.v4i8, triggered by
dEQP-VK.spirv_assembly.instruction.compute.mul_extended.(un)signed_8bit
on bifrost.
The old logic was missing several other instructions, so there may be
additional bugs that we don't know about.
There are no cases where the new behavior will keep swizzles that would
have been lowered previously, so this change should not introduce any
new bugs with valhall.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33416>
Primary reason to do this is to make codegen using the swizzle names in
bifrost/ISA.xml simpler. A secondary benefit is that dependent code can
now use the swizzle name that matches the context, making things a
little more readable.
We may want to consider giving widens separate values later, so that
va_lower_constants and bi_opt_constant_fold can fold them correctly, but
I don't know of current bugs caused by this.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33416>
Valhall supports all combinations of ftz/preserve denorm behavior
between FP16 and FP32 except FP16=ftz, FP32=preserve. Because of this,
we can't advertise independent denorm behavior.
Even with INDEPENDENCE_NONE, it is still possible for shaders to set
denorm behavior for one size and leave the other size unspecified.
Previously we were defaulting to preserve for any unspecified size, but
with FP16=ftz, we need to default unspecified FP32 to preserve.
When advertising INDEPENDENCE_NONE, the CTS checks that the
shaderDenormFlushToZeroFloat* and shaderDenormPreserveFloat* features
are equal for all sizes, so we need to advertise the same supported
denorm behavior for FP64 even though we don't support FP64 at all.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33660>
With vkCmdPipelineBarrier, it's possible to specify a barrier with
pipeline stages but without any memory barriers. These might not be
practical, but are legal Vulkan code.
Barriers like this are currently ignored in mesa, as we only convert
barriers with passed memory barriers into vkCmdPipelineBarrier2.
This commit adds handling of execution only barriers by converting them
into a memory barrier without access masks.
Fixes: 97f0a4494b ("vulkan: implement legacy entrypoints on top of VK_KHR_synchronization2")
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34187>
Fix the nginx cache snippets - I'd missed the file nesting somehow.
Tested on a debian:bookworm image with nginx-full installed, checked
that we could pull an arbitrary external site, as well as S3, as well
as GitLab artifacts.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34341>
Fixes some upcoming CTS tests for texture clears.
* some drivers will attempt to issue clears with zero range
and hit asserts/crashes (spec clarification for negative
values)
* fix error thrown with negative values to match spec
* fix cases for clearing generic compressed formats
* fix negative case of using color format while having
depth/stencil internalformat and vice versa
Cc: mesa-stable
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34428>
On Valhall we can optimize lower waits, which waits for both readers and
writers, into resource_waits which only wait for writers, allowing
threads accessing read-only resources to execute concurrently.
Let's use that on LD_TILE instructions so we can optmize the read-only
case.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32540>
In order to dynamically load the content of the tile buffer, we need
to know the target (color, depth or stencil) and the conversion to
apply. Let's define the load_input_attachment_{target,conv}_pan
intrinsics so we can dissociate the logic lowering input attachment
loads into load_converted_output_pan, and the part optimizing the shader
when input attachment map is passed at compile time.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32540>
We take the color attachment remapping into account when emitting
blend descriptors, and we make sure we re-emit those when this color
attachment map is dirty.
We also need to take the remapping into account when checking the
render targets written by the fragment shader, hence the addition of
a color_attachment_written_mask() helper.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32540>
Re-order things in panvk_deserialize_shader() to avoid declaring local
variables for stuff we feed the panvk_shader with. The only exception
is pan_shader_info, because we need to know the shader stage to call
vk_shader_zalloc(), which if part of pan_shader_info.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32540>
Some upcoming changes in the runtime will make it impossible to rely
on the pipeline or runtime information to know whether a fragment
shader has input attachments.
Instead we gather that information at compile time and store it in our
shader bind_map.
At runtime we check whether the fragment shader has input attachments
and whether those map to the runtime depth/stencil input attachments
to set the 3DSTATE_PS_EXTRA::PixelShaderKillsPixel.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: d2f7b6d5a7 ("anv: implement VK_KHR_dynamic_rendering_local_read")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32540>
For drivers using the render pass emulation provided by the
runtime, it's important to express the mapping between
depth/stencil/color attachments and input attachments using
VkRenderingInputAttachmentIndexInfoKHR, otherwise those drivers
have to special-case emulated render passes in their
CmdBeginRendering() implementation.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32540>
Panfrost supports pushing uniforms to hardware uniform registers (RMU/FAU for
Midgard/Bifrost respectively). Since OpenGL uniforms are lowered to UBO #0, it
does this with a pass that pushes UBOs. That's good!
The pass also pushes 'true' OpenGL UBOs, since they look the same in the backend
at this point. This is where the trouble comes in:
- True UBOs are allocated in GPU BOs, not CPU allocated buffers. That means it's
write-combine memory, which we cannot read from efficiently (at least
depending on coherency details that were never plumbed through panfrost.ko and
unlikely to be replumbed now that panthor is the new hot stuff). So, pushing
true UBOs reduces GPU overhead at the cost of tremendous CPU overhead. This is
dubious... When I benchmarked this on MT8192 in early 2023, this pushing
improved FPS in SuperTuxKart but hurt FPS in Dolphin.
- True UBOs can be written on the GPU. In OpenGL, we have batch tracking
infrastructure to sort this mess out in theory. What this means is that
pushing UBOs requires us to flush writers AND STALL at draw-time. If this is
ever hit, our performance is utterly trashed. But it gets worse.
- True UBOs can be written in the same batch that reads them. For example, we
could bind a buffer as a transform feedback buffer, do a draw with XFB, then
rebind as a UBO and do a draw reading. This is where we collapse -- our logic
will flush the writer, which is the same batch we were in the middle of
enqueueing a draw to. When we try to push words, we'll crash with theatrics.
This could be solved by smartening the batch tracking logic but it's not
trivial by any means.
So, pushing true UBOs on the CPU is broken and can hurt performance. Stop doing
it!
Long term, the solution will be to push on the GPU instead. This avoids all of
these issues. This can be done with a compute kernel or with CSF instructions.
The Vulkan driver will likely have to do this for performance, since pushing
UBOs from the CPU is utterly broken in Vulkan for the above reasons.
I have a branch somewhere doing this on v9 but I'm doing this on NIR time to
unblock a core change that was crashing piglit due to this pile of unsoundness.
Let's fix the correctness issues first, then someone can look at recovering
performance later when we're not blocking unrelated work.
Fixes corruption in Piglit test
gles-3.0-transform-feedback-uniform-buffer-object, which writes a UBO with
transform feedback. (I suspect the test still doesn't pass for the same reason
it's broken on other tilers. But that's a better place to be than oodles of
memory corruption.)
According to CI, fixes spec@arb_uniform_buffer_object@rendering{-dsa}-offset.
Cc: mesa-stable
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34193>
ss->info.ubo_mask includes the push+sysval UBO so if there's a user
UBO bound at the same index as the push+sysval UBO, without this
change we end up writing a descriptor for the user UBO at that index.
Fixes: 3b3cd59f ("panfrost: Launch transform feedback shaders")
Cc: mesa-stable
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34193>
For instance, this issue is triggered with "piglit/bin/fcc-blit-between-clears -auto -fbo":
Direct leak of 16400 byte(s) in 5 object(s) allocated from:
#0 0xb720689a in __interceptor_calloc (/usr/lib/libasan.so.6+0xb289a)
#1 0xaf10f896 in draw_create_fragment_shader ../src/gallium/auxiliary/draw/draw_fs.c:47
#2 0xaef64619 in i915_create_fs_state ../src/gallium/drivers/i915/i915_state.c:550
#3 0xae16a955 in ureg_create_shader ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:2194
#4 0xae17f45f in ureg_create_shader_with_so_and_destroy ../src/gallium/auxiliary/tgsi/tgsi_ureg.h:150
#5 0xae17f45f in ureg_create_shader_and_destroy ../src/gallium/auxiliary/tgsi/tgsi_ureg.h:159
#6 0xae17f45f in util_make_fs_blit_zs ../src/gallium/auxiliary/util/u_simple_shaders.c:365
#7 0xaf13300e in blitter_get_fs_texfetch_depth ../src/gallium/auxiliary/util/u_blitter.c:1157
#8 0xaf13300e in util_blitter_cache_all_shaders ../src/gallium/auxiliary/util/u_blitter.c:1322
#9 0xaef6b738 in i915_create_context ../src/gallium/drivers/i915/i915_context.c:233
#10 0xacb33c49 in st_api_create_context ../src/mesa/state_tracker/st_manager.c:986
#11 0xac845740 in dri_create_context ../src/gallium/frontends/dri/dri_context.c:178
#12 0xac854d97 in driCreateContextAttribs ../src/gallium/frontends/dri/dri_util.c:631
#13 0xb6ce79a3 in dri2_create_context_attribs ../src/glx/dri2_glx.c:240
#14 0xb6c9606f in dri_common_create_context ../src/glx/dri_common.c:665
#15 0xb6ca4f00 in CreateContext ../src/glx/glxcmds.c:322
#16 0xb6ca5c0b in glXCreateNewContext ../src/glx/glxcmds.c:1449
Fixes: 1a69b50b3b ("i915g: Fix point sprites.")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27570>
For instance, this issue is triggered with "piglit/bin/glx-multithread-texture -auto -fbo":
Direct leak of 256 byte(s) in 1 object(s) allocated from:
#0 0xb71eda62 in __interceptor_realloc (/usr/lib/libasan.so.6+0xb2a62)
#1 0xadd5a32f in tokens_expand ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:239
#2 0xadd5a32f in get_tokens ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:262
#3 0xadd62519 in copy_instructions ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:2079
#4 0xadd62519 in ureg_finalize ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:2129
#5 0xadd64bde in ureg_get_tokens ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:2206
#6 0xade377d0 in nir_to_tgsi_options ../src/gallium/auxiliary/nir/nir_to_tgsi.c:4043
#7 0xade3da63 in nir_to_tgsi ../src/gallium/auxiliary/nir/nir_to_tgsi.c:3831
#8 0xaeb606c9 in i915_create_vs_state ../src/gallium/drivers/i915/i915_state.c:662
#9 0xac781a2c in st_create_common_variant ../src/mesa/state_tracker/st_program.c:720
#10 0xac78e8a4 in st_get_common_variant ../src/mesa/state_tracker/st_program.c:773
#11 0xac78fc10 in st_precompile_shader_variant ../src/mesa/state_tracker/st_program.c:1259
#12 0xac78fc10 in st_finalize_program ../src/mesa/state_tracker/st_program.c:1345
#13 0xac790b1a in st_program_string_notify ../src/mesa/state_tracker/st_program.c:1378
#14 0xace457a9 in _mesa_get_fixed_func_vertex_program ../src/mesa/main/ffvertex_prog.c:1397
#15 0xac5ef8db in update_program ../src/mesa/main/state.c:281
#16 0xac5f0ece in _mesa_update_state_locked ../src/mesa/main/state.c:560
#17 0xac5f1653 in _mesa_update_state ../src/mesa/main/state.c:593
#18 0xacdf9fe2 in _mesa_DrawArrays ../src/mesa/main/draw.c:1403
Fixes: 487a493325 ("i915g: Add support for per-vertex point size.")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27570>
For instance, this issue is triggered with "piglit/bin/fcc-blit-between-clears -auto -fbo":
Direct leak of 836 byte(s) in 1 object(s) allocated from:
#0 0xb71eb6f2 in malloc (/usr/lib/libasan.so.6+0xb26f2)
#1 0xaefadc78 in slab_add_new_page ../src/util/slab.c:179
#2 0xaefadc78 in slab_alloc ../src/util/slab.c:221
#3 0xaef7d461 in i915_texture_transfer_map ../src/gallium/drivers/i915/i915_resource_texture.c:789
#4 0xac9e931e in pipe_texture_map ../src/gallium/auxiliary/util/u_inlines.h:555
#5 0xac9e931e in _mesa_map_renderbuffer ../src/mesa/main/renderbuffer.c:494
#6 0xad49c5e4 in readpixels_memcpy ../src/mesa/main/readpix.c:260
#7 0xad49c5e4 in _mesa_readpixels ../src/mesa/main/readpix.c:898
#8 0xad5d8cfe in st_ReadPixels ../src/mesa/state_tracker/st_cb_readpixels.c:568
#9 0xad4a0caf in read_pixels ../src/mesa/main/readpix.c:1199
#10 0xad4a0caf in _mesa_ReadnPixelsARB ../src/mesa/main/readpix.c:1216
#11 0xad4a155b in _mesa_ReadPixels ../src/mesa/main/readpix.c:1231
or "piglit/bin/fcc-read-to-pbo-after-clear -auto":
Direct leak of 772 byte(s) in 1 object(s) allocated from:
#0 0xb726b6f2 in malloc (/usr/lib/libasan.so.6+0xb26f2)
#1 0xaf0adc88 in slab_add_new_page ../src/util/slab.c:179
#2 0xaf0adc88 in slab_alloc ../src/util/slab.c:221
#3 0xaf07aad7 in i915_buffer_transfer_map ../src/gallium/drivers/i915/i915_resource_buffer.c:75
#4 0xad10de74 in pipe_buffer_map_range ../src/gallium/auxiliary/util/u_inlines.h:398
#5 0xad10de74 in _mesa_bufferobj_map_range ../src/mesa/main/bufferobj.c:499
#6 0xad5677ce in _mesa_map_pbo_dest ../src/mesa/main/pbo.c:308
#7 0xad59be3b in _mesa_readpixels ../src/mesa/main/readpix.c:894
#8 0xad6d8cfe in st_ReadPixels ../src/mesa/state_tracker/st_cb_readpixels.c:568
#9 0xad5a0caf in read_pixels ../src/mesa/main/readpix.c:1199
#10 0xad5a0caf in _mesa_ReadnPixelsARB ../src/mesa/main/readpix.c:1216
#11 0xad5a155b in _mesa_ReadPixels ../src/mesa/main/readpix.c:1231
Fixes: e7a73b75a0 ("gallium: switch drivers to the slab allocator in src/util")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27570>
If you suspect a workload is failing because it needs more memory, you
can set ANV_SYS_MEM_LIMIT=100 to give it all the memory available.
This could make, for example, certain games start working (it really
depends on how much RAM you have and how much the game wants).
If you suspect a workload is too resource hungry, you can try to limit
it with ANV_SYS_MEM_LIMIT=30 (or some other value) to see if it can
deal with the more restricted environment and behave accordingly.
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/28513>
"We paid for sixteen gigs of RAM, so we gonna use the whole damn
sixteen gigs of RAM!"
- My Mom
First, some history:
The Anv 50%-or-75% rule was originally added in 2017 by 060a6434ec
("anv: Advertise larger heap sizes"). When i915.ko started reporting
memory sizes in its ioctls, it didn't impose any restrictions: 100% of
SRAM was reported as available, so the restriction was in Mesa. When
xe.ko was introduced, it only reported 50% of the SRAM as available
through its ioctls, so commit b571ae6e7a ("intel: Make memory heaps
consistent between KMDs") adapted the code to not take an extra 25% of
the 50% that was already cut, and restricted i915.ko to 50% instead of
the 50%-or-75%. In Kernel commit d2d5f6d57884 ("drm/xe: Increase the
XE_PL_TT watermark"), xe.ko changed to reporting 100% of SRAM through
its ioctls, so we adapted Mesa to do the right thing depending on
which Kernel version was running.
While this was all happening, we were discussing about which behavior
was actually the best: restrict everything to 50% in order to avoid
issues when many things are running in parallel, or keep the
restriction only at 75% in order to allow high demanding workloads to
make full use of the hardware.
The way I see, if parallel applications are causing the system to run
out of resources, the user always has the option to kill applications
and use one thing at a time. On the other hand, if a single
application needs more than 50% of the SRAM and we don't allow it in
our heaps, the application will never work (unless, of course, the
user patches Mesa). So in this commit we go back to allowing
high-demanding applications to work by restoring the 50%-or-75% rule.
This commit is especially useful in systems with integrated graphics,
like LNL, where the option to upgrade RAM is not present.
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/28513>
Kernel commit d2d5f6d57884 ("drm/xe: Increase the XE_PL_TT watermark")
changed how xe.ko reportes memory: its ioctls now report 100% of the
system RAM as available. Since our policy is to report 50% of the SRAM
as available for the heaps, add some code to check the amount reported
by xe.ko against the amount reported by the system, then act
accordingly.
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/28513>
Before commit b571ae6e7a ("intel: Make memory heaps consistent
between KMDs"), we had the following policy for reporting Sytem RAM
memory sizes:
- For OpenGL, we reported the total available RAM.
- For Vulkan, we reported the total available RAM as:
- 50% of the total RAM if the total RAM was <= 4GB,
- 75% otherwise
- In addition, the Memory Budget (for VK_EXT_memory_budget) is 90%
of the "free" memory, which can be an extra 10% off of the 50% or
75%.
When xe.ko was added, one key difference was noted: while i915.ko
reported the "real" RAM memory sizes in its ioctls, xe.ko reported
only 50% of the system RAM as available. Because of that (and other
reasons, see this discussion on MR 28513), commit b571ae6e7a decided
to unify the behavior by changing the Anv i915.ko rule to "always 50%"
instead of "50% or 75%". This also changed the Iris rule to 50%
instead of 100%.
In my research, I couldn't find any reason why this restriction should
also apply to Iris, so here we revert back to handling these size
restrictions on Anv only.
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/28513>
This is necessary to appropriately uniformize the first component
access of a convergent vector. Without this, this is produced:
load_payload(16) %18:D, 0d, 0d NoMask group0
add(32) %21:F, %18+0.0:F, 0.5f
add(32) %22:F, %18+2.0<0>:F, 0.5f
This is the correct code:
load_payload(16) %18:D, 0d, 0d NoMask group0
add(32) %21:F, %18+0.0<0>:F, 0.5f
add(32) %22:F, %18+2.0<0>:F, 0.5f
Without 38b58e286f, the code generated was more incorrect, but happened
to work for this test case:
load_payload(16) %18:D, 0d, 0d NoMask group0
add(32) %21:F, %18+0.0<0>:F, 0.5f
add(32) %22:F, %18+0.4<0>:F, 0.5f
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 38b58e286f ("brw/nir: Fix source handling of nir_intrinsic_load_barycentric_at_offset")
Closes: #12969
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34427>
Indeed, this resource was assigned twice and was not properly freed.
For instance, this issue is triggered with:
"piglit/bin/glsl-fs-pointcoord -auto -fbo"
while setting GALLIUM_REFCNT_LOG=refcnt.log.
Fixes: 0278d1fa32 ("gallium: add unbind_num_trailing_slots to set_vertex_buffers")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27572>
Add conditioning before making driver calls to be
able to workaround some of the fatal errors, such
as unboxing issues during or after snapshot load.
This enables invalidating a host dispatcher based
on the application state. A default error will be
returned for vulkan calls.
Builtin expectation function is used to reduce
performance cost of the checks.
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34418>
Track pipeline layout creation and destroy calls
to cleanup them correctly on device teardown.
Pipeline layouts require delayed delete operations for
VulkanQueueSubmitWithCommands feature which modifies order
of commands and they need to stay valid during recording.
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34418>
This tells it to actually panic instead of unwinding and returning NULL.
I find myself commenting out the unwind code pretty frequently so I can
get GDB to break at the panic. This should help avoid that extra debug
step.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34435>
We need different Temps for each resume shader, because registers aren't
preserved across resume boundaries.
This was likely fine in practice because arg registers are the same for
each shader, but resulted in invalid IR and asserts.
Fixes crashes in Indiana Jones RT with assertions enabled on GFX8.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34114>
VUID-VkDescriptorSetAllocateInfo-pSetLayouts-09380 says that :
"If pSetLayouts[i] was created with an element of pBindingFlags
that includes VK_DESCRIPTOR_BINDING_VARIABLE_DESCRIPTOR_COUNT_BIT,
and VkDescriptorSetVariableDescriptorCountAllocateInfo is included
in the pNext chain, and
VkDescriptorSetVariableDescriptorCountAllocateInfo::descriptorSetCount
is not zero, then
VkDescriptorSetVariableDescriptorCountAllocateInfo::pDescriptorCounts[i]
must be less than or equal to
VkDescriptorSetLayoutBinding::descriptorCount for the corresponding
binding used to create pSetLayouts[i]"
But applications like are not following the spec. RADV doesn't apply
that limit and allocates if there is enough space in the pool. Let's
just do the same.
Note that this issue got resolved with a vkd3d-proton change :
a7ac1a7d2f
But since this change is deleting more code than it adds, might as
well go with it.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12185
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32305>
Created stand alone tool for sampling gfx data on regular
intervals. Tool has inner loop that performs sampling every N
useconds. Press any key to end sampling. Results will be dumped
when intel_monitor exits.
First application of intel_monitor will be to collect eu stall
data. Perhaps more applications can be added at a later date.
How to use:
0. Set sysctl dev.xe.observation_paranoid=0
1. Clean shader cache and launch gfx INTEL_DEBUG=shaders-lineno.
Redirect stderr to asm.txt.
2. When gfx app ready to monitor, begin capturing eustall data by
launching `intel_monitor -e > eustall.csv` in separate console.
3 When done collected, close intel_monitor by pressing any key.
4. Correlate eustall data in eustall.csv with shader instructions in
asm.txt by matching instruction offsets. Use data to determine which
instructions are stalling and why.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30142>
Xe2+ GPUs have support for eu stall sampling perf debug feature.
This feature allows driver to collect count and reasons for why
EUs are stalled on GPU. Stall data is cross referenced with ip
address within individual shaders so it is possible to know which
instructions in which shaders are generating stalls. This should
be a very useful feature for debugging performance of slow shaders.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30142>
Add support for dumping shader asm containing instruction line numbers
matching offsets within instruction state pool buffer. Offsets
should match values collected from eu stall sampling. This is
required for match eu stall data with individual shader instructions.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30142>
logicop_func=COPY is different from logicop_enable due to overriding blending.
maintain the info we need to implement properly. fixes
dEQP-VK.pipeline.shader_object_unlinked_binary.logic_op_na_formats.r32g32b32a32_sfloat.copy_blend
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34426>
This pulls out the logicop_func variable from the options struct, so we can
modify it in the next commit in a central place. It then refactors out the
format variable from the options struct since we end up duplicating
options->format[rt] a zillion times and passing in both an options struct and a
logicop func override is confusing so this will just make everything neater and
self-contained next commit.
no functional change.
Cc'd to make the next commit cherrypickable.
Cc: mesa-stable
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34426>
A few Android tools are based on/assume the datasource names
gpu.renderstages and gpu.counters. It is less effort to align with that
naming for Android builds than to chase down those tools and fix them,
not to mention account for new tools that may be created in the future.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34330>
This is the backport of eca57f85ee ("radeonsi: fix
gl_ClipDistance and gl_ClipVertex for points").
This change was tested on rv770, palm, barts and cayman. It
fixes 450 khr-gl tests and 64 khr-gles tests on evergreen
and cayman gpus. Here is the list:
spec/glsl-1.20/execution/clipping/vs-clip-vertex-primitives: fail pass
spec/glsl-1.30/execution/clipping/vs-clip-distance-primitives: fail pass
spec/glsl-1.50/execution/compatibility/clipping/gs-clip-vertex-primitives-points: fail pass
khr-gl(3[0-3]|4[0-5])/clip_distance/functional: fail pass
khr-gl(33|4[0-5])/cull_distance/functional_test_item_[0-8]_primitive_mode_points_max_culldist_[0-7]: fail pass
khr-gles3/clip_distance/functional: fail pass
khr-gles3/cull_distance/functional_test_item_[0-8]_primitive_mode_points_max_culldist_[0-7]: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34403>
This is the backport of 9c49550163. This rounding functionality
is available on all the gpus of the r600 family.
This change was tested on rv770, palm and cayman. This change fixes
at least the "turn-on-off" tests on all these gpus and it does not
add any regression. Here are the tests fixed on palm:
spec/ext_framebuffer_multisample/interpolation 6 centroid-edges: fail pass
spec/ext_framebuffer_multisample/interpolation 8 centroid-edges: fail pass
spec/ext_framebuffer_multisample/turn-on-off 2: fail pass
spec/ext_framebuffer_multisample/turn-on-off 4: fail pass
spec/ext_framebuffer_multisample/turn-on-off 6: fail pass
spec/ext_framebuffer_multisample/turn-on-off 8: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34403>
When executing CopyBufferToImage or CopyImage with multiple regions of
both depth and stencil aspects targeting an interleaved depth stencil
image, we must split the regions into one copy-command for each aspect
and add a barrier between them to avoid a write-after-write race.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Fixes: 5067921349 ("panvk: Switch to vk_meta")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34384>
The colorspace SRGB_NONLINEAR could be added twice when querying
available formats, leading to duplicate entries and VulkanCTS WSI test
failures.
Fixes: 789507c99c ("vulkan/wsi: implement the Wayland color management protocol")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34410>
Funny story... this is how regular b2f was implemented before Curro
implmented the `MOV dst:F -src:D` method 9 years ago (see
3ee2daf23d).
Eliminating the type conversion in the arithmetic operation enables the
next commit.
No shader-db or fossil-db changes on any Intel platform.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33931>
This commit prevents code quality regressions in the next
commit. Without this, some fragment shaders in Batman: Arkham Origins
have code like:
shr(8) g51<1>UW g1.28<1,8,0>UB 0x76543210V
...
and(8) g52<1>UD ~g51<8,8,1>UW 0x0001UW
...
add(8) g56<1>D -g52<8,8,1>D 1D
transformed to
shr(8) g51<1>UW g1.28<1,8,0>UB 0x76543210V
...
and(8) g52<1>UD ~g51<8,8,1>UW 0x0001UW
...
mov(8) g56<1>D -g52<8,8,1>D
...
and(8) g57<1>UD ~g56<8,8,1>D 0x00000001UD
Propagating through the negation allows the added MOV to be deleted.
shader-db:
All Intel platforms had simlar results. (Lunar Lake shown)
total instructions in shared programs: 16968020 -> 16968019 (<.01%)
instructions in affected programs: 281 -> 280 (-0.36%)
helped: 1 / HURT: 0
total cycles in shared programs: 914598850 -> 914598832 (<.01%)
cycles in affected programs: 5398 -> 5380 (-0.33%)
helped: 1 / HURT: 0
A single Blender vertex shader was affected.
fossil-db:
Lunar Lake, Tiger Lake, Ice Lake, and Skylake had similar results. (Lunar Lake shown)
Totals:
Instrs: 209894650 -> 209894651 (+0.00%)
Cycle count: 30545958586 -> 30545952860 (-0.00%)
Totals from 2 (0.00% of 706657) affected shaders:
Instrs: 3582 -> 3583 (+0.03%)
Cycle count: 1875100 -> 1869374 (-0.31%)
Meteor Lake and DG2 had similar results. (Meteor Lake shown)
Totals:
Subgroup size: 9906400 -> 9906416 (+0.00%)
Totals from 2 (0.00% of 805770) affected shaders:
Subgroup size: 16 -> 32 (+100.00%)
Two compute shaders in Hogwarts Legacy were affected.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33931>
This is mostly defensive. If a convergent value ever ended up as a
source of a DDX or DDY, the eu_emit code will ignore the stride. This
will result in bad code being generated.
No shader-db or fossil-db changes on any Intel platform.
v2: DDX and DDY will always be float, but brw_imm_for_type only works
with integer types.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Suggested-by: Ken
Fixes: d5d7ae22ae ("brw/nir: Fix up handling of sources that might be convergent vectors")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33007>
The vast majority of the callers want channel = 0. During the
development process, using this default parameter value saved a lot of
pain in rebasing. However, it seems to be more trouble than it's worth.
Issue #12464 occurred because LNL was merged while this code was in
review. As a result, one caller of get_nir_src that wanted channel = -1
was not inspected closely, and it got the default channel = 0 instead.
To prevent this happening in the future (with possible branches still
yet to be merged, for example), remove the default parameter. This will
force the inspection of any callers that don't have an explicit channel
parameter. Hopefully that will prevent more problems.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33007>
The source of nir_intrinsic_load_barycentric_at_offset is a vector, so
-1 should be passed to get_nir_src. This is also done for texture
sampling intrinsics.
I skimmed the other user of get_nir_src, and I believe they are
correct. This one was just missed as LNL support landed an many, many
rebases of the original MR occurred.
v2: Fix another get_nir_src call. Suggested by Lionel.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [v1]
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Fixes: d5d7ae22ae ("brw/nir: Fix up handling of sources that might be convergent vectors")
Closes: #12464
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33007>
Bifrost keeps a cache of information about buffers being
used as indices. Unfortunately, it was not keeping information
about the size of the indices (probably because this rarely
changes). If a program deliberately re-interprets the indices
as a different type (e.g. UNSIGNED_INT instead of UNSIGNED_SHORT)
then we will use incorrect values from the cache. This actually
showed up in a test program we were running.
Fix by saving the index size in the cache key.
Cc: mesa-stable
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34011>
This issue seems to be specific to textureGather() which could
fail when processing some surfaces. These surfaces are configured
with non-standard one and zero swizzles. The gpu doesn't support
this very specific setup with all the possible hardware formats.
This change selects a compatible configuration when this is
possible.
This change was tested on palm, barts and cayman. This change
fixes the 216 remaining arb_texture_gather tests:
spec/arb_texture_gather/texturegather/.*-zero-.*: fail pass
spec/arb_texture_gather/texturegather/.*-one-.*: fail pass
spec/arb_texture_gather/texturegatheroffset/.*-zero-.*: fail pass
spec/arb_texture_gather/texturegatheroffset/.*-one-.*: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Acked-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34293>
After ca09c173f6, util_blitter_clear_render_target() requires
a call to util_blitter_save_fragment_constant_buffer_slot().
The r600 implementation was using the same sequence with
util_blitter_clear_depth_stencil() which does not need this
call. This was the cause of the refcnt imbalance.
For instance, this issue is triggered with:
"piglit/bin/ext_clear_texture-stencil -auto -fbo"
while setting GALLIUM_REFCNT_LOG=refcnt.log.
Fixes: ca09c173f6 ("gallium/u_blitter: remove UTIL_BLITTER_ATTRIB_COLOR, use a constant buffer")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34292>
The vtn_ssa_value for a cmat is not backed by a nir_def, but by a nir_variable, so
can't be used directly when calling a function. In most cases the cmat is used by
reference so code will take the value of deref for it (which is a `nir_def`).
When passing a cooperative matrix to a function by value, let the caller pass the deref
value, and the callee copy to a new local variable from that deref.
Fixes: b98f87612b ("spirv: Implement SPV_KHR_cooperative_matrix")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34364>
The `meson configure` command is used in `.gitlab-ci/meson/build.sh` to
show a summary of the build configuration, however when the script is
re-used locally on systems when there is a pager the commands blocks
for user input, which can be annoying.
Pass the `--no-pager` option to `meson configure`, so that it never
blocks for user input.
This does not change the behavior in the CI, it just makes the script run
uninterrupted also on local invocations.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34289>
The cid loop in the previous implementation stopped at n_counters for a
given category, even though cid is a global id that does not start
counting from zero at the beginning of each category. As a result, we
missed most of the counters outside of the first category.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Fixes: 513d1baaea ("pps: Panfrost pps driver")
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34202>
Starting with Rust 1.83 this benign warning is show when compiling the pest dependency:
```
warning: elided lifetime has a name
--> pest/src/iterators/pairs.rs:330:70
|
89 | impl<'i, R: RuleType> Pairs<'i, R> {
| -- lifetime `'i` declared here
...
330 | ) -> Filter<FlatPairs<'i, R>, impl FnMut(&Pair<'i, R>) -> bool + '_> {
| ^^ this elided lifetime gets resolved as `'i`
|
= note: `#[warn(elided_named_lifetimes)]` on by default
```
Meson, at least as of version 1.7.0, unfortunately does not suppress warnings originating in dependencies.
Upstream has resolved the warning in 2.8.0, so update to that.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34368>
__LINE__ can be inconsistent when using different compilers. This patch
changes the test runner to do a simple string find/replace of the test
source file instead of looking for the line where the reference string
starts.
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33980>
There is a special address defined in kernel from which ALWAYSON
counter could be read.
Blob uses this sequence to read it:
getone #l15
mov.s32s32 r2.y, -4096
mov.s32s32 r2.z, 131071
(rpt5)nop
ldg.u32 r2.w, g[r2.y], 1
ldg.u32 r2.y, g[r2.y+4], 1
(sy)(ss)mov.s32s32 r48.x, (last)r2.w
mov.s32s32 r48.y, (last)r2.y
l15:
Passes:
dEQP-VK.glsl.shader_clock.*
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29860>
The temporary syncobj created in the fast path of kgsl_queue_submit was
not being destroyed, and potentially being assigned to multiple syncobjs
without being properly duplicated. This could lead to a use-after-free
or double-free since multiple syncobjs could be assigned the same FD.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34328>
This reverts commit 0342d34bdb which
introduced a regression in the Turnip's KGSL backend, causing various
sync issues since KGSL doesn't advance the GPU timeline when a submit
without cmdbufs is made. A comment explaining the issue was added to the
code, and the fast path is reintroduced.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34328>
Using constant-size array instead of variable-length array is preferred
due several issues with the latter.
Particularly, for this case using VLA generates several warnings by
static analyzer: passed-by-value struct argument contains uninitialized
data (e.g., field: 'file').
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34050>
Most compositors work with damage in the buffer local coordinate space.
This change spares the compositors some work converting the provided
INT32_MAX x INT32_MAX damage region to the buffer local coordinate
space. It has no significant performance impact, but it'd still be nice
to use wl_surface_damage_buffer() if possible.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34227>
Most compositors work with damage in the buffer local coordinate space.
This change spares the compositors some work converting the provided
INT32_MAX x INT32_MAX damage region to the buffer local coordinate
space. It has no significant performance impact, but it'd still be nice
to use wl_surface_damage_buffer() if possible.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34227>
When running under DXVK or vkd3d, the texture coordinate rounding behavior
should match D3D expectations. On Adreno, this behavior can be toggled
through the SP_TP_MODE_CNTL register.
A driconf-based option is introduced to help set the relevant register flag
that enables this behavior.
This fixes the cause of test_sampler_rounding test case failure in vkd3d on
Turnip's side, but a small change in vkd3d is also required, so the test
failure expectation isn't removed yet.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33987>
This commit makes radv use vk_video_derive_h265_scaling_list, which properly
applies default scaling lists whenever they're needed. It also simplifies
update_h265_scaling function into a simple memcpy. The firmware interface
struct and Vulkan's StdVideoH265ScalingLists struct both have identical memory
layouts, so it's not neccessary divide it into multiple copies with offsets.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34096>
H265 specification defines default scaling lists to use whenever scaling lists
are not specified in neither sps nor pps. Currently drivers ignore this
requirement and set the lists to zero. This commits adds a helper function
vk_video_derive_h265_scaling_list (similar to its h264 counterpart) that
selects either sps or pps lists and falls back to default values if neither
were specified. The default values were taken from ITU-T H265 specification
(revision 8), section 7.4.5.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34096>
The intervening_saturating_copy test is removed. The defs version of the
pass does not handle this case. It should not occur often in practice
anyway. Copy propagation and brw_nir_opt_fsat should prevent this
scenario from happening.
No shader-db changes on any Intel platform.
fossil-db:
All Intel platforms had similar results. (Lunar Lake shown)
Totals:
Instrs: 212677275 -> 212677278 (+0.00%)
Cycle count: 30466062848 -> 30466056040 (-0.00%)
Totals from 1 (0.00% of 706300) affected shaders:
Instrs: 1343 -> 1346 (+0.22%)
Cycle count: 411664 -> 404856 (-1.65%)
v2: Stop counting ip. The non-defs part of the pass was the only thing
that used it.
v3: Also delete "if (block != def->block) continue;" code. I noticed
this while working on some other changes to this function. It's the last
thing in the loop, so it's totally useless. Delete some other spurious
continues too.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> [v2]
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31497>
v2: Add support for WE_all instructions... this already just worked, so
I only had to delete the check and the FINISHME comment.
v3: Use logic more like def_analysis::update_for_reads to determine when
to not insert LOAD_REG instructions. Based on a suggestion by Ken.
v4: Eliminate "store" from all the names since STORE_REG does not exist
anymore. Fold insert_load_reg into brw_insert_load_reg. Elminate extra
call to s.def_analysis.require() after progress. Pull a loop-invariant
check out of the inst->srouces loop. Drop call to
brw_opt_split_virtual_grfs after lowering load_reg. All suggested by
Caio.
v5: Assert that LOAD_REG doesn't already exist in
brw_insert_load_reg. Update comment before fully_defines. Both
suggested by Caio.
v6: Don't explicitly special-case SHADER_OPCODE_MEMORY_STORE_LOGICAL.
Move the inst->dst.file != VGRF check earlier to avoid the loop over
sources. Both suggested by Ken. Move the call the brw_insert_load_reg
a little bit later, and explain why it's at that location. Suggested
by Caio.
v7: Many changes to the for-each-source loop in brw_insert_load_reg.
Removes incorrect multiplication of s.alloc.sizes with reg_unit. Adds
checks for matching SIMD size and NoMask in the search for pre-existing
LOAD_REG of same value.
v8: Add some unit tests. Suggested by Caio.
shader-db:
Lunar Lake
total instructions in shared programs: 16923237 -> 16921895 (<.01%)
instructions in affected programs: 450565 -> 449223 (-0.30%)
helped: 251 / HURT: 377
total cycles in shared programs: 910428418 -> 889920590 (-2.25%)
cycles in affected programs: 719248184 -> 698740356 (-2.85%)
helped: 9076 / HURT: 9082
total fills in shared programs: 2242 -> 2218 (-1.07%)
fills in affected programs: 116 -> 92 (-20.69%)
helped: 2 / HURT: 0
total sends in shared programs: 848635 -> 848421 (-0.03%)
sends in affected programs: 810 -> 596 (-26.42%)
helped: 10 / HURT: 0
LOST: 82
GAINED: 78
Meteor Lake and DG2 had similar results. (Meteor Lake shown)
total instructions in shared programs: 19875784 -> 19871694 (-0.02%)
instructions in affected programs: 1050091 -> 1046001 (-0.39%)
helped: 251 / HURT: 2403
total cycles in shared programs: 905328238 -> 882446458 (-2.53%)
cycles in affected programs: 682736344 -> 659854564 (-3.35%)
helped: 7869 / HURT: 7911
total spills in shared programs: 5512 -> 5032 (-8.71%)
spills in affected programs: 1830 -> 1350 (-26.23%)
helped: 8 / HURT: 0
total fills in shared programs: 5648 -> 4782 (-15.33%)
fills in affected programs: 3312 -> 2446 (-26.15%)
helped: 8 / HURT: 0
total sends in shared programs: 1032942 -> 1032722 (-0.02%)
sends in affected programs: 572 -> 352 (-38.46%)
helped: 10 / HURT: 0
LOST: 138
GAINED: 53
Tiger Lake
total instructions in shared programs: 19711930 -> 19715591 (0.02%)
instructions in affected programs: 1040623 -> 1044284 (0.35%)
helped: 317 / HURT: 2474
total cycles in shared programs: 862988990 -> 860573870 (-0.28%)
cycles in affected programs: 612392461 -> 609977341 (-0.39%)
helped: 7447 / HURT: 7686
total sends in shared programs: 1034763 -> 1034555 (-0.02%)
sends in affected programs: 784 -> 576 (-26.53%)
helped: 8 / HURT: 0
LOST: 56
GAINED: 143
Ice Lake and Skylake had similar results. (Ice Lake shown)
total instructions in shared programs: 20545461 -> 20545220 (<.01%)
instructions in affected programs: 422405 -> 422164 (-0.06%)
helped: 180 / HURT: 459
total cycles in shared programs: 872697345 -> 866874523 (-0.67%)
cycles in affected programs: 573117917 -> 567295095 (-1.02%)
helped: 6783 / HURT: 6980
total spills in shared programs: 4335 -> 4336 (0.02%)
spills in affected programs: 90 -> 91 (1.11%)
helped: 1 / HURT: 2
total fills in shared programs: 4194 -> 4196 (0.05%)
fills in affected programs: 463 -> 465 (0.43%)
helped: 1 / HURT: 2
total sends in shared programs: 1079446 -> 1079238 (-0.02%)
sends in affected programs: 784 -> 576 (-26.53%)
helped: 8 / HURT: 0
LOST: 117
GAINED: 37
fossil-db:
All Intel platforms had similar results. (Lunar Lake shown)
Totals:
Instrs: 209708136 -> 209695617 (-0.01%); split: -0.02%, +0.01%
Send messages: 10927753 -> 10927640 (-0.00%)
Cycle count: 30540172048 -> 30427084732 (-0.37%); split: -0.99%, +0.62%
Spill count: 511621 -> 510932 (-0.13%); split: -0.22%, +0.08%
Fill count: 621166 -> 618440 (-0.44%); split: -0.56%, +0.12%
Scratch Memory Size: 35574784 -> 35648512 (+0.21%); split: -0.06%, +0.26%
Max live registers: 65453860 -> 65453140 (-0.00%); split: -0.00%, +0.00%
Non SSA regs after NIR: 75374990 -> 35195764 (-53.31%)
Totals from 503284 (71.25% of 706391) affected shaders:
Instrs: 180203778 -> 180191259 (-0.01%); split: -0.02%, +0.01%
Send messages: 9699732 -> 9699619 (-0.00%)
Cycle count: 30080349592 -> 29967262276 (-0.38%); split: -1.01%, +0.63%
Spill count: 511584 -> 510895 (-0.13%); split: -0.22%, +0.08%
Fill count: 621120 -> 618394 (-0.44%); split: -0.56%, +0.12%
Scratch Memory Size: 35443712 -> 35517440 (+0.21%); split: -0.06%, +0.27%
Max live registers: 52566092 -> 52565372 (-0.00%); split: -0.01%, +0.00%
Non SSA regs after NIR: 70110949 -> 29931723 (-57.31%)
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31497>
This prevents assertion failures in brw_eu_emit in a later commit in
this MR. Even though they have not been previously observed, these
assertion failures could happen even without that commit.
No shader-db or fossil-db changes on any Intel platform.
Fixes: 04e1783278 ("brw: Call brw_fs_opt_algebraic less often")
v2: Add SHUFFLE. Suggested by Ken. Fixed indentation.
v3: Update BROADCAST exec_size after rebasing on "brw/build: Use SIMD8
temporaries in emit_uniformize".
v4: Explain why munging the exec_size is correct.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31497>
The changes to try_copy_propagate will be removed later in the series.
v2: Fix up some comments to note that offset != 0 is allowed only when
stride == 0. Apply same offset=0 restriction in try_copy_propagate_def
too. Allow copy propagation if the source is either a def or
UNIFORM. Don't copy prop a load_reg through a non-def value.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31497>
load_reg is something like load_payload except it has a single
source. It copies the entire source to the destination. Its purpose is
to convert a non-SSA VGRF into an SSA value. This copy is marked as
volatile so that it will act as a scheduling barrier.
v2: Fix some typos in the commit message. Eliminate the
brw_builder::LOAD_REG overload that returns a brw_inst*. This is
unlikely to ever be used. Add some checks to brw_validate. All
suggested by Caio.
v3: Force the source and destination types of the LOAD_REG to by
integer. This will (eventually) simplify the creating of unit tests for
the pass that adds LOAD_REG instructions.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31497>
v2: Move to immediately before the main optimization loop. Most
importantly, this is after the first call to DCE.
fossil-db:
All Intel platforms had similar results. (Lunar Lake shown)
Totals:
Non SSA regs after NIR: 237045283 -> 100183460 (-57.74%); split: -58.12%, +0.39%
Totals from 701423 (99.26% of 706657) affected shaders:
Non SSA regs after NIR: 236868848 -> 100007025 (-57.78%); split: -58.17%, +0.39%
Suggested-by: Ken
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31497>
device-select-layer needs to obtain the display server's preferred
display device, and has so far relied on wl_drm for this. wl_drm is
superseded by linux-dmabuf with some Wayland servers having dropped
support for wl_drm entirely.
Implement linux-dmabuf as preferred mechanism for obtaining the main
device, with wl_drm support retained as a fallback for now.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34219>
Starting with sRGB meant we would refcount to -1 if an application
chooses PASS_THROUGH. Instead, just initialize with PASS_THROUGH so the
initial refcount of 0 reflects reality.
Previously, we would segfault if an application chose PASS_THROUGH at
swapchain initialization then switched to a color managed colorspace
later in the runtime, because we would increment refcount from -1 -> 0
and this would result in not creating a new color managed surface.
Fixes: 789507c99c ("vulkan/wsi: implement the Wayland color management protocol")
Signed-off-by: llyyr <llyyr.public@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34353>
Calling dri2_x11_setup_swap_interval with swap_available = false
sets the min/max/default swap interval values to zero.
EGL_MIN/MAX_SWAP_INTERVAL is always reported as 0 and the interval
value set by eglSwapInterval gets clamped to 0.
Set swap_available to true before calling dri2_x11_setup_swap_interval,
as was done before.
Fixes: c00701c83a ("egl/x11: unify swrast/kopper/dri3 paths a bit")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34235>
We need to remember which streamout buffers and streams were enabled,
even if the shader doesn't actually write any outputs to them,
because the API requires that we count vertices created by this shader
towards queries against those streams.
That information can be gathered by nir_gather_xfb_info_with_varyings
from the original NIR I/O variables that we get from the frontend,
but it isn't included in any intrinsics so would be otherwise lost here.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34317>
On i686, where VK_USE_64_BIT_PTR_DEFINES is unset and Vulkan handles are
represented as 64-bit integers instead, the code used the wrong format
specifier, causing a build error.
Fixes: 7fb31361f4 ("Handle external fences in vkGetFenceStatus()")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34124>
Per spec, logic operations between fragment values and color attachments
should be disabled when attachments are using float or sRGB formats.
Regardless of attachment's format, enabled logic operations should keep
blending disabled.
Fixes: dEQP-VK.pipeline.*.logic_op_na_formats.*
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34212>
Context flushes can be caused by all kinds of operations that aren't
obvious to a GL API user. As those are quite heavy-weight operations
it is nice to have some insight into how many of those are happening
per frame. Add a sw query to make this information easily accessible.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34350>
Shared RA might insert new defs to be handled by regular RA (e.g.,
shared spills). However, their interval offsets were not initialized
which caused their intervals to sometimes be mistakenly matched with
those containing offset 0. Fix this by calling index_merge_sets after
shared RA and modifying that function to only index new defs in that
case.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: fa22b0901a ("ir3/ra: Add specialized shared register RA/spilling")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33319>
shpe is a bit of a special instruction: it's not really a terminator
(i.e., it does not perform a jump) but it does have to stay at the end
of its block. Up to now, we tried to enforce this by creating const
write barriers on shpe; the assumption being that everything that
happens in the preamble ends in a write to the const file so shpe stays
at the end. Alas, it turns out this is not true: things like sampler
prefetches do not write the const file and nothing was preventing those
from being scheduled after shpe.
Instead of trying to create even more barrier dependencies, fix this by
making shpe a terminator. Both sched and postsched treat terminators
specially to make sure they always stay at the end of their block.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34290>
In order to implement FDM offset, we will have to offset the viewport
and scissor in the binning pass. In order to do this, we have to pass a
bin with nonsensical negative offsets to the patchpoint function, which
would result in asserts when patching the load/store sequences. But we
don't really need to patch these anyways as they are unused during
binning, so add the ability to skip them when binning. FS params and
some implementations of CmdClearAttachments (that don't contribute to
visibility) can similarly be skipped.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33500>
For FDM offset, we will need to expand the number of bins by 1, which
can change how pipes are allocated. We don't necessarily know whether
FDM offset will be used when creating the VkFramebuffer, so we'll have
to create two different configs when FDM is enabled. Split out the parts
that are affected by the number of bins into a separate "VSC config"
struct that will be duplicated with FDM offset.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33500>
nir_opt_vectorize could replace swizzled movs with vectorized movs in a
different block. If this happens with swizzled movs in a then block, it
could leave this block empty. ir3 assumes only the else block can be
empty (e.g., when lowering predicates) so make sure ifs are in that
canonical form again.
This fixes empty predication blocks in some shaders, for example:
predt
predf
...
prede
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34272>
At least on all a6xx/a7xx, mad.f32 and mad.f16 are not fused. This means
that when the sources of a NIR ffma are all uniform we can split it in
two to execute it on the scalar ALU. This is important to reduce
register pressure and make more preambles executed early.
On fossil-db the statistics are mostly a wash as expected, but with
early preambles increasing dramatically:
Totals:
MaxWaves: 2249180 -> 2249230 (+0.00%); split: +0.01%, -0.01%
Instrs: 49668884 -> 49662951 (-0.01%); split: -0.12%, +0.11%
CodeSize: 103662656 -> 103831154 (+0.16%); split: -0.22%, +0.38%
NOPs: 8502571 -> 8495568 (-0.08%); split: -0.61%, +0.53%
MOVs: 1554442 -> 1538804 (-1.01%); split: -2.01%, +1.01%
Full: 1820906 -> 1814292 (-0.36%); split: -0.39%, +0.03%
(ss): 1168628 -> 1165868 (-0.24%); split: -1.01%, +0.78%
(sy): 616751 -> 616521 (-0.04%); split: -0.52%, +0.49%
(ss)-stall: 4384397 -> 4361662 (-0.52%); split: -1.44%, +0.93%
(sy)-stall: 17850227 -> 17858949 (+0.05%); split: -0.58%, +0.63%
Early-preamble: 102262 -> 115702 (+13.14%)
Cat0: 9375820 -> 9367978 (-0.08%); split: -0.57%, +0.48%
Cat1: 2470212 -> 2454318 (-0.64%); split: -1.28%, +0.64%
Cat2: 18673655 -> 18707106 (+0.18%)
Cat3: 14227810 -> 14211106 (-0.12%)
Cat5: 1424184 -> 1424150 (-0.00%)
Cat7: 1404718 -> 1405808 (+0.08%); split: -0.39%, +0.47%
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34115>
There are three copies of this function, all of them have the same
memory leak in them. Instead of fixing them one by one, just use a
common implementation for all three, since they already all have a
shared helper lib.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34118>
With "classic" renderpasses, the VkFramebuffer's layerCount must be 1 if
multiview is enabled. We accidentally rely on this to not disable GMEM
for multiview, and possibly for other things too. Apparently the dynamic
rendering equivalent, VkRenderingInfo::layerCount, can be anything when
multiview is enabled, and some CTS tests set it to the number of views.
Sanitize it when constructing the internal framebuffer for dynamic
rendering.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34080>
We were a bit too conservative and fully disabled LRZ for when stencil
or blending were involved. There is no need to fully disable LRZ
in those cases, only LRZ writes should be disabled.
The final rules are:
LRZ is DISABLED until depth attachment is cleared when:
- Depth Write + changing direction of depth test
e.g. from OP_GREATER to OP_LESS;
- Depth Write + OP_ALWAYS or OP_NOT_EQUAL;
- Clearing depth with vkCmdClearAttachments;
- Depth image is a target of blit commands.
- (pre-a650) Not clearing depth attachment with LOAD_OP_CLEAR;
- (pre-a650) Using secondary command buffers;
LRZ WRITE is DISABLED until depth attachment is cleared when:
- Depth Write + blending (color blend, logic ops, partial color mask, etc.);
- Fragment may be killed by stencil;
LRZ is disabled for CURRENT draw when:
- Fragment shader side-effects (writing to SSBOs, atomic operations, etc);
- Fragment shader writes depth or stencil;
LRZ WRITE is DISABLED (via LATE_Z) for CURRENT draw when:
- Fragment may be via killed alpha-to-coverage, discard, sample coverage;
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33851>
This adds the latency information provided by NVIDIA. This is copied
from excel spreadsheets provided to Red Hat.
This fully passes CTS on Turing TU104 with no regressions.
I'm sure future use of some instructions like IMAD may require some
changes to this, but it should be functionally complete.
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33573>
Delays greater than 15 needs to be encoded into a nop following the
instruction. These delays will start to happen when we add accurate
latency handling and with certain instructions.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33573>
Otherwise we schedule this sort of thing wrong,
r0 = iadd3 r0 c[0x0][0x0] rZ
r0 = shf.l.w.i32 r0 rZ 0x2
r0 p0 = iadd3 r0 c[0x1][0x0] rZ
since raw latencies are more important than waw, but we go do a
waw for the first two instructions instead of a raw which is correct.
Fixes: 2d4e445099 ("nak/calc_instr_deps: Rewrite calc_delays() again")
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33573>
When we are using compute resolve, we can get
values the CTS does not expect due to the value
we end up writing for UNORM in
`nir_image_deref_store`.
Make the compute resolve rounding path match with
the output of the fragment shader resolve path,
by going through the same FP16 RTZ conversion as
we do for UNORM/SNORM formats.
This is why VK_EXT_sample_locations CTS was
failing on > GFX9.
On <= GFX9, I am assuming we are falling back to
RESOLVE_FRAGMENT, due to DCC stuff, which is why
it works there.
I tested a handful of images from the Vulkan CTS
for the sample locations and resolve tests for
diff UNORM formats from the qpa file forcing
FRAGMENT and with this change.
With this change, we now match on the compute
resolve path the same sha for the ones I compared
with ImageMagick `identify`.
CTS passes for: *resolve*, *image_clearing* and
*sample_locations* on RX 7900XTX.
Signed-off-by: Autumn Ashton <misyl@froggi.es>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28237>
This is based on Timur Kristof's code, but there are a lot of differences.
The idea is that it doesn't just compute an intersection between a point
and a triangle. It computes the *distance* between a point and a triangle
and it does so in screen space. It accurately takes the subpixel precision
of the rasterizer into account, so that it works optimally at all
resolutions, all MSAA modes, and all quant modes.
The distance computation is only approximated because it only considers
the infinite lines going through triangle edges. However, it seems to be
more than sufficient in practice because the existing rounding-based small
prim culling compensates for it.
The performance improvement is up to 10% in some geometry-bound tests,
though targeted microbenchmarks can show a lot more than that.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33361>
Migrate the panfrost-g52-vk job to mt8186-corsola-steelix-sku131072, a
new device in LAVA. This DUT is faster than the Khadas VIM3 device it
replaces, and since more of these devices are available in LAVA, reduce
the DEQP_FRACTION and increase the parallelism for the pre-merge job.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33996>
We currently just assume that textureCompressionETC2 and
textureCompressionASTC_LDR are always supported. And while that's true
for all the G52s, G610s abd G310s we've seen out in the wild, it's not
guaranteed to be true. An SoC vendor might disable support for one of
these formats.
So let's check properly, just for good measure.
Fixes: d970fe2e9d ("panfrost: Add a Vulkan driver for Midgard/Bifrost GPUs")
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34206>
The panfrost_emit_plane function expects an array, and Coverity
complains about passing a pointer instead. Yeah, that's a bit nit-picky,
but it's easy enough to use an actual array here instead of trying to
fudge it.
This should be a non-functional change.
CID: 1636773, 1636744
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34156>
Enforce a default job timeout of 1 second, to make jobs which don't
explicitly specify a timeout insta-fail, rather than potentially hanging
around for an hour.
Container builds get the full hour as they can run long and are not run
in pre-merge context, and LAVA jobs also get the full hour as they have
multiple internal timeout mechanisms which aim to fast-fail jobs once
they actually start. However, as they just queue jobs to an external
host (shared with other projects like KernelCI), these timeouts aren't
reflected into the GitLab CI definitions.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34280>
quick_shader is for some reason now excruciatingly slow on the Microsoft
runners, but fine on the GStreamer runners. Until we can figure out why
this is happening - 27min runtimes instead of 3min - just keep them over
there.
Dozen is miraculously unaffected.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34280>
Most of our build jobs have had a timeout of 1 hour since 6425b6e3d4,
which pushed the timeout as high as possible to allow for LTO building
taking forever. Since then, we've pulled LTO back to only running on the
fedora-release nightly job.
This tries to bring us back to the ideal from 322a83f321, where the
build jobs all have very low timeouts both for the overall job as well
as the build section we run. So if anything goes wrong - apart from
fedora-release - we'll just assume the runner has some environmental
damage, give up, and try again.
Of the build-for-tests jobs, all but the ASan and UBSan jobs regularly
complete in around 5 minutes, apart from debian-testing which is our
critical-path build job for almost all x86-64 testing. This is obviously
not good, but is tracked in mesa#12544.
The build-only jobs not using sanitizers also typically complete in
3-4 minutes, with the exception of debian-clang-release and
debian-x86_32 which are closer to 10 minutes. That's not ideal, but
they're also not currently on the critical path, so we can live with
that.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34280>
Buffer resources are quite special as they are only one dimensional,
always linear, don't have miplevels or array slices, never have a
texture or render compatible sibling, don't ever use TS.
The gallium context interface acknowledges this fact by providing
separate entry points for buffer maps/unmaps/flushes.
Provide a specialized etna_buffer_resource as a much more lightweight
alternative to the fullblown etna_resource and implement buffer
maps/unmaps in the same straight forward, direct map manner that is
hidden inside all the tiling, TS and resource sibling handling in
etna_transfer_map/unmap. It is expected that further map optimizations
can be added on top of this simple implementation much more easily
than in the merged buffer/texture transfer code.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34061>
A begin/end sequence is something like (it's all macros based):
radeon_begin(cs);
radeon_emit(PKT3(PKT3_DRAW_INDEX_AUTO, 1, cmd_buffer->state.predicating));
radeon_emit(vertex_count);
radeon_emit(V_0287F0_DI_SRC_SEL_AUTO_INDEX | use_opaque);
radeon_end();
This is loosely based on RadeonSI (see !8653 (a0978fff)) and it seems
indeed faster overall.
The main goal of this rework is to re-use the same logic as RadeonSI
for paired packets on GFX12 (also GFX11 dGPUs) because it's supposed
to be way faster, especially on GFX12 where the CP is slow. The other
goal is to share more cmdbuf emission between both drivers in the near
future.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34229>
This is probably a little more code but we're about to add real data for
Turing+ so it's better to have things contained like this. Since Volta
and earlier will always remain hacks, we might as well have those hacks
in the per-SM files rather than pretending we have a general thing in
sched_common.rs.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34302>
We're about to add instruction latencies which are going to be in their
own files because they're also massive. This makes things follow a bit
more of a module structure where sm70.rs is the thing that ties it all
together, sm70_encode.rs is the encoder, and smXX_instr_latencies.rs
will be the individual latency files.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34302>
After ca09c173f6, util_blitter_clear_render_target() requires
a call to util_blitter_save_fragment_constant_buffer_slot().
The radeonsi implementation was using the same sequence with
util_blitter_clear_depth_stencil() which does not need this
call. This was the cause of the refcnt imbalance.
For instance, this issue is triggered with:
"piglit/bin/ext_clear_texture-stencil -auto -fbo"
while setting GALLIUM_REFCNT_LOG=refcnt.log.
Fixes: ca09c173f6 ("gallium/u_blitter: remove UTIL_BLITTER_ATTRIB_COLOR, use a constant buffer")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34291>
This enables support for NV12, which are really useful when
dealing with hardware video decoders. This patch makes use
of the integrated YUV tiler to convert multi-planar to YUYV.
The binary blob uses the same method to deal with multi-planar
YUV formats. Other formarts will be added in a follow-up patch.
Tested with kmscube (nv12-1img) and the following gstreamer pipeline:
gst-launch-1.0 filesrc location=/tmp/test.mp4 ! qtdemux ! v4l2slh264dec ! video/x-raw,format=NV12 ! glimagesink
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Signed-off-by: Peter Frühberger
Signed-off-by: Marek Vasut <marex@denx.de>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3418>
By default mesa now only supports DRI3.
If Xorg is not activating DRI3, it will show an almost empty screen, which is not working.
No error message is given.
This e.g. happens at Debian package
xserver-xorg-video-intel at the i915 gallium driver.
This commit generates error messages to explain the problem.
Signed-off-by: GKraats <vd.kraats@hccnet.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33679>
A pipeline barrier which contains an image layout transition like
COLOR_ATTACHMENT_OPTIMAL -> TRANSFER_DST_OPTIMAL on compute queue
would just hang. Such a barrier is useless in practice but it's legal.
Prevent GPU hangs by skipping FCE or FMASK_DECOMPRESS when it's not
on the graphics queue.
Fixes dEQP-VK.synchronization2.layout_transition.compute_transition*.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34231>
It is important to get D/S only draw calls to bypass invoking
the fragment shader. The public documentation for Adreno states:
"Hint the driver to engage Fast-Z by using an empty fragment
shader and disabling frame buffer write masks for renderpasses
that modify Z values only."
"The GPU has a special mode that writes Z-only pixels at twice
the normal rate."
We are promised a big performance improvement in this case.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33735>
This affects:
- generic jobs (sanity, rustfmt, shader-db, docs, etc.)
- linux image builds
- linux mesa builds
- software renderer tests
- android tests
- virgl & venus tests
Marge pipelines get high priority, nightly pipelines get low priority,
and everything else is in between.
(Hardware test farms have their own mechanisms.)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34264>
This changes the static cycle count estimate so that it takes into
account estimated variable latency instruction delays. Statistics from
before this commit are not comparable to statistics generated after
this commit.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32311>
To get us started, this is designed to be pretty much the simplest thing
possible. It runs post-RA so we don't need to worry about hurting
occupancy and it uses the classic textbook algorithm for local (single
block) scheduling with the usual latency-weighted-depth heuristic.
-14.22% static cycle count on shaderdb
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32311>
The problem this fixes is currently hidden because of the order in
which we run nir_lower_tex & intel_nir_lower_texture. The issue is
that nir_lower_tex removes the LOD source in some cases and the second
run of nir_lower_tex can add it back.
This is also only needed on Gfx12.5+ if the LOD is present.
Finally move all of the texture lowering to the postprocess phase. No
need to run this multiple times.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33138>
The previous concept was to emit the non-deferred shader part
first, including the culling code, and then modify the
non-deferred part accordingly.
This caused some issues because it was really impossible to tell
which sysvals the deferred part needs after DCE, so we had to
run an additional cleanup pass afterwards.
The new concept is to prepare the deferred part first by applying
reusable variables (from the non-deferred part) and run DCE.
This opens the possibility to accurately gather info about what
the deferred part needs.
This idea is further expanded in the next commits.
Fossil DB stats on Navi 21:
Totals from 17 (0.02% of 79377) affected shaders:
Instrs: 18063 -> 18064 (+0.01%)
CodeSize: 93368 -> 93372 (+0.00%)
Latency: 49889 -> 49899 (+0.02%); split: -0.01%, +0.03%
SALU: 2416 -> 2417 (+0.04%)
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22073>
Calculate the IP ranges of the shader as an analysis pass. This will
later replace the existing tracking of start_ip/end_ip as the blocks are
changed (and the defer/adjust scheme to avoid too much churn when that
happen).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34012>
It was used by the pass tests to verify output with TEST_DEBUG=1,
replace it with brw_print_instructions().
The output is slightly different (not printing IP, not reordering the
blocks), we can add those features as we need, but given the usage was
already very reduced, don't bother with that until need arises.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34012>
Drivers are expected to ignore unknown structs in pNext chains. Venus
is a bit weird because we advertise features based on the host driver
and so we have code for all sorts of things which may not be supported
by the host driver. When globalPriorityQuery is unsupported, we
shouldn't even attempt to return anything. Currently, we just crash in
this case because vn_physical_device::global_priority_properties is an
uninitialized pointer. While we're here, initialize it to NULL if it's
invalid.
Fixes: e488b5e45e ("venus: support VK_KHR_global_priority")
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34218>
When we're using the PRIME path and using vkCmdCopyImageToBuffer to copy
to a linear image, the buffer memory is what's shared with the window
system. For legacy drivers that depend on memory signaling via
wsi_memory_signal_submit_info, we need to tell the driver to signal the
buffer memory, not the image memory or else the window system may wait
on a driver-internal buffer and not wait for the copy to complete.
Cc: mesa-stable
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34218>
a1b05991 ("radv/rt: Flush L2 after writing internal node offset on GFX12")
did this for radv-internal CP writes - we also need to do this for PLOC
sync data initialization which is done in the common framework.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34178>
The mirror needs to be reversed because the rotation is applied
before the mirroring.
VAAPI docs:
Mirroring of an image can be performed either along the
horizontal or vertical axis. It is assumed that the rotation
operation is always performed before the mirroring operation.
Cc: mesa-stable
Acked-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34140>
This should probably be done different, params should probably be considered immutable,
and this should be moved into the command buffer, also this gets set on decode paths as well
which might not make sense.
Reviewed-by: Hyunjun Ko <zzoon@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34204>
Because if FMASK_COMPRESS_1FRAG_ONLY is set, the FMASK decompress
operation actually doesn't occur. Note that DCC_DECOMPRESS implicitly
decompresses FMASK.
This fixes an issue on GFX10-GFX10.3 which is uncovered by enabling
VK_EXT_sample_locations.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33639>
FMASK_DECOMPRESS also implies FAST_CLEAR_ELIMINATE, so it can run first.
The only exception is fast-clear for color images that have DCC and
FMASK but without comp-to-single (only GFX10) because FMASK_DECOMPRESS
can't eliminate DCC fast-clears.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33639>
comp-to-single supports MSAA since a while and it's useless to perform
a fast clear eliminate for these fast color clears.
Only GFX10-GFX10.3 are affected because these are the only GPUs that
support DCC with MSAA with FMASK.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33639>
Mesa is built twice in the same debian-android job, once for aarch64 and
once for x86_64 to catch as many build regressions as possible.
However the install dir used for the two builds is the same, and this
results in a mix of aarch64 and x86_64 artifacts ending up in
install.tar, because .gitlab-ci/prepare-artifacts.sh is called at the
end of the second build.
Having two separate jobs for aarch64 and x86_64 build would be cleaner
but it would also use more resources.
Since the aarch64 libraries are not used for anything for now, a cheaper
workaround is to build x86_64 first and just call prepare-artifacts.sh
after first build.
This way the aarch64 build will still be done to catch regressions, but
the artifacts won't end up in install.tar which is also more consistent
with the fact that S3_ARTIFACT_NAME only has x86_64 in the name
(mesa-x86_64-android-${BUILDTYPE}).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34234>
We were never setting has_multiview. It's not actually necessary anyway,
since we can just do the optimization we were trying to do whenever
num_views is 1 instead.
This doesn't affect the actual fragment size, which was already correct,
only gl_FragSizeEXT.
Fixes: 6f2be52487 ("tu, ir3: Handle FDM shader builtins")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33991>
When bin merging we maximize instead of minimize the VSC pipe size,
which means that we fail when there are too many pipes instead of when
the pipes are too large. This means that we need to calculate
binning_possible differently, and we need to skip
tu_tiling_config_update_pipes() when binning is impossible because
otherwise we will write out-of-bounds.
Fixes: 3fdaad0948 ("tu: Implement bin merging for fragment density map")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34196>
Most implementation defined behaviors have been properly defined via
new maintenance extensions, and the mapping support is the only one
left on the table...in a very unfortunate way for historical reasons.
Meanwhile, update the host driver list for the latest that has been
tested working. Two major KVM improvements have also been documented
along with the setups that rely on those.
Acked-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34225>
Previously we were printing this information whenever the driver
started, but that proved to noisy.
For example, if running thousands of tests, this would cause thousands
of warnings messages to be printed. (Assuming the driver was built in
debug mode.)
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34243>
We will move this check into the `intel_dev_info` tool. Unfortunately,
this means we will be much less likely to notice inconsistencies, but
the current strategy has proven to be far too noisy.
For example, if the driver was built in debug mode, then when test
suites are running thousands of tests, the current approach can lead
to thousands of messages being printed.
Closes: mesa/mesa#12141
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34243>
Previously we'd burn 4 minutes waiting for curl to bang its head
trying to get results which would never emerge. Change this so we don't
fail on a 404, and also pull the retry down quicker, so we'll spend a
maximum of 2 minutes waiting for a server to come back, and no minutes
when the results aren't there to be fetched.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34244>
The new s3-proxy we have on fd.o is just a redirecting agent: it queries
the policy and, if allowed, returns a URL with temporary credentials
where the client can pull the real data from.
This means that nginx would see /fdo-opa/mesa-rootfs/misc?key=foo and
/fdo-opa/mesa-rootfs/misc?key=bar as distinct objects, not knowing that
it could cache only on the base URL.
Strip the query params from the nginx cache key so we can actually do
caching.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34244>
RenderDoc has a hard-coded limit of 16B for descriptor captures and
we're currently burning 24B. Reducing is pretty easy, though, since
storage doesn't support multi-plane. Any storage image views will use
VK_IMAGE_ASPECT_PLANE_N_BIT.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34128>
We detect whenever a method hasn't changed from one generation to the
next and just `pub use` the older generation's method struct and any
enum types associated. This keeps each mthd module independently usable
with all necessary types while reducing the number of unique Rust types
and associated trait implementations generated. This drops the size of
libnvidia_headers.rlib from 84 MiB to 22 MiB and will hopefully make
Rust code a little less expensive to build.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34136>
This adds proper Method and Field classes and uses them instead of
the pile of dictionaries we had before. This is probably faster and
definitely more readable. I've verified with cl9097.h that this makes
no differenct to the generated C or Rust besides whitespace.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34136>
The low-end Turing cards (TU117 for sure) are SM73, not SM75. These are
the cards on which we have tensor cores but they're so slow as to be
almost useless. We're not back-porting this because nouveau currently
returns 75 for these cards and because Volta binaries work fine on
Turing so they'll just be a little slower. We have, however, seen this
advertised by NVRM so we want our handling of shader models to be
correct.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34201>
It's possible that the source is uniform but the destination is not. In
this case, we need to insert a copy or else we might accidentally
propagate a uniform into some place we don't expect it.
This fixes a bunch of fp64 KHR-Single-GL46.subgroups.arithmetic.* tests.
Fixes: d09d3f5246 ("nak/from_nir: Emit uniform instructions when !divergent")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34201>
Currently it is not possible to mmap() the exported dma-bufs from etnaviv
for writing, through the GBM APIs, such as gbm_bo_get_fd(). etna_bo_dmabuf()
calls drmPrimeHandleToFD() only with DRM_CLOEXEC flag, omitting DRM_RDWR.
A typical call sequence, ending in etna_bo_dmabuf, for illustration:
gbm_bo_get_fd -> gbm_dri_bo_get_fd -> dri2_query_image ->
dri2_query_image_by_resource_handle -> etna_resource_get_handle
-> etna_bo_dmabuf.
Signed-off-by: Nikolas Zimmermann <nzimmermann@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34213>
In 35df3925ca ("brw: ensure VUE header writes in HS/DS/GS stages") I
misread the PRMs and thought that the VF would initialize the header.
What actually happens is that the VF does not write valid values in
there and the PRMs explicitly say that the VS shader should overwrite
whatever is in there.
We could avoid writing the header in some cases when no HW is going to
read back the header. For example with rendering disables through
3DSTATE_STREAMOUT::RenderingDisable. But those cases are dynamic and
the compiler is not able to tell. So just always write the header.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 35df3925ca ("brw: ensure VUE header writes in HS/DS/GS stages")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12880
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34211>
GL functions were exported by luck because we incorrectly used
link_with in meson, which exports functions only if the static lib is
used. link_whole guarantees that the functions are always exported
even if the static lib is unused.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34002>
- include the generated header directly instead of including
MAPI_ABI_HEADER
- remove the MAPI_MODE_BRIDGE macro
- must move code into .c files since we don't have the macros anymore
- clean up #includes
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34002>
Now the key consists of format + high order index from different pNext
chain structs. To be noted. we still don't want to cache modifiers to
avoid preparing dynamic length internal storage for per format
modifiers. The good thing is that most of the queries against modifier
support are one-time.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34207>
Xe3 different SKUs can have different max_subslices_per_slice and
Xe KMD topology uAPI only provide us the available subslices.
Therefore, to correctly calculate the available slices, we need
max_subslices_per_slice to match the hardware.
This change retrieves this information from hwconfig for Xe3+.
This avoids adding all the PTL intel_device_info variants.
Additionally, the PTL topology values are currently embargoed and
cannot be hard-coded in public source code.
This could be simplified if we decide to apply max_slices and
max_subslices_per_slice to all platforms that hwconfig is required.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33328>
I've also included the CI infrastructure used by each farm, in case an
issue is affecting all farms of a kind, like I don't know, a bug in the
http proxy used by lava & baremetal farms :]
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34195>
../src/asahi/compiler/agx_nir_lower_address.c:82:30: runtime error: passing zero to ctz(), which is not a valid argument
#0 0x56175dca5684 in pass ../src/asahi/compiler/agx_nir_lower_address.c:82
#1 0x56175dca2eda in nir_function_intrinsics_pass ../src/compiler/nir/nir_builder.h:164
#2 0x56175dca308c in nir_shader_intrinsics_pass ../src/compiler/nir/nir_builder.h:191
#3 0x56175dca68ae in agx_nir_lower_address ../src/asahi/compiler/agx_nir_lower_address.c:167
#4 0x56175dc885c0 in agx_optimize_nir ../src/asahi/compiler/agx_compile.c:3063
#5 0x56175dc9650d in agx_compile_shader_nir ../src/asahi/compiler/agx_compile.c:3827
#6 0x56175dc52148 in main ../src/asahi/clc/asahi_clc.c:359
#7 0x7fdf1c343249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#8 0x7fdf1c343304 in __libc_start_main_impl ../csu/libc-start.c:360
#9 0x56175dc44760 in _start (/builds/mesa/mesa/_build/src/asahi/clc/asahi_clc+0xbd0760)
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33685>
Different versions of Android might have different ways of getting the
GLES runtime version, so factor this out to a function, so that the
mechanism can be changed in a centralized way.
Also rename MESA_RUNTIME_VERSION to GLES_RUNTIME_VERSION because this is
really what is being retrieved, in the future we might have a similar
check for the vulkan Mesa driver.
While at it remove mentions of SurfaceFlinger in some comments since the
mechanism to retrieve the versions is irrelevant for the purposes of the
checks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34111>
The intel vulkan driver is always built by the `debian-android` job,
since it may be needed for some future job, push it unconditionally, it
does not hurt to have it in the Android system.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34111>
Since ANGLE is always built for Android, always push it even if it is
not going to be tested directly.
Besides simplifying the script, this is also because ANGLE is going to
be mandatory anyway starting from Android 15+ and not having it in the
Android system might cause unexpected failures.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34111>
Remove old mesa and ANGLE libraries before pushing new ones, and do this
using a trailing wildcard, because some versions of Android might have
versioned libraries like /vendor/lib64/egl/libEGL_mesa.so.1 which should
also be removed to avoid any confusion when loading the freshly pushed
ones.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34111>
Some of the commands in cuttlefish-runner.sh, like updating mesa and
ANGLE, are not specific to cuttlefish, in general they can be executed
on any Android device under test.
So split those commands out of cuttlefish-runner.sh and put them into an
android-runner.sh script.
For example, when testing a physical Android device instead of a virtual
device, a mesa-ci job will call android-runner.sh directly instead of
cuttlefish-runner.sh
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34111>
The color format needs to be compatible with depth or stencil. Also
the depth/stencil format was incorrect when it's the source.
Fixes dEQP-VK.api.ds_color_copy.*
and VKD3D_TEST_FILTER=test_copy_texture.
Fixes: d4ff011b12 ("radv: advertise VK_KHR_maintenance8")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34142>
Our QA team extensively tested Helldivers 2 on AMD RX 7800 XT/RX 7600
with many different presents and didn't get any GPU hangs. Few users
also reported the game being very stable without this workaround.
Few other users reported issues with the workaround itself (like
pstate not correctly restored etc), so let's remove it.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34164>
Need to properly fill layered api properties while adjusting query
wrapping based on maint7 feature enablement. Venus has to conditionally
advertise maint7 support only when renderer side vk is 1.2 or supports
VK_KHR_driver_properties.
Acked-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33960>
Previously, when rebuilding LLVM for Android, the script would delete the
freshly built LLVM install. This caused the android_build container to
lack LLVM unless the container was rebuilt again, this time without
rebuilding LLVM, and instead just downloading the tarball.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34180>
Ninja was already included in the android_build container, so there's no
need to put it in the Ephemeral packages, which only meant that it was
removed at the end of the LLVM build.
Also, add the usual image tag header at the top of
build-android-x86_64-llvm.sh.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34180>
We can't do earlyz_with_discard when using fbfetch as we can have TLB reads
that occur before the discard. This can result in implicit Z writes which make
the setmsf instruction emitted as a result of the discard invalid.
Fixes: 332b313547 ("v3d: enable framebuffer fetch")
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34151>
Starting from VCN 2+ (ie. RDNA1+), video encode/decode extensions are
enabled by default if the firwmares are up-to-date.
GFX6-9 firmwares will probably never be fixed and video extensions will
remain experimental because it won't be possible to pass VKCTS.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34144>
pipe_surface_width and pipe_surface_height helpers actually need
a pipe surface with a texture attached instead of just passing
directly the pipe_surface we get from the st.
The compressed formats are still broken unfortunatelly, so add them
to CI fails for now.
Partial fix for: 9d359c6d10
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34087>
The damage region can be useful to optimize the "resolve" step that we have on
imx6q (GC2000) because there isn't any tiling compatible with both render and
scanout or an any GPU when scanning out a linear buffer since we don't support
linear PE.
This improves fps for e.g `weston-simple-egl` by factor 2 (~30 fps -> ~60 fps).
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33226>
When updating delays, we'd update all dst regs based on reg_elems.
However, when wrmask has gaps, this would update delays for regs that
aren't actually written. Fix this by skipping regs for which the
corresponding wrmask bit is zero.
Note that this wasn't just a performance issue but could result in
illegal code because the delay is reset to zero for tex/sfu
instructions. For example, the following (post-legalization) code was
observed in the wild:
(rpt1)add.f r1.w, (r)r2.w, (r)c3.z
sam.base0 (f32)(w)r2.x, r3.y, s#0, t#1
rcp r2.x, r2.x
Here, the add would result in a required delay for r2.x which would then
be cleared by the sam (even though it doesn't write to it), resulting in
insufficient delay before the rcp.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: 61b2bd861f ("ir3: Rewrite nop insertion")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34107>
The call looks up a Program and creates it if it doesn't
already exist. However we weren't locking the hash between looking
up the name and adding it to the hash so it could be possible
another thread also generated the same name.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Fixes: 842c91300f ("mesa: enable GL name reuse by default for all drivers except virgl")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34091>
The call looks up an ATIShader and creates it if it doesn't
already exist. However we weren't locking the hash between looking
up the name and adding it to the hash so it could be possible
another thread also generated the same name.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Fixes: 842c91300f ("mesa: enable GL name reuse by default for all drivers except virgl")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34091>
The calls look up a renderbuffer and create it if it doesn't
already exist. However they weren't locking the hash between looking
up the name and adding it to the hash so it could be possible
another thread also generated the same name.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Fixes: 842c91300f ("mesa: enable GL name reuse by default for all drivers except virgl")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34091>
The calls look up a framebuffer and create it if it doesn't
already exist. However they weren't locking the hash between looking
up the name and adding it to the hash so it could be possible
another thread also generated the same name.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Fixes: 842c91300f ("mesa: enable GL name reuse by default for all drivers except virgl")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34091>
The calls look up a texture object and create it if it doesn't
already exist. However they weren't locking the hash between looking
up the name and adding it to the hash so it could be possible
another thread also generated the same name.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Fixes: 842c9130 ("mesa: enable GL name reuse by default for all drivers except virgl")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34091>
Allow us to parse instructions in a form we currently generate
```
dpas.8x8(8) g55<1>F g47<1,1,0>F g31<1,1,0>HF g39<1,1,0>HF { align1 WE_all 1Q $4 };
```
Regions are not really needed, but this will be handled in a later patch
(that will also stop printing the regions).
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34031>
The spec allows to create aliased disjoint image for a specific plane of
a multi-planar image, and the format can be R8. When querying memory
requirement of such image, VkImagePlaneMemoryRequirementsInfo is not
required to be chained although it has the disjoint bit.
This change fixes to look for aspect info from plane memory info only
when that's chained. The implementation can be passive here as the spec
VU has sufficient guarantees for the validity around. See below VU for
details:
- VUID-VkImageMemoryRequirementsInfo2-image-01589
- VUID-VkImageMemoryRequirementsInfo2-image-01590
- VUID-VkImageMemoryRequirementsInfo2-image-02279
- VUID-VkImageMemoryRequirementsInfo2-image-02280
Meanwhile, the existing disjoint check for size info is kept as is for
the special handling of VK_FORMAT_D32_SFLOAT_S8_UINT.
Test: dEQP-VK.ycbcr.plane_view.memory_alias.* pass with venus-on-panvk
Fixes: 412c286331 ("panvk: Enable multiplane images and image views")
Reviewed-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34134>
house protocols
- Remove some duplicate definitions (replaced with virgl_hw.h include,
which is also represented in gfxstream host code)
- Also removed the capset_ids from virtgpu_gfxstream_protocol.h. They
aren't needed to build guest-side driver, and are planned to be merged
to virtgpu_drm.h
Reviewed-By: Gurchetan Singh <gurchetansingh@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34116>
Per Vulkan spec 7.9. Host Write Ordering Guarantees, queue submission
commands automatically perform a domain operation from host to device
for all writes performed before the command executes. That is to say,
host updates to the mappings can occur after the end of the command
recording and must be flushed implicitly at submission boundary.
Before this change, necessary cache flushes could be missed once the
app starts reusing pre-recorded command buffers. e.g. a simple buffer
copy cmd while the app only updates the source buffer mapping in
different submissions. This changes backs out most of the current
version of cache flush reduction while still assigning LATEST_FLUSH_ID
to at least the final batch itself. This aligns with panfrost_batch
submit behavior on the gallium side.
Test: dEQP-VK.synchronization*.timeline_semaphore.* pass w/o flakiness
via venus-on-panvk
Fixes: 28e4d22497 ("panvk/csf: Pass a non-zero flush-id to benefit from cache flush reduction")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34093>
If the last owner thread has just unset the alive status and released
the watchdog, the new owner thread could have acquired to abort
unexpectedly if the ownership transfer occurs right before the next
owner's warn order. So we must set watchdog alive for new owner so that
it can properly check ring alive status in the next warn order.
Cc: mesa-stable
Acked-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34135>
That tag was supposed to allow these jobs to run faster, but these
runners are currently having disk issues, and the normal runners look
like they're plenty fast enough (at least right now since almost nobody
runs ci jobs ^^).
We might revert this later, but for now let's merge this to unblock CI.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34120>
The current `s3cp` implementation does not work anymore after the
migration, and instead of fixing it and propagating the fix down to us,
it's simpler to directly use `curl`.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34120>
Register spilling can cause us to require thread local storage (tls).
However, we were not adjusting the tls stack size space to account for
the tls needed for the extra xfb shader when transform feedback is
needed. We noticed this when testing register allocation in the
OpenGL CTS (for testing we had forced spilling where none happened
before).
Cc: mesa-stable
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33935>
Both GC7000 GPUs have the RA_WRITES_DEPTH feature, which needs a bit
more prodding to have valid fragcoord.zw components present in the
shader. This has been fixed by the previous commit, so we can remove
the related fails from the CI expectation.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34081>
On GPUs with the RA_WRITE_DEPTH feature, passing Z and/or W values
to SH can be gated. It doesn't have any impact on performance, so
maybe it's just to be able to free those register slots for other,
currently unknown, values. For now simply enable passing both Z and
W to SH unconditionally to make those GPUs behave like the ones
without the RA_WRITE_DEPTH feature.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34081>
This currently treats coarse and fine derivatives the same, but Qualcomm
needs to know whether just coarse derivatives are used or fine
derivatives/quad ops are also used. Rename this to
needs_coarse_quad_helper_invocations make clear the difference from the
new field, needs_full_quad_helper_invocations.
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Fixes: 264d8a6766 ("ir3: Set need_full_quad depending on info.fs.require_full_quads")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33862>
We no longer need finalize_nir and thus we don't need to support
texcoord as well. This is a nice rs state cleanup.
This effectivelly reverts commits
0ac6801970 and
d4b8e8a481. Also import the previous
location fixup from the state tracker, which was removed when the
unconditional nir_opt_varying pass was introduced.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33961>
This was added so we could report compile failures. Since we can
now just do that simply from create_vs/fs_state there is no need
for finalize_nir anymore.
Move the optimization loop to the beginning of create_vs/fs_state.
This could be probably optimized a bit more, but right now there
should be no functional change, we can improve the pass order later.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33961>
The register is usually a few dwords ahead of the memory value used by
the kernel, which can lead to an inaccurate calculation of where the SQE
is.
To compensate for the more accurate rptr, increase the lookback
slightly.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34063>
For RB, it's not convenient to use a gpuaddr because of how the GPU
addresses wrap around. Instead pass the host address to the renamed
highlight_addr(), so that we can use it directly.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34063>
This is needed for SPIR-V 1.6 support in OpenCL. This capability enables
the Uniform and UniformId decorations which prior were Shader only.
The CTS ends up using those decorations on function arguments, but we can
just ignore handling them there for now.
Fixes the spirv16_uniformdecoration_uniform and
spirv16_uniformdecoration_uniformid CL CTS test inside test_spirv_new.
Fixes: bb6d371c0e ("rusticl: support SPIR-V 1.5 and 1.6")
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34004>
It seems the hardware requires a dummy PS state with a noop FS,
otherwise it might just hang. This used to work just fine on older
gens.
Note that RadeonSI refuses to draw if VS or PS is missing and AMDVLK
seems to also always emit this state. So, this might be a bug that AMD
didn't encounter at all.
This fixes a GPU hang during loading with Ghostwire: Tokyo.
Backport-to: 25.0
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34070>
This change began by fixing an old regression related to the dceil
functionality. This issue affected palm. Now, this change adjusts
the software fp64 support to make it fully operational.
This change was tested on palm and barts. This change fixes 561
"piglit run all" tests. The khr_gl tests are fixed as well (243 tests).
Here is a summary:
spec/arb_gpu_shader_fp64/execution/built-in-functions/*
spec/arb_gpu_shader_fp64/execution/fs-isnan-dvec: fail pass
spec/arb_gpu_shader_fp64/execution/gs-isnan-dvec: fail pass
spec/arb_gpu_shader_fp64/execution/vs-isnan-dvec: fail pass
spec/glsl-4.00/execution/built-in-functions/*
spec/glsl-4.10/execution/conversion/*
khr-gl4[3-5]/compute_shader/fp64-case1: fail pass
khr-gl4[0-5]/gpu_shader_fp64/builtin/*
Fixes: aed6a39c10 ("glsl: Retire dround lowering.")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33708>
The key change is to use a builder to write the expected shader result
and compare that. To make this less error prone, a few helper functions
were added
- a way to allocate VGRFs from both shaders in parallel, that way the
same brw_reg can be used in both of them;
- assertions that a pass will make progress or not, and proper output
when the unexpected happens;
- use a common brw_shader_pass_test class so to collect some of the helpers;
- make some helpers work directly with builder.
The idea is to improve the signal in tests, so that the disasm comments
are not necessary anymore. For example
```
TEST_F(saturate_propagation_test, basic)
{
brw_reg dst1 = bld.vgrf(BRW_TYPE_F);
brw_reg src0 = bld.vgrf(BRW_TYPE_F);
brw_reg src1 = bld.vgrf(BRW_TYPE_F);
brw_reg dst0 = bld.ADD(src0, src1);
set_saturate(true, bld.MOV(dst1, dst0));
/* = Before =
*
* 0: add(16) dst0 src0 src1
* 1: mov.sat(16) dst1 dst0
*
* = After =
* 0: add.sat(16) dst0 src0 src1
* 1: mov(16) dst1 dst0
*/
brw_calculate_cfg(*v);
bblock_t *block0 = v->cfg->blocks[0];
EXPECT_EQ(0, block0->start_ip);
EXPECT_EQ(1, block0->end_ip);
EXPECT_TRUE(saturate_propagation(v));
EXPECT_EQ(0, block0->start_ip);
EXPECT_EQ(1, block0->end_ip);
EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode);
EXPECT_TRUE(instruction(block0, 0)->saturate);
EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode);
EXPECT_FALSE(instruction(block0, 1)->saturate);
}
```
becomes
```
TEST_F(saturate_propagation_test, basic)
{
brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16);
brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16);
brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F);
bld.ADD(dst0, src0, src1);
bld.MOV(dst1, dst0)->saturate = true;
EXPECT_PROGRESS(brw_opt_saturate_propagation, bld);
exp.ADD(dst0, src0, src1)->saturate = true;
exp.MOV(dst1, dst0);
EXPECT_SHADERS_MATCH(bld, exp);
}
```
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
While nullity of the CheckedPtr object is checked, writing to a raw
pointer safely requires that several other invariants be satisfied, so
it should be marked as unsafe to reflect that.
v2: reorder commits for cherry-picking and remove alignment check
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33989>
std::slice::from_raw_parts requires that the slice pointer be non-null,
even when the slice contains zero elements. Failing this invariant is
undefined behavior.
v2: reordered commits to allow cherry-picking bugfixes
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33989>
clGetSupportedImageFormats will write as many supported formats as are
discovered at present, regardless of the value of num_image_formats.
This could result in writing out-of-bounds memory.
v2: reordered commits to allow cherry-picking bugfixes
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Cc: stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33989>
This test already passed when executed standalone, but hit a issue triggered
by switching between fast and slow ZS clears when executed together with other
dEQP tests. This issue has been fixed by the previous commit, so we can drop
the fail from the CI expectation now.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34029>
When a slow/fast/slow clear sequence is executed on a surface, the second
slow clear will not regenerate the clear command if the clear value of the
fast clear is the same as the one used for the second slow clear, as the
current stored surface clear value is the same as the new clear value.
The command generated on the first slow clear however may have used a
different clear value, which is now submitted unchanged to the hardware on
the second slow clear.
Fix this by only generating the clear command if there is no valid one
already. If we already have a valid clear command simply update the fill
value in that command with the new clear value. This has some marginal
overhead, but has been chosen over the alternative of adding more state by
remembering the last slow clear value.
Cc: mesa-stable
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34029>
The problem occurs with a series of instructions build the subgroup
invocation value :
mov(8) g23<1>UW 0x76543210V
add(8) g23.8<1>UW g23<8,8,1>UW 0x0008UW
add(16) g23.16<1>UW g23<16,16,1>UW 0x0010UW
Our register spilling code operates on physical registers (64B on
Xe2+) and using the brw_inst::is_partial_write() helper only considers
32B registers. So the spiller doesn't see that the add(16) instruction
is doing a partial write and ends up discarding the previous value.
You can reproduce the issue by running a test like :
INTEL_DEBUG=spill_fs ./deqp-vk -n dEQP-VK.compute.pipeline.cooperative_matrix.khr_a.subgroupscope.constant.uint8_uint8.buffer.rowmajor.linear
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: aa494cbacf ("brw: align spilling offsets to physical register sizes")
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33642>
Cayman has a non-deterministic behavior issue which is
visible with the test below (arb_shader_image_size).
The tests fail randomly at the "fragment" test category.
Anyway, if the "compute" category is removed, the same
tests are working flawlessly.
The "compute" part of the driver was interfering with the
graphic pipeline. The culprit is the packet PKT3_DEALLOC_STATE
which puts the gpu in an incorrect state to perform some
graphic operations.
This change fixes this problem by issuing a PKT3_CLEAR_STATE
packet just after the PKT3_SURFACE_SYNC packet. As explained
by d51dbe048a PKT3_DEALLOC_STATE is mandatory on cayman to
avoid a gpu hang at the PKT3_SURFACE_SYNC stage.
This correction makes tests like
"spec@glsl-4.30@execution@built-in-functions@cs-.*" to pass
in an utterly deterministic way without random failures.
This change removes around 500 random failures for a
"piglit run all".
For instance, this issue is triggered on cayman with
"piglit/bin/arb_shader_image_size-builtin -auto -fbo".
Fixes: d51dbe048a ("r600g/compute: Emit DEALLOC_STATE on cayman after dispatching a compute shader.")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33973>
Venus can only enable VK_EXT_display_control after using common vk_sync,
unless we add new layered implementation in common. Like how I replaced
the common android present impl, but no bandwidth at this point.
Fixes: 89ec6c4d8f ("venus: add a few more trivial extensions")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34037>
This optimization seems broken because eg. v_s_log_f32 uses SGPRs
for both the source and destination but applying OMOD seems to require
VGPRs.
This fixes a GPU hang when launching Enshrouded on GFX1201.
No fossils db changes on GFX1201.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34027>
The premise of the change was wrong: the case where the defs analysis
was required was rare and requiring the analysis inside just the
case we care was being used for another analysis too. So for now,
the change doesn't really helps. I'll revisit this whole pass later on.
This backs out commit 6e19215810.
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34039>
A lot of people (including me) misinterpreted the conformanceVersion
field for so long. The Vulkan spec wasn't very clear either but it's
going to be clarified soon.
VkConformanceVersion is actually unrelated to the official CTS
conformance process in Khronos. It just reports the latest CTS version
that the driver can pass, not more.
For GFX8+, RADV should be passing CTS 1.4.0.0 on all GPUs because we
validated this CTS version recently for Vulkan 1.4.
For GFX6-7, which only suppports Vulkan 1.3, RADV should also be
passing CTS 1.4.0.0, because newer versions of the CTS can be used
to validate a driver against an older version of the spec, so
it's perfectly fine to report a higher CTS version than the Vulkan version.
Newer CTS versions likely can't pass 100% due to a DGC bug that I still
need to fix.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12799
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34018>
Instead of calling `require()` every instruction, call it once per pass.
Even though the defs are cached (i.e. we are not re-calculating them every
instruction), this prevents the extra check and the call to analysis
validation.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34010>
Otherwise, the size of the EGLSurface and the drawable may get out of
sync if kopper needs to re-create the swapchain at a different size.
This can cause problems with things like eglSetDamageRegionKHR() where
the core EGL code clamps them to the size in the EGLSurface.
With Wayland, it's up to the client to choose a size and resize by
creating a new EGLSurface with a different size. Only on X11 can we
get a resize side-band like this.
Normally, without kopper, this goes the other direction where the X11
EGL code will detect a surface size change in dri2_x11_query_surface()
and it invalidates the drawable if they've changed, forcing
re-allocation. Kopper, however, works more like the DRI2 path where we
just get handed buffers at some size decided by X11 and have to deal
with them. In the DRI2 path, the size is unconditionally updated by
dri2_x11_get_buffers(). This is roughly equivalent, updating the size
right after every call to kopperSwapBuffers().
Fixes: 8ade5588e3 ("zink: add kopper api")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12797
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34015>
- brw_lower_3src_null_dest: Allocating a new destination, so include
INSTRUCTION_DATA_FLOW class.
- brw_lower_alu_restriction: Removing instruction, so include
INSTRUCTION_IDENTITY. No details are changed so remove
INSTRUCTION_DETAIL.
- brw_lower_vgrfs_to_fixed_grfs: Changing source and destination
numbers, so include INSTRUCTION_DETAIL.
- brw_lower_send_gather: Insert new instructions (scalar register) and
change sources and other information on existing ones. So include
INSTRUCTION_DETAIL and INSTRUCTION_IDENTITY. Promote to INSTRUCTIONS.
- brw_opt_eliminate_find_live_channel: Can change source, so include
INSTRUCTION_DATA_FLOW.
- brw_opt_copy_propagation_defs and brw_opt_cse_defs: Both can remove
instructions, so include INSTRUCTION_IDENTITY. Promote to
INSTRUCTIONS.
- brw_opt_saturate_propagation: Instruction can have `sat` modified,
and operands can have type modified, so include INSTRUCTION_DETAIL.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33993>
Replace global path variables with ProjectPaths dataclass
- Add explicit file existence check before loading YAML
- Enhance tag retrieval by checking environment variables first
- Add logging for better debugging of tag selection process
- Remove redundant file existence check in main function
- Improve error handling for missing conditional tags file
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33863>
This reverts commit 1cc2c738bb
We originally changed some aliases into functions so scripts could use
them without needing to be sourced, keeping the environment cleaner.
However, this broke `x_off`, which is supposed to stop debug logs
(xtrace output) from showing in the console. The function version still
triggered xtrace before disabling it, while the alias correctly
redirected the logs to `/dev/null`.
It also fixes the `bin/ci/update_tag.py` script to be able to reuse the
aliases via double sourcing the setup-test-env.sh and the respective
build script.
Reported-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33863>
Venus query records have been properly propagated from nested cmds
already, so no special care is needed here for qfb optimizations.
Test:
- dEQP-VK.api.command_buffers.*nested*
- dEQP-VK.conditional_rendering.*nested*
- dEQP-VK.draw.dynamic_rendering.nested_*
- dEQP-VK.multiview.*nested*
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33992>
This matches Intel driver. Chromium always sets RT format to YUV420
which would cause us to not report other formats as supported.
Only check that the RT format is actually supported when creating
config, but don't limit supported surface formats.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34001>
This allows the exported fds to be mapped for writing. This is needed
for virtgpu native ctx support where the fds are mapped rw when the
mappings are added to the guest by kvm. This aligns with other mesa
drivers, and unblocks the extended testing with venus on top.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34017>
We also want to run Android CTS in the Android jobs.
Since the Android CTS is quite large, download it and strip it down to
only contain the interesting tests, so to reduce the space taken in the
container image.
Eventually we might want to have android-cts be run via deqp-runner
itself, but for now add a proof-of-concept mechanism which calls the
android-cts directly and uses an ad-hoc handling of expectations.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33499>
To run deqp-runner in cuttlefish we do something similar to
deqp-runner.sh but adapted to be used on Android via adb.
Isolate those adapted commands in an android-deqp-runner.sh script so
that in the future it will be easier to compare with deqp-runner.sh and
evaluate if deqp-runner.sh and android-deqp-runner.sh could be possibly
consolidated into a single script.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33499>
In .gitlab-ci/cuttlefish-runner.sh 32bit libraries were removed but they
were not being replaced with newer ones, however this caused some
problems because by default the x86_64 target in AOSP is still
multi-library and for example the 32bit zygote process ended up crashing
because of the missing 32bit libraries, causing a general system
instability.
Since the CI is only building 64bit libraries for the android target,
use an x86_64_only cuttlefish product which only has components and
libraries built for the 64bit target, this avoids dealing with 32bit
EGL/Vulkan libraries at all, preventing any possible cause of
instability.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33499>
Disable the modem simulator in cuttlefish, it is not needed for testing
the graphics subsystem and avoids opening a few vsock ports which
reduces the chance of collisions in case of multiple instances of
cuttlefish running concurrently.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33499>
Cleaning up and stopping cuttlefish before launching it is not strictly
necessary when using gitlab shared runners.
This can be added back later when we have a better justification.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33499>
A significant CPU performance bottleneck in mesa GL is refcounting atomics:
even with the current pinning attempts, eliminating them can yield huge
performance gains (easily verified by running drawoverhead with return false at the top of pipe_reference_described()).
This is a proof of concept for removing refcounts from gallium objects,
namely sampler views and resources. Sampler views were smaller in scope,
so I started there. This MR alone is not expected to noticeably affect
performance, though if applied to all drivers/frontends,
it would enable a bunch of code deletion for crazy samplerview
refcounting hacks currently used to try circumventing the existing overhead.
Co-authored-by: Karol Herbst <kherbst@redhat.com
Co-authored-by: David Rosca <david.rosca@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33813>
When translating atomic instructions, the base type of the imageView can be
float only for image_atomic_exchange. If a float type image is used with other
atomic instructions the results are undefined.
Enforce this check in the shader translator and don't emit any instruction if
it fails.
Fixes crash in piglit test arb_shader_image_load_store@invalid.
Signed-off-by: Maaz Mombasawala <maaz.mombasawala@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33749>
The nir to tgsi translator flattens all constants in the nir shader into uint32
immediates. In the svga driver, the vgpu10 shader translator then packs all
these immediates into a constant buffer, and also optimizes it to prevent
repetitions by only emitting a 32-bit constant once.
This can cause problems with double sized constants, since either the lower or
higher 32-bits of different 64-bit constant can be identical, and in the constant
buffer that repeating 32-bit value will be emitted only once, so a 64-bit
constant gets split into two non-contiguous 32-bit values.
When this 64-bit constant is then invoked by a double instruction live ddiv or
dmul, the source register can now have invalid swizzles like .xz or .xw since
its 32-bit components are not contiguous.
We have seen this happen in the piglit test -
spec@arb_gpu_shader_fp64@execution@glsl-fs-loop-unroll-mul-fp64
which emits invalid swizzle values for double instructions.
To fix this, introduce a new option in nir to tgsi shader translator that
preserves uint64 constants. When a 64-bit immediate is translated into svga
shader code, its 32-bit components are contiguous and aligned in the constant
buffer, so accessing them only emits valid swizzles .xy and .zw.
Other drivers using the nir to tgsi shader translater should not see any change
in the tgsi shader emitted unless they too explicitly invoke the
keep_double_immediates option like svga.
Signed-off-by: Maaz Mombasawala <maaz.mombasawala@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33749>
During translation of tgsi shaders to vgpu10 shader code that is sent to
svga device, we may get as input a double instruction with incorrect
swizzles such as xzxz. In this case we have a workaround to move the value
in that register to a temporary register with an xyzw swizzle.
However the functions that check if the instruction has double source or
destination did not check for all instructions, such as DDIV, so if
incorrect swizzles are sent in the shader tgsi code then the same
incorrect swizzle is also emitted in the vgpu10 shader code.
Fix this by adding all the double instructions in double checking
functions.
Signed-off-by: Maaz Mombasawala <maaz.mombasawala@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33749>
The extra `all_free` that now remains in the list will be ignored in the
loop below anyway so there is no need to have complex code to try to
remove it.
This also means it becomes possible to set things like
`-D video-codecs=all_free,vc1dec`.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33949>
- Fix the checks for emulation (based on presence of the extension
on the host)
- Add flag in gfxstream_vk_physical_device, otherwise the real device
extensions are not properly filtered when communicating with the host.
- The "function" version of the check in ResourceTracker can eventually
just check the flag once mesa and gfxstream objects are combined
- Remove the duplicate getPhysicalDeviceFormatProperties2 impl, this is
covered by the ResourceTracker impl
- Add ResourceTracker impl for getImageDrmFormatModifierPropertiesEXT
- Remove isDmaBufImage flag from VkImage_info, and clean up all the code
associated with this flag. In on_vkCreateImage, all required info is
avaialble from the extMemImageCi::handleType. In on_vkAllocateMemory,
this is all associated with the tiling of the dedicatedImage for the
allocation
Reviewed-By: Gurchetan Singh <gurchetansingh@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33944>
With secondary command buffers, inherited rendering can be used but
it's basically impossible to know if the depth/stencil attachment
enabled HiZ/HiS. But it's required to disable WALK_ALIGN8 to avoid
GPU hangs.
This assumes that HiZ/HiS is enabled for inherited rendering as long
as a depth/stencil attachment is used. It's not the most optimal
approach but it's not supposed to hurt either.
This fixes a GPU hang with
dEQP-VK.dynamic_rendering.primary_cmd_buff.basic.contents_secondary_cmdbuffers
and friends.
GFX1200 isn't affected because it doesn't support HiZ/HiS.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33986>
We currently report a deviceName as e.g. "Mali-G610 (Panfrost)", but
panfrost has nothing to di with the physical device, and the suffix
doesn't belong there at all.
So let's remove that suffix from PanVK. This results in output like this
from vulkaninfo:
---8<---
VkPhysicalDeviceProperties:
---------------------------
apiVersion = 1.1.305 (4198705)
driverVersion = 25.0.99 (104857699)
vendorID = 0x13b5
deviceID = 0xa8670000
deviceType = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
deviceName = Mali-G610
pipelineCacheUUID = <snip>
---8<---
We already sort of namedrop Panfrost in the driver properties:
---8<---
VkPhysicalDeviceDriverPropertiesKHR:
------------------------------------
driverID = DRIVER_ID_MESA_PANVK
driverName = panvk
driverInfo = Mesa 25.1.0-devel (git-136dd9f985)
conformanceVersion:
major = 1
minor = 4
subminor = 1
patch = 2
---8<---
While this might techically speaking be a regression, PanVK has been
marked as experimental until Mesa 25.0. But to reduce the risk of people
starting to depend on this behavior, let's also backport this change to
the 25.0 release.
The patch looks a bit funny, because we add the " (Panfrost)"-suffix in
common code, and this moves it to the Gallium driver. But effectively,
this means PanVK is the only driver that sees a change of behavior.
Backport-to: 25.0
Reviewed-by: John Anthony <john.anthony@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33972>
We have a common implementation for this, let's just use that.
Similar to the previous commit, this is a bit silly. But if we ever get
in a situation where VK_EXT_display actually makes sense, this stuff
should "just work", so let's enable it for good measure.
Tested-by: Alexandre ARNOUD <aarnoud@me.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33916>
It seems the common WSI code does all that's really needed here for us
already. Enabling this lets me run vkmark on PanVK.
This is a bit silly, because what actually happens here is that we end
up passing -1 as the display_fd to wsi_device_init(). This in turn leads
us to returning zero usable displays, which renders the extension
somewhat useless. But it is better than not supporting the extension, and
not supporting applications who have a hard depdendency on it fail, like
is the case with vkmark.
Tested-by: Alexandre ARNOUD <aarnoud@me.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33916>
We're currently exposing a bunch of extensions that requiring Vulkan
1.1, and we'll soon enough do the same for Vulkan 1.2. Instead of having
to update each of these extensions separately once we add new Vulkan
version support for some gens, let's use a single variable for this
instead.
And while we *could* query the exposed vulkan version and do this a bit
more "automatically", this makes it easy to leave some needless checks
behind if the baseline version changes. Leaving this as a arch check in
this function should make it a bit more obvious when the check can be
removed.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33971>
This was only needed on Sandybridge. We can delete the brw code,
and replace the generic devinfo bit with a helper inside the elk
compiler itself.
Thanks to Iván Briano for noticing we still had dead brw code for this.
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33764>
We were not using the minimum values from devinfo for anything. For
tessellation control, the minimum value is 0, so we continue taking
MAX2 of that with 1 when tessellation is enabled so we have at least
something guaranteed to be present. For geometry, the minimum value
is already non-zero (and updated by the previous patch).
This will have the side-effect of raising the minimum number of URB
entries for geometry stages. This is currently not known to fix
anything, but should be more closely following the documentation.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33764>
We've been programming our minimum number of URB entries for geometry
shaders to 2, but it appears that we should have been setting 8 on
Broadwell and later. Additionally, there's a workaround on Skylake
and later that requires us to add flushing (which we haven't) or use
a minimum of 16 URB entries.
This alone will not fix anything, as nothing reads this devinfo field
presently (will be fixed in the next commit).
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33764>
As we added new platforms, the device info macros evolved over time
Most platforms had a "FEATURES" macro, some had a "HW_INFO" macro,
a few had macros for URB entries - some with min entries only, some
with min and max, some including the .urb = { ... } braces, others not.
Thread counts or subslice info was sometimes considered FEATURES,
sometimes HW_INFO, sometimes inserted only in the final structure.
FEATURES macros often inherited from an ancestor platform, but not
necessarily the prior platform - many were based on GFX8_FEATURES.
Many redundantly set the same feature bits as prior platforms.
This patch aims to clean up the situation, so it's a little more
organized, especially if you look at multiple generations. Macros
are now split into several separate pieces:
1. The FEATURES macro only has architectural features, such as LSC,
ray tracing support, 64-bit integers, flat CCS, and so on. Thread
counts, subslice info, and URB sizes that may vary by SKU are not
included here. This makes it easy for one platform to inherit the
features from the previous, while not pulling in that extra data.
2. THREAD_COUNTS macros contain maximum thread counts from the
3DSTATE_VS documentation and so on.
3. URB_MIN_MAX_ENTRIES macros contain the entire URB configuration,
including .urb = { ... }.
4. PAT_ENTRIES macros (on modern platforms) contains our choice of which
PAT entries to use for various types of resources.
5. CONFIG macros combine all of the above into a tidy bundle for use
in defining various structures, and may also include the platform
macro or simulator ID for convenience.
On recent platforms where hwconfig tables exist, items #2-3 could
potentially be dropped and filled in from there instead. For XEHP+
where we require hwconfig, we instead have a PLACEHOLDER_THREADS_AND_URB
macro that makes it clear that these values are updated from hwconfig.
One nice thing is that the bits that could (or do) come from hwconfig
tables are now cleanly separate from those that do not (i.e. platform
feature support, PAT entry selection, and so on).
This patch does not touch GFX7 or earlier macros. We could probably
offer a similar treatment there, but they're generally working and not
quite as complex.
To verify that this commit does not have unintentional changes, I
recommend running
objdump -s build/src/intel/dev/libintel_dev.a.p/intel_device_info.c.o
before and after this commit, and diffing the output. The devinfo
structures produced are identical.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33764>
intel_device_info_init_common calculates this for Gfx9+ based on
max_threads_per_psd and slice information. Mark it as zero in the
structures to make clear that the value there isn't useful, and make
it easier to diff binaries for the next commit's refactors.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33764>
The documentation for 3DSTATE_URB_HS has 0 as the minimum number of HS
URB entries for all platforms. See BSpecs 32162, 47137, 56271 for
Gfx6-11, Xe, and Xe2-3, respectively.
This should silence warnings about our device info field not matching
the hwconfig tables.
Notably, nothing in our drivers currently uses this value so it cannot
have a functional impact.
Fixes: 4064b5546b ("intel/dev: reduce warning noise from urb settings")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33764>
This code, since the dawn of time, has had a redundant check for gen5-6
separate stencil in the final else clause:
} else if (doing separate stencil on gen5-6) {
return compact
} else {
if (doing separate stencil on gen5-6)
return compact
...
}
We can eliminate that one. The else clause then has a single if, so it
can be folded into the "else if" ladder alongside the others.
Reviewed-by: Dylan Baker <dylan.c.baker@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33764>
Compositors sometime try to import BOs with lower alignments than 128B.
This seems particularly common in the case of cursor images but it can
also happen on other BOs allocated by the old nouveau GL driver. As
long as we avoid rendering to them (which NVK will do), the
texture/image hardware is fine as long as they're at least 32B-aligned.
Panicing in this case isn't very nice to compositors.
Backport-to: 25.0
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33990>
When importing libdrm_radeon code [1][2] it was somehow missed
that what libdrm has in one r600_pci_ids.h, Mesa has split
into r600_pci_ids.h and radeonsi_pci_ids.h. So, devices
with ids from radeonsi_pci_ids.h were not considered valid for
radeon_surface_manager_new.
This commit changes that, thus fixing radeonsi for these
devices.
[1] commit 1299f5c50a
[2] commit 3aa7497cc0
Fixes: 1299f5c50a
Signed-off-by: Ivan A. Melnikov <iv@altlinux.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33940>
to make it easier for people (especially newcomers to the project) to add review
tags, we need a database mapping gitlab usernames to author names & emails. that
way, if someone just comments "rb" or whatever, there's a direct way to look
that up. this comimt adds a list of current contributors with the following
methodology:
1. first, I grabbed all names + emails of recent authors, with mailmap applied,
as proxy for active contributors:
$ git log --since=2025-01-01 --pretty='%aN,%aE,'|sort | uniq
2. then, I scraped usernames via the gitlab api attempting to match by name. I
don't want to hammer the gitlab api too much which is why I tried to keep the
list in #1 as small as possible.
import gitlab
import subprocess
import tempfile
import sys
import urllib.request
import csv
gl = gitlab.Gitlab('https://gitlab.freedesktop.org', private_token=...)
names = {}
with open('dump.csv') as csvfile:
spamreader = csv.reader(csvfile)
for row in spamreader:
if len(row) == 3:
names[row[0]] = row[1]
for name in names:
users = gl.users.list(search=name)
print(', '.join([name, names[name]] + [u.username for u in users]))
3. finally, I fixed up various data issues by hand. there were cases of both
people with multiple usernames (I tried to pick the one that's actually in
use), and people whose name on their profile does not match the name in their
commits (I tried to determine the username from searching gitlab manually,
but dropped a number of such authors when it was nontrivial to figure out. I
am a regular reviewer across the tree so if I don't recognize your name
you're probably not that active, sorry.)
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33896>
..or "the one where Alyssa gets jealous by b4".
Those of us who have stuck around a while have a habit of just commenting "rb"
or "ab" on MRs. which raises the question for everyone else of what name/email
to use. I've personally built up a collection of 36 (!!) different
shell aliases to apply different people's trailers. I think other people do
similarly.
This calls for better tooling. This patch adds a little script for applying
review trailers given a fuzzy match on the reviewer's name. I recommend
contributors alias it to something like `mrb`, then you can do things like:
mrb alyssa
mrb -a faith
to add a review tag for me or an acked-by tag for Faith.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33896>
It is expected that inputs and prefetches are always in the first block.
However, ir3_create_empty_preamble would create blocks before the first
one, leaving inputs after the preamble. This causes issues with
(probably among others) spilling/RA where precolored inputs could
illegally reuse the spill base register.
Fixes RA validation failures on a7xx for
dEQP-VK.ray_query.multiple_ray_queries.vertex_shader
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: f3026b3d3e ("ir3: add some preamble helpers")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33977>
For empty BVHs we shouldn't emit any leaf nodes, but there is one
invocation to encode the root node. Guard leaf node encoding so that
invocation doesn't try writing any leaves.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33985>
Prime blit can be used in setups like venus on lavapipe over vtest. It's
native env so Venus relies on renderer side driver to tell about the pci
info, while lavapipe doesn't implement that extension, which ends up
with mismatched gpu thus prime blit.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33956>
The swizzle check was too strict, we actually don't care about the
swizzle on the constant source at this point, it is only checked
later whether the constant source actually has the correct form.
So this effectively enables INV and BIAS presub on R300/R400.
RV370 stats:
total instructions in shared programs: 85379 -> 84948 (-0.50%)
instructions in affected programs: 15669 -> 15238 (-2.75%)
helped: 336
HURT: 81
total presub in shared programs: 1318 -> 2991 (126.93%)
presub in affected programs: 797 -> 2470 (209.91%)
helped: 0
HURT: 514
total omod in shared programs: 387 -> 384 (-0.78%)
omod in affected programs: 9 -> 6 (-33.33%)
helped: 3
HURT: 0
total temps in shared programs: 13290 -> 13243 (-0.35%)
temps in affected programs: 1388 -> 1341 (-3.39%)
helped: 91
HURT: 52
total consts in shared programs: 81922 -> 81855 (-0.08%)
consts in affected programs: 173 -> 106 (-38.73%)
helped: 67
HURT: 0
total cycles in shared programs: 126746 -> 126560 (-0.15%)
cycles in affected programs: 30752 -> 30566 (-0.60%)
helped: 255
HURT: 124
LOST: shaders/godot3.4/22-69.shader_test FS
GAINED: shaders/ck2/172.shader_test FS
GAINED: shaders/tesseract/389.shader_test FS
GAINED: shaders/tesseract/393.shader_test FS
GAINED: shaders/unity/64-DeferredPointShadows.shader_test FS
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33915>
Previously asynchronous descriptor set allocation is only enabled when
the VK_DESCRIPTOR_POOL_CREATE_FREE_DESCRIPTOR_SET_BIT bit is not set.
However, some engine would use that bit but alloc/free with identical
descriptor set layout. So this change extends the async set alloc to
cover that since the spec has guaranteed no fragmentation there.
Besides, a pool before any descriptor set free is also considered w/o
fragmentation. so this change extends to cover here as well. Both
would also help with dEQP run time since all descriptor pools involved
are with that bit set.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33966>
We get a kernel message "You are adding an unorder point to timeline!"
on many CTS runs. This stems from us SIGNALing the queue syncobj then
WAITing but not reseting it. It is assumed by the time we get to
panvk_queue_submit_init_signals() that the value is 0, however it is 1
due to the previous calls.
Signed-off-by: Ashley Smith <ashley.smith@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Fixes: 5544d39f ("panvk: Add a CSF backend for panvk_queue/cmd_buffer")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33943>
VEGA10, RENOIR, NAVI10, RAPHAEL and NAVI31 are covered, they passed
100% of 25 runs each.
NAVI21 and VANGOGH still don't enable video testing in CI because I
got few hangs during my last stress test. Need to be stress tested
again.
Note that the kernel in Mesa CI is too old and doesn't have latest
firmwares that should fix the remaining failures.
GFX6-8 have different issues like GPU hangs on Polaris10, so it's not
yet enabled in CI.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33968>
At least, NAVI10, NAVI21 and NAVI24 are affected by this what looks
like a hardware bug when primitive restart is changed and no context
registers are written between draws. It seems the hardware doesn't
consider primitive restart at all in this situation.
Adding SQ_NON_EVENT(0) as suggested by Marek seems to fix it reliably
without introducing any overhead. It's basically a NOP packet that adds
a small delay.
Fixes new VKCTS coverage dEQP-VK.transform_feedback.primitive_restart.*.
Also fixes this old vkd3d-proton issue.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7258
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33929>
The boot action was wrapping the deploy action, which could cause
timeout misalignment. For example, the boot `GitlabSection` timeout was
shorter than the deploy timeout in LAVA, leading to cases where LAVA
jobs were canceled during their own retry mechanism.
By splitting these actions, we can align the timeouts properly,
preventing interference and unnecessary job cancellations.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33906>
There are some jobs that were missing the FARM variable, which is useful
to lava_job_submitter.py to classify how it should interact with each
LAVA server and how it should assemble the job definition.
Right now, we use a set of regexex with the RUNNER_TAG variable, but
that is error-prone.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33888>
We check for iamge layouts and feedback loops when we bind image
resources but not queue families. If the resource isn't on the graphics
queue, we need to add it to need_barriers so we can transition it back
to our queue.
Fixes: d4f8ad27f2 ("zink: handle implicit sync for dmabufs")
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33952>
Otherwise, we'll transition to QUEUE_FAMILY_FOREIGN and then forget that
we left it on the foreign queue and never transition back the next time
we use the resource. This was kind-of okay with Wayland compositors
because they always re-import the BO so it's always fresh and they pick
up on the queue transfer the first time. X11, on the other hand, does
not re-import BOs so they get stuck in this weird QUEUE_FAMILY_FOREIGN
limbo until something happens to randomly trigger a layout transition
check and then we find it and do the transition. We should mark them as
needing a barrier the moment we transition to QUEUE_FAMILY_FOREIGN.
Fixes: d4f8ad27f2 ("zink: handle implicit sync for dmabufs")
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33952>
Implement all commands involved. No need to scrub anything in the RT
pipeline info since it has been well validated by the VUs related.
The nature of VkDeferredOperationKHR plays well with venus multi-ring
support. So later we can properly define our own concurrent limits for
RT pipeline creations.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33907>
This commit adds genxml to Lima, by copying mostly from Asahi. The definition of the texture descriptor has been moved there.
v2:
- remove mipaddress handling, use "shr(6)" modifier
- indent TD parser 8 spaces
v3:
- added copyright
- renamed ushort to unorm16
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33385>
With SPIR-V 1.6 OpIsHelperInvocationEXT was effectively replaced with
Volatile loads of the HelperInvocation built-in variable.
This patch also drops the distinction between is_helper_invocation and
load_helper_invocation.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33492>
The "JIP:" and "UIP:" markers were being ignored, so was possible
to switch their order in the text but the parser would act as the
same. Just fix the order now and enforce it through the parsing.
Since we are here, remove the "Jump:" and "Pop:" that are not used
for Gfx9+ anymore.
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33522>
And use brw_builder(brw_shader *) and brw_builder() constructors
where possible.
The way tests are written, it is necessary to initialize an "empty"
builder -- which is later replaced by a proper one. Default parameter
NULL make that initialization implicit.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33815>
We already merged it below, when the library has both fragment output
interface and fragment shader state (which is when we'd compute it
anyway). Setting it twice is probably harmless but also confusing and
useless.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33902>
fd_pipe_new2 can segfault when trying to set the is_64bit flag on new
pipes. This can happen when the current GPU is not be listed in the
fd_dev_recs table because it's not supported by mesa, but is supported by
the kernel.
Add a helper function to test if the current GPU is in the supported table,
and use it in fd_pipe_new2.
Signed-off-by: Loïc Minier <loic.minier@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33830>
The fast path for kgsl_queue_submit when there are no command buffers
and only sync objects led to breakage for two reasons:
* The fast path was not properly handling duplication of the merged sync
object assigned to signalled `kgsl_syncobj`(s), which could lead to
multiple `kgsl_syncobj`s owning the same FD and consequently issues
such as double close of that FD leading to UB. This is fixed by moving
to the slow path as it always produces a timestamp sync object which
can be trivially duplicated.
* The Vulkan specification requires that drivers strictly follow the
order of submission of command buffers and consequently the order of
semaphore signal/wait operations. Since no submission was being made
to the kernel, subsequent submissions could be executed without waiting
for wait/signal operations from previous submissions to complete.
As both of these issues are fixed by moving to the slow path, this patch
removes the fast path in favor of the more correct slow path.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33894>
RC_FILE_INPUT is pretty much just a RC_FILE_TEMPORARY with an initial
value in it. So we regalloc it the same way we do normal temps, however
for unknown reasons (probably to have a bit more readable shader dumps)
we still keep the RC_FILE_INPUT type even though its the same as
temporary. This is handled correctly when emitting the machine code,
however, it was not taken into account in shader stats.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33817>
The free list must be re-initialized. Found the bug while running:
dEQP-VK.ray_tracing_pipeline.acceleration_structures.device_compability_khr.gpu_built.top
where it invokes VK_COMMAND_POOL_RESET_RELEASE_RESOURCES_BIT to purge
the cmd pool resources, and the next alloc still gets cache hit with the
"empty" list.
Fixes: e2c4bafccc ("venus: free query batches for VK_COMMAND_POOL_RESET_RELEASE_RESOURCES_BIT")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33908>
If PXP initialization is not completed and application requested a
protected context the GEM_CONTEXT_CREATE will wait up to 250ms for
PXP to finish initialization but if that do not happens it will
return a error and set errno to EIO.
This patch add the missing retry handling.
Cc: mesa-stable
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30723>
Implement 2 optimizations for branches:
1) if unconditional branch target is a block that only has
unconditional branch, propagate the target
2) optimize following contruction:
block 1:
...
if (cond) block 3
block 2:
branch block N
block 3:
...
into
block 1:
...
if (!cond) block N
block 2:
block 3:
...
Note: optimization 1) significantly improves runtime of if ladders, but
it is not visible in shader-db because we do not track shortest/longest
path and it doesn't always create dead code (usually just a single
instruction)
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33754>
On a7xx, const registers should be loaded via the preamble instead of
uploaded by the driver to the const state. This commit implements this
by adding a new pass that emits the consts created by ir3_cp to a
sequence of stc instructions in the preamble.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32454>
On a7xx, the immediates that get promoted to const registers will be
initialized in the preamble instead of being part of the const state. So
technically, we won't need the immediate state that is part of the const
state anymore on a7xx. However, it is still a convenient place for
ir3_cp to store the immediates that should be promoted to const
registers before they are lowered to the preamble.
This causes one issue: the binning pass isn't allowed to modify the
const state while it's perfectly fine for it to use different immediates
compared to the non-binning pass on a7xx. Even pre-a7xx this is fine as
long as the size of the immediate buffer is the same.
To allow the binning pass to modify its immediate state while keeping
its const state immutable, this commit moves the fields related to
immediates into a new struct. Runtime checks are added to enforce that
the size of the immediate buffer is the same for the binning and
non-binning variant pre-a7xx.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32454>
The AttrAccess structure provided inputs for similar instructions, some
inputs were used only in a subset of instructions, needing asserts and
dummy values.
This commit flattens the struct directly in the instructions removing
the unused fields and cleaning up the code.
Signed-off-by: Lorenzo Rossi <snowycoder@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33899>
Currently spilling code operates on individual ops rather than on
instructions, and as a result it may create a redundant load_temp op if
an instruction references spilling register several times.
Similarly, it creates multiple stores if there are multiple ops in the
instruction that write different components of the register.
Check whether the instruction already contains a necessary load_temp or
store_temp and reuse it if possible.
shader-db:
total instructions in shared programs: 27718 -> 27673 (-0.16%)
instructions in affected programs: 2786 -> 2741 (-1.62%)
helped: 18
HURT: 0
helped stats (abs) min: 1 max: 8 x̄: 2.50 x̃: 1
helped stats (rel) min: 0.39% max: 5.33% x̄: 2.05% x̃: 0.80%
95% mean confidence interval for instructions value: -3.70 -1.30
95% mean confidence interval for instructions %-change: -3.09% -1.01%
Instructions are helped.
total loops in shared programs: 4 -> 4 (0.00%)
loops in affected programs: 0 -> 0
helped: 0
HURT: 0
total spills in shared programs: 390 -> 381 (-2.31%)
spills in affected programs: 145 -> 136 (-6.21%)
helped: 9
HURT: 0
total fills in shared programs: 1210 -> 1174 (-2.98%)
fills in affected programs: 149 -> 113 (-24.16%)
helped: 9
HURT: 0
LOST: 0
GAINED: 0
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33753>
this contains two behaviour changes:
* NDEBUG no longer set in debug builds (so asserts work in debug, but are still
stripped out in release as expected).
* macro map set properly for assertions to be reported with proper paths.
together this makes assertions do the right thing on Intel and brings us in
alignment with asahi+panfrost
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33879>
There's already code to verify that any compacted instruction
that we produce is equivalent to the original uncompacted
instruction -- including detailed output if it fails.
This patch enables this verification in debug build and will
abort in case it fails.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33821>
* ballot{,_relaxed}'s src[0] must always be a 32-bit value.
* read_invocation's src[0] must always be at most 32-bit value. While
the HW instruction always operates on a 32-bit value, it's important
to remember that it's just a data movement operation, so garbage in
the high bits of a 32-bit value representing a narrower value don't
present an issue.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33365>
All mature drivers report shader statistics in various places. GL drivers use
util_debug for shader-db's report script. VK drivers use executable statistics
feeding the report fossil script. Many drivers also have a magic env var to
dump the stats to stdout/stderr in addition to these standard forms.
Implementing any of these 3 reports requires doing brittle string processing in
C (GL, stdout) or piles of boilerplate (VK). Additionally, the logic gets
duplicated in every driver and duplicated between GL and VK.
And to add insult to injury, the information is duplicated *again* in the report
fossil script :'(
This commit introduces a new 'shader statistic framework' that aims to unify
statistics reporting across all drivers and across GL&VK. With the new approach,
a common XML file defines all the statistics for the tree. The common code
introduced here then autogenerates from that XML file an appropriate C header.
The header contains a C struct for each ISA, and autogenerated print/report
functions. Minimal driver integration is required: just filling out the stats
struct and calling the appropriate functions.
In this MR, 3 driver families are added as examples. Panfrost/PanVK and
Asahi/Honeykrisp are added as "complete" examples. Neither Vulkan driver
reported nontrivial executable statistics; with these changes, both report all
the same statistics that the GL drivers report. Turnip is also added partially -
it's not plumbed into ir3/gallium yet but just using the XML reduces boilerplate
a ton for Vulkan statistics.
[It is intended for this XML to be consumed also by shader-db's python scripts,
but that's not done here.]
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33814>
This seems to fix some artifacts, but we're not sure why, so it might not
be a correct or optimal solution.
fossil-db (navi31):
Totals from 28424 (35.81% of 79377) affected shaders:
Instrs: 30112910 -> 30348977 (+0.78%); split: -0.00%, +0.78%
CodeSize: 159542980 -> 160485336 (+0.59%); split: -0.00%, +0.59%
Latency: 221438396 -> 221500856 (+0.03%); split: -0.00%, +0.03%
InvThroughput: 38154231 -> 38159984 (+0.02%); split: -0.00%, +0.02%
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Backport-to: 25.0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33853>
The old code got the accumulation a bit wrong. For one thing, it always
accumulates with whatever was there instead of resetting to empty each
time. For another, it sets with with y and height with x when it writes
back to the resource. This is also all too complicated because it
converts between pipe_box, u_rect, and VkRect2D on every iteration.
Instead, there are helpers in util/box.h which will do most of this work
for us and they're correct. Let's just use them to get rid of the bugs
and make everything simpler and more obvious at the same time.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12194
Fixes: 3d38c9597f ("zink: hook up KHR_partial_update")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33855>
The old calculations are wrong. They add width+x and call that a width
the same with y and height. This is wrong but it's wrong in a way that
only ever increases damage so we never noticed it. However, util/box.h
has helpers for these operations which don't have this bug. Let's use
them and make the code simpler, more obvious, and correct. We also
weren't flipping the damage like we're supposed to and that was most
likely not getting noticed because of the over-damage.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33855>
In case of constant lowering with halfswizzle sources, we were selecting
h01 causing an invalid instruction error to be yield later.
This can only be hit by conversion instructions and shouldn't be seen in
the wild (as this should be eliminated before entering the backend).
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Fixes: 7d07fb9a67 ("pan/va: Handle 8-bit lane when lowering constants")
Reviewed-by: Benjamin Lee <benjamin.lee@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33867>
If we pass zink=false to pipe_loader_drm_probe_fd, it could happen that
a Gallium driver that had been already discarded because of not
supporting the graphics CAP will be chosen.
To avoid that, explicitly ask pipe_loader_drm_probe_fd to choose the
zink Gallium driver.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30096>
Exposing a rendernode from a supported driver is not a sufficient
matching criteria to qualify as the render part of a renderonly
device, as the rendernode might only expose compute or 2D accel
capabilities.
Look for a screen that actually supports gallium graphics operations
to qualify as a renderonly screen.
v2 (Tomeu): Have pipe-loader return a list of FDs for kmsro to choose
based on capabilities.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30096>
it's technically possible for a resource to have no usage but for
batch usage to be set; this can occur if a resource is used,
its cmdbuf completes, but the batch state is not reset before the
resource is used again
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33848>
This reverts commit df1ff3c711. When
clients allocate BOs via GBM's gbm_bo_create(), they expect those BOs to
work with KMS without modifiers. Assigning them a modifier and hoping
that they then query that modifier even though they used the legacy API
to create the BO is pretty mean. In particular, this breaks KWin which
doesn't use modifiers if the KMS device doesn't support atomic.
Fixes: df1ff3c711 ("zink: enable single-plane modifiers for generic 2D exports")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33887>
We clone loads for uniforms for each user, which means that each
ppir_node will have its own, however an instruction may have several
nodes that need to load uniforms. Currently, in this case ppir compiler
will place all but one load uniforms nodes into a new instruction and
create an extra mov.
We can optimize that by checking whether load_uniform node in the instruction
is the same as the one we are trying to insert and reuse it. It is safe
to do so, because successors use pipeline register, so regalloc doesn't
care about it.
shader-db:
total instructions in shared programs: 27808 -> 27718 (-0.32%)
instructions in affected programs: 2652 -> 2562 (-3.39%)
helped: 31
HURT: 0
helped stats (abs) min: 1 max: 8 x̄: 2.90 x̃: 2
helped stats (rel) min: 0.56% max: 33.33% x̄: 5.12% x̃: 4.11%
95% mean confidence interval for instructions value: -3.78 -2.03
95% mean confidence interval for instructions %-change: -7.24% -2.99%
Instructions are helped.
total loops in shared programs: 4 -> 4 (0.00%)
loops in affected programs: 0 -> 0
helped: 0
HURT: 0
total spills in shared programs: 391 -> 390 (-0.26%)
spills in affected programs: 1 -> 0
helped: 1
HURT: 0
total fills in shared programs: 1213 -> 1210 (-0.25%)
fills in affected programs: 3 -> 0
helped: 1
HURT: 0
LOST: 0
GAINED: 0
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33746>
Ideally this would be passed in pic params as the values are
in sequence header, but using the surface size also works.
Also add sanity checks for frame size.
Fixes decoding av1-1-b8-22-svc-L2T1 and av1-1-b8-22-svc-L2T2.
Cc: mesa-stable
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33737>
This change was tested on cayman. This change fixes all the tests fixed by
the evergreen commit, and fixes the 32-bits integer tests as well:
spec/arb_texture_compression_bptc/texwrap formats bordercolor-swizzled/gl_compressed_rgb_bptc_signed_float, swizzled, border color only: fail pass
spec/arb_texture_compression_bptc/texwrap formats bordercolor-swizzled/gl_compressed_rgb_bptc_unsigned_float, swizzled, border color only: fail pass
spec/arb_texture_compression_bptc/texwrap formats bordercolor-swizzled/gl_compressed_rgba_bptc_unorm, swizzled, border color only: fail pass
spec/arb_texture_rg/texwrap formats-int bordercolor-swizzled/gl_r32i, swizzled, border color only: fail pass
spec/arb_texture_rg/texwrap formats-int bordercolor-swizzled/gl_r32ui, swizzled, border color only: fail pass
spec/arb_texture_rg/texwrap formats-int bordercolor-swizzled/gl_rg32i, swizzled, border color only: fail pass
spec/arb_texture_rg/texwrap formats-int bordercolor-swizzled/gl_rg32ui, swizzled, border color only: fail pass
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33579>
This change fixes a regression introduced with 8b5d41cacb.
Indeed, lookup_resid was not updated.
This change was tested on palm and cayman. Here are the tests fixed:
khr-gl4[3-5]/shader_image_size/advanced-nonms-cs-float: fail pass
khr-gl4[3-5]/shader_image_size/advanced-nonms-cs-int: fail pass
khr-gl4[3-5]/shader_image_size/advanced-nonms-cs-uint: fail pass
khr-gl4[3-5]/shader_image_size/advanced-nonms-fs-float: fail pass
khr-gl4[3-5]/shader_image_size/advanced-nonms-fs-int: fail pass
khr-gl4[3-5]/shader_image_size/advanced-nonms-fs-uint: fail pass
khr-gl4[3-5]/shader_image_size/basic-nonms-cs-float: fail pass
khr-gl4[3-5]/shader_image_size/basic-nonms-cs-int: fail pass
khr-gl4[3-5]/shader_image_size/basic-nonms-cs-uint: fail pass
khr-gl4[3-5]/shader_image_size/basic-nonms-fs-float: fail pass
khr-gl4[3-5]/shader_image_size/basic-nonms-fs-int: fail pass
khr-gl4[3-5]/shader_image_size/basic-nonms-fs-uint: fail pass
Fixes: 8b5d41cacb ("r600/sfn: Use range_base for atomics and images")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33352>
Per https://github.com/llvm/llvm-project/issues/119967 these
headers are internal implementation details of libclc and were
never supposed to be installed. They are not available anymore
since LLVM 20. Instead opencl-c.h should be used.
There already ise a code path for including opencl-c.h, so always
use it.
This didn't work for me out of the box, because the build system
currently hardcodes the clang resource directory, which is incorrect
for Fedora at least. Fix this by using GetResourcePath +
CLANG_RESOURCE_DIR provided by clang instead. This is basically
the same as what is done in clc_helper.c
I've still retained the old behavior as a fallback just in case
(e.g. if clang is linked statically?)
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33805>
RUN_COMPUTE_INDIRECT has been found to cause intermittent hangs, so
this change replaces it with RUN_COMPUTE and a set TASK_AXIS_X.
While this task axis might be suboptimal, the performance cost is
somewhat offset by RUN_COMPUTE not being an emulated command.
Fixes: 2ffc05d8d2 ("panvk: Add support for CmdDispatchIndirect")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33841>
RUN_COMPUTE_INDIRECT has been found to cause intermittent hangs, so
this change replaces it with RUN_COMPUTE and a set TASK_AXIS_X.
While this task axis might be suboptimal, the performance cost is
somewhat offset by RUN_COMPUTE not being an emulated command.
Fixes: 447075eeee ("panfrost: Add support for the CSF job frontend")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33841>
BC250 is known to have non-functional compute queue. Thousands
for Vulkan CTS tests fail, and many games are known to have visual
glitches. RADV_DEBUG=nocompute is the known workaround for all these
issues.
Disable compute queue for this chip in both radv and radeonsi.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33116>
AMD BC-250 is a mining board based on an AMD APU with an integrated GPU
that kernel recognizes as Cyan Skillfish.
It is basically RDNA1/GFX10, but with added hardware ray tracing
support. LLVM calls it GFX1013, see
https://llvm.org/docs/AMDGPU/AMDGPUAsmGFX1013.html
Support for this GPU hasn't been extensively tested. Some games are
known to work, some non-trivial ray query compute and ray tracing
pipeline rendering works too. Q2RTX works.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33116>
Skip the zero-index perfcntr collection only if CP_ALWAYS_COUNT is used,
since we want to collect that at the very end/start of collection. But
don't unwittingly ignore that perfcntr if CP_ALWAYS_COUNT isn't being
collected.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Fixes: 86456cf0e6 ("tu: support exposing derived counters through VK_KHR_performance_query")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33852>
This change fixes the indirect draw 8-bits path which does
a conversion to 16-bits. This change is implemented to process
the parameters the same way as the other indirect draw paths.
This change was tested on palm and cayman. Here are the tests fixed:
deqp-gles31/functional/draw_indirect/draw_elements_indirect/indices/index_byte: fail pass
deqp-gles31/functional/draw_indirect/random/35: fail pass
deqp-gles31/functional/draw_indirect/random/45: fail pass
khr-gl40/draw_indirect/basic-indicesdatatype-unsigned_byte: fail pass
khr-gl41/draw_indirect/basic-indicesdatatype-unsigned_byte: fail pass
khr-gl42/draw_indirect/basic-indicesdatatype-unsigned_byte: fail pass
khr-gl43/draw_indirect/basic-indicesdatatype-unsigned_byte: fail pass
khr-gl44/draw_indirect/basic-indicesdatatype-unsigned_byte: fail pass
khr-gl45/draw_indirect/basic-indicesdatatype-unsigned_byte: fail pass
Fixes: d80701df8a ("r600g: Implement GL_ARB_draw_indirect for EG/CM")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Acked-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32802>
As explained by d80701df8a, the r600 hardware doesn't implement
the base vertex offset. This change implements this offset as a
constant buffer entry shared with lds.
This change is inspired from 3511a51be0 ("freedreno/ir3: handle
VTXID_BASE for indirect draws").
Note: this feature requires at least evergreen.
This change was tested on palm and cayman. Here are the tests fixed:
spec/arb_draw_indirect/gl_vertexid used with gldrawarraysindirect: fail pass
spec/arb_draw_indirect/gl_vertexid used with gldrawelementsindirect: fail pass
spec/arb_multi_draw_indirect/gl-3.0-multidrawarrays-vertexid -indirect: fail pass
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32769>
Add a specific timeout for the U-Boot action in LAVA job definitions for
rockchip devices. This ensures sufficient time for U-Boot to download
the kernel and set up early network, preventing potential job failures
due to timeout constraints.
This behavior started to happen since LAVA 2025.02 version.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33839>
After dae57e184a ("glsl,st/mesa: always lower IO for GLSL, unlower
IO for drivers"), the shaders updated by sfn_nir_legalize_image_load_store
on cayman could trigger a segmentation fault. The main issue is that
sfn_nir_legalize_image_load_store does not handle properly the ssa
dominance functionality and this issue is exacerbated by this last
mesa update.
This change makes the ssa dominance functionality operational.
This commit implements pass_flags to avoid an infinite loop.
For instance, this issue is triggered on cayman using this
environment variable NIR_DEBUG=validate_ssa_dominance with:
"piglit/bin/oes_egl_image_external_essl3 -auto -fbo":
NIR validation failed after r600_legalize_image_load_store in ../src/gallium/drivers/r600/sfn/sfn_nir.cpp
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32894>
Since glapi is part of libgallium.so, the offsets don't have to be immutable
anymore, but they still have to be fixed values within a build because both
gl_XML.py and genCommon.py use them and they should match AFAIK.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33634>
This fixes missing script dependencies that didn't trigger rebuilds when
those files were changed. To keep it simple stupid, all xml and python
files used by python scripts indirectly are now in a single global list.
All variables holding file names are also inlined, so that we use file
paths everywhere.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33634>
Calculation was wrongly walking uncompacted instructions, even if we had
some compacted in the middle, generating invalid size. Since we are
here just drop the instruction count, since in practice the caller will
have to walk the instruction stream anyway.
Fixes: 6267585778 ("intel/brw: Also return the size of the assembled shader")
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33532>
This GPU is located in the same host as Tahiti, and was kindly donated
to the RADV project by Leonardo Frassetto (@DottorLeo).
It's good to finally making use of it, one year after receiving it \o/
On a side now, the skips are removed since they do not appear to be
reducing the chances of hanging once paired with the updated postamble
flushes.
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33563>
After nir_lower_io we need to gather the info about 64 bit usage
to be up-to-date when deciding whether the remaining 64 bit IO ops
be lowered.
Before 89dad5618d ("gallium: add PIPE_CAP_CALL_FINALIZE_NIR_IN_LINKER")
the info was eventually updated to include the use of 64 bit values
also if only some IO was using this so that SFN was handling the code
correctly. As it seems with above patch this is not always the case
anymore, and we have to take care of it.
Fixes: 89dad5618d ("gallium: add PIPE_CAP_CALL_FINALIZE_NIR_IN_LINKER")
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32774>
Turnip's current VK_KHR_performance_query implementation only exposed raw
perfcounters. These aren't exactly trivial to evaluate on their own.
This mode can still be used with the new TU_DEBUG_PERFCRAW flag. Existing
TU_DEBUG_PERFC now enables performance query mode where Freedreno's derived
counters are exposed instead. These default to using the command scope,
making them usable with RenderDoc's performance counter capture.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33208>
Freedreno's derived counters combine multiple perfcntrs into a more
sensible, human-friendly metric. This change picks up the counters
currently used in Freedreno's Perfetto producer and rolls them into a
more genericallly usable form.
First place of their use will be through VK_KHR_performance_query, but
the Perfetto producer should also be able to use this interface instead
of having the logic duplicated. For now the counters are available only
for a7xx devices.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33208>
When using vkGetQueryPoolResults for performance queries, the result of
each query is the VkPerformanceCounterResultKHR union, and the result of
each query should be written into that union according to the storage type
of the corresponding counter.
This fixes current behavior of using the generic write procedure, where
either 32-bit or 64-bit value is written depending on the specified query
result flags.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33208>
We currently keep a0.x/a1.x unnecessarily blocked until we have to spill
it, even if all its uses have been scheduled already. This causes
unnecessary spills and potentially schedules address writes later than
we'd like.
Fix this by keeping track of the number of uses that are still
unscheduled, unblocking address writes when it drops to zero.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33816>
This step is needed to support the same GPU model, but with a
different revision. A good example is the gc7000.
- imx8mp: model gc7000 with revision 6204 (uses RS)
- imx8mq: model gc7000 with revision 6214 (uses BLT)
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33811>
every vk driver wants these macros for executable statistics, so make them
common. there are two variants floating in-tree, a pure copy (radv) and a
formatted print (everyone else). we add both variants and then convert most
prints to copies where formatting isn't actually used. that has the benefit of
cleaning up trivial "%s" format strings in a bunch of places.
I didn't bother cleaning up the formatting in non-automatic-formatted drivers
because it's tedious and I'm planning to delete a lot of this driver code with
upcoming runtime work anyway. This is a step towards those runtime improvements.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33826>
Android's Vulkan loader provides KHR_android_surface and intercepts
during instance creation; it does not implement KHR_present_[wait/id]
nor does it pass the enablement of KHR_android_surface to the driver
so this check wasn't actually disabling KHR_present_[wait/id] for
Android.
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33677>
> Allowing 1D and 3D images, and array images too, with DRM_FORMAT_MOD_LINEAR, is ok
> because VkImageDrmFormatModifierExplicitCreateInfoEXT::pPlaneLayouts is able to fully
> describe the image layout. IF miplevels == 1, which this patch continues to enforce.
Reviewed-by: Lina Versace <lina@kiwitree.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33668>
this is a nice idea, but there are apps/games that do not respect
hardware capabilities and yolo-bind fixed size buffers
fixes Ballionaire (2667120) launch on non-desktop drivers
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33819>
Beyond that, monolithic pipelines just bloat to incredible sizes,
destroying compile times for questionable, if any, runtime perf benefit.
Indiana Jones: The Great Circle has more than 100 stages and takes
several minutes to compile its RT pipeline on Deck when using monolithic
compilation, and yet separate shaders still end up faster (probably
because instruction cache coherency in traversal is better).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33818>
The first test verifies that, if possible, we don't emit unnecessary
renames/copies for temporaries where it's possible for them to stay
in their current register (if an operand is precolored to the register
the temporary is currently residing in).
The second test verifies that we correctly choose a non-clobbered
operand even if there is one fixed to the temporary's current register.
To minimize copies, we'll want to have the live copy of
%tmp0 in v[2] there, because v[0-1] gets overwritten.
The third test verifies that we add a copy to another free register and
rename if all possible precolored operands are clobbered.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29576>
These traces are now stable enough to start running them again on TGL.
Additionally, add new lines between traces in preparation for adding
ADL coverage, and update zink-anv-tgl-traces-restricted to no longer
inherit rules from zink-anv-tgl-traces.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33793>
We would set the `src` flag on the interval of reloaded sources.
However, the interval might be merged with its parent when inserted and
the parent wouldn't have this flag set. This caused the parent interval
to potentially be reused to reload later sources. Fix this by setting
the `src` flag on the top-level interval after insertion.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: fa22b0901a ("ir3/ra: Add specialized shared register RA/spilling")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33810>
Now that every ANGLE use is covered by tag consistency checks
(structured tagging), we don't need the USE_ANGLE flag anymore, because
if we have ANGLE_TAG set, it means that ANGLE is required in this job.
In detail, it means that the test job has inherited ANGLE_TAG from
`.container-builds-angle`.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33421>
Make structural tagging functions available for both test and build
scripts.
Introduces the update_tag.sh helper for listing, checking, and updating
deterministic tags.
Also adds the ci_tag_build_time_check and ci_tag_test_time_check
functions to validate tags during build and test phases, ensuring
consistent component versioning.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33421>
Alias are not exportable, in the current situation of the build scripts,
we use alias to deal with sections, but it infers that all build scripts
will be included in a bigger one that has already included
`setup-test-env.sh`.
With the structured tagging, we do a dry run of all build scripts, to
early check if the tagging is valid, before building stuff.
So changing alias to functions will not have an effect on the current
setup, but it also removes the need to reinclude library bash scripts in
some situations, as described above.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33421>
The android_build.sh script was not calling the container_pre_build.sh
and container_post_build.sh, we will need that to make the structural
tagging early checking to work. And also do the same cleanup and
configuration made for other container build jobs.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33421>
When spilling values, we can detect when a value is known to be constant
and avoid spilling it out to memory and/or GPRs by just re-materializing
the constant value instead of filling.
Shader-db stats:
Totals:
CodeSize: 30101168 -> 30052896 (-0.16%); split: -0.19%, +0.03%
SLM size: 146536 -> 146524 (-0.01%)
Static cycle count: 6952994 -> 6939532 (-0.19%); split: -0.30%, +0.10%
Spills to memory: 174139 -> 173625 (-0.30%)
Fills from memory: 174139 -> 173625 (-0.30%)
Totals from 555 (8.05% of 6891) affected shaders:
CodeSize: 18945520 -> 18897248 (-0.25%); split: -0.30%, +0.04%
SLM size: 128952 -> 128940 (-0.01%)
Static cycle count: 4344118 -> 4330656 (-0.31%); split: -0.47%, +0.16%
Spills to memory: 174139 -> 173625 (-0.30%)
Fills from memory: 174139 -> 173625 (-0.30%)
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33785>
Fixes: 692b5fa9f2 ("anv: Add shader to copy acceleration structures")
This commit fixes the future test "sparse_binding_structures" for
"header_bottom_address" for ray tracing pipeline.
Even on 48-bit ray tracing (Xe1/2), the software-defined part
instance_leaf_part1.bvh_ptr has to be in canonical form for copy.comp
to deference a bvh, which means we have to preserve the upper 16bits.
This is especially relevant in cases where the acceleration structure buffer
is located high, such as sparse buffer.
Signed-off-by: Kevin Chuang <kaiwenjon23@gmail.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33745>
Fixes: 2fe57947e3 ("anv: Implement encode shader to fit in ANV BVH")
This commit resolves the failures in the future tests
"sparse_binding_structures" for rayquery. Sparse buffers' heaps are
located high, and since it's in canonical form, the higher 16bits are
all set to 1. However, the existing encoder did not expect any non-zero
values at the higher 16bits. As a result, the instance flags got
corrupted, causing most triangle tests to fail.
Thanks for Paulo providing insights about sparse buffer properties.
Co-developed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Kevin Chuang <kaiwenjon23@gmail.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33745>
... since `BoxedHandleManager` should, well, manager the handles.
This simplifies `VkDecoderGlobalState` a little bit and should also
allow us to remove a bunch of functions that no longer need to
depend on `VkDecoderGlobalState`.
Test: cvd create --gpu_mode=gfxstream_guest_angle_host_swiftshader
Test: cvd snapshot_take --force \
--auto_suspend \
--snapshot_path=/tmp/snapshot1
Test: cvd reset -y
Test: cvd create --snapshot_path=/tmp/snapshot1
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33740>
Add vkGetFenceStatus and vkWaitForFences functions to the
global state tracking list for the host.
This will allow adding more functionality to the fences
and perform additional operations before waiting for and
signaling them.
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33740>
... to break the recursive behavior of the replay calling into
VkDecoderSnapshot so that locking and thread safety annotations can be
preserved in VkDecoderSnapshot.
Follow up to aosp/3412302.
Test: cvd create --gpu_mode=gfxstream_guest_angle_host_swiftshader
Test: cvd snapshot_take --snapshot_path=<>
Test: cvd create --snapshot_path=<>
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33740>
Bifrost LDEXP.v2f16 takes a 16-bit exponent, which requires messy
lowering. The codegen for this is quite bad currently, but would be
improved by implementing unpack_32_2x16_split_*, and by fusing
comparisons with CSEL.
The main alternative is converting to F32, then LDEXP.f32, then
converting back to F16. This has better codegen for dynamic exponents
currently, but worse in the common case with a constant exponent where
all the saturating cast logic can be folded.
Fixes dEQP-VK.glsl.builtin.precision_fp16_storage16b.ldexp.compute.vec2
when shaderFloat16 is enabled in panvk.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33637>
On vulkan, truncating to S/U16 before converting is not valid, because
out-of-range conversions are specified to be correctly rounded. IEEE 754
requires that out-of-range values round to ±inf with RTNE and ±F16_MAX
with RTZ.
On gl, truncating is valid for U16->F16, because out-of-range int->float
conversions are undefined behavior. For S16->F16, it is not valid
because S16_MAX < F16_MAX, so some in-range values will be truncated as
well.
Instead, just handle S/U16->F16 as S/U16->F32->F16.
Fixes dEQP-VK.spirv_assembly.instruction.compute.convertstof.int32_to_float16_*
when shaderFloat16 is enabled in panvk.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Fixes: be74b84e6f ("pan/bi: Fill in some more conversions")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33637>
Right now the aliasing/overlapping checks are only done with index
0. I guess that was done because variables don't get a different
internal location even if you have a different index.
But doing that, the checks would not detect a case like this:
layout(location = 0, index = 1) out vec4 color;
layout(location = 0, index = 1) out vec4 factor;
That was used on the following piglit parser test:
spec/arb_explicit_attrib_location/1.10/compiler/layout-13.frag
And as the spec included on that test, is a link error case:
" * if more than one varying out variable is bound to the same
number and index; or"
This commit executes the aliasing checks for index 1 too, and moves
the skip down, to only skip if the current variable and all previous
location-assigned variables has different index and location.
The bad news is that now such assigned variables need to be tracked on
OpenGL-ES. Before that commit that was avoided.
With this commit the mentioned parser test properly fails to link in
any driver.
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33093>
If we insert
<code>
s_branch 1
s_branch Target
at the end of some block, and later hide an additional chained branch
after the existing one, then we have to update the 's_branch 1' to
also jump over the newly added branch.
Fixes: cab5639a09 ('aco/assembler: chain branches instead of emitting long jumps')
Closes: #12673
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33762>
Venus has long supported creating swapchain image alias via binding. So
below are exposed without extra work needed:
- VK_EXT_surface_maintenance1
- VK_EXT_swapchain_maintenance1
Test: dEQP-VK.wsi.*.maintenance1.*
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33782>
Our name for this enum was brw_message_target, but it's better known as
shared function ID or SFID. Call it brw_sfid to make it easier to find.
Now that brw only supports Gfx9+, we don't particularly care whether
SFIDs were introduced on Gfx4, Gfx6, or Gfx7.5. Also, the LSC SFIDs
were confusingly tagged "GFX12" but aren't available on Gfx12.0; they
were introduced with Alchemist/Meteorlake.
GFX6_SFID_DATAPORT_SAMPLER_CACHE in particular was confusing. It sounds
like the SFID to use for the sampler on Gfx6+, however it has nothing to
do with the sampler at all. BRW_SFID_SAMPLER remains the sampler SFID.
On Haswell, we ran out of messages on the main data cache data port, and
so they introduced two additional ones, for more messages. The modern
Tigerlake PRMs simply call these DP_DC0, DP_DC1, and DP_DC2. I think
the "sampler" name came from some idea about reorganizing messages that
never materialized (instead, the LSC came as a much larger cleanup).
Recently we've adopted the term "HDC" for the legacy data cluster, as
opposed to "LSC" for the modern Load/Store Cache. To make clear which
SFIDs target the legacy HDC dataports, we use BRW_SFID_HDC0/1/2.
We were also citing the G45, Sandybridge, and Ivybridge PRMs for a
compiler that supports none of those platforms. Cite modern docs.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33650>
This is part of the hashing key :
==25753== Uninitialised byte(s) found during client check request
==25753== at 0x93D29AE: blob_write_bytes (blob.c:164)
==25753== by 0x93A62C6: vk_pipeline_precomp_shader_serialize (vk_pipeline.c:722)
==25753== by 0x93AC55E: vk_pipeline_cache_add_object (vk_pipeline_cache.c:433)
==25753== by 0x93A691B: vk_pipeline_precompile_shader (vk_pipeline.c:875)
==25753== by 0x93A8FB9: vk_create_graphics_pipeline (vk_pipeline.c:1715)
==25753== by 0x93A9799: vk_common_CreateGraphicsPipelines (vk_pipeline.c:1860)
==25753== Address 0xf1adf82 is 82 bytes inside a block of size 152 alloc'd
==25753== at 0x64FA858: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==25753== by 0x99AAC38: vk_default_alloc (vk_alloc.c:26)
==25753== by 0x93A403B: vk_alloc (vk_alloc.h:48)
==25753== by 0x93A406B: vk_zalloc (vk_alloc.h:56)
==25753== by 0x93A60A0: vk_pipeline_precomp_shader_create (vk_pipeline.c:680)
==25753== by 0x93A689D: vk_pipeline_precompile_shader (vk_pipeline.c:866)
==25753== by 0x93A8FB9: vk_create_graphics_pipeline (vk_pipeline.c:1715)
==25753== by 0x93A9799: vk_common_CreateGraphicsPipelines (vk_pipeline.c:1860)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 9308e8d90d ("vulkan: Add generic graphics and compute VkPipeline implementations")
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33792>
This is useful both for correctness (to ensure that things we think are
constant stay constant) and it improves performance a bit by reducing
register pressure and avoiding spilling.
Pipeline-db stats:
CodeSize: 29665072 -> 29437344 (-0.77%); split: -0.92%, +0.16%
Number of GPRs: 157124 -> 156082 (-0.66%)
SLM Size: 148900 -> 146436 (-1.65%)
Static cycle count: 6840286 -> 6805711 (-0.51%); split: -0.98%, +0.47%
Spills to memory: 177779 -> 173337 (-2.50%)
Fills from memory: 177779 -> 173337 (-2.50%)
Spills to reg: 17692 -> 16731 (-5.43%)
Fills from reg: 12013 -> 11897 (-0.97%)
Max warps/SM: 309128 -> 309456 (+0.11%)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33771>
I'm not aware of any workloads that will be impacted by this change,
but let's keep our list of control flow instructions complete. A
shader-db run on MTL tells me nothing changes.
v2: "The scheduler relies on HALT not being considered control flow to
be able to move code past HALT instructions. Doing this would prevent
such optimization from happening and would reduce performance
dramatically in some cases." - Francisco.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33021>
In `fossilize-replay --pipeline-hash 375a63e14afa96c4
fossils/fossil-db/steam-dxvk/f1_22_abu_dhabi.dx12vk-ultra.foz`,
`cf_count` would get decremented below zero. This would lead trying to
print `UINT_MAX` levels of indentation just a few lines below. I ran
out of disk space and patience before that finished. 🤣
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33748>
For setters, e.g. vk_set_physical_device_properties_struct used by venus
to fill all props, the out array storage comes from the driver, so we'd
assign directly. This change also fixes the template indent and drops an
unused arg.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33757>
The img-2-img and layout transition are trivial passthrough. For
img-2-mem and mem-2-img copies, host pointer has to be sized for proper
protocol encoding and decoding, and we have to either query or calculate
on our own based on VK_HOST_IMAGE_COPY_MEMCPY_EXT flag being used or
not.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33757>
No need to burn an entire PAGE_SIZE BO for an event. And in particular
the pattern of allocate + immediate mmap is expensive in a VM.
Suballocating cuts down the # of times we do this in
dEQP-VK.api.command_buffers.execute_large_primary from 10000 to 157,
avoiding problems with the test running up against watchdog timeout.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33721>
The issue with using video buffer associated data is that the data will
not be cleared when the buffer is removed from DPB. This will cause
issues if application tries to reuse such buffer (buffer that was
valid buffer in DPB in the past, but is currently not active in DPB)
as a dummy buffer for missing reference.
With Tier2 this works correctly because we allocate the DPB buffers
internally, but with UDT we use the video buffers directly for
references and so we need to make sure to only use the valid buffer
for a given index.
Instead of storing the buffer index as video buffer associated data,
use the render_pic_list array that we already have for keeping track
of active buffers in DPB.
Acked-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33641>
There are some tests that reaches out of memory (OOM) on purpose to
cover some fail cases.
But others that shouldn't are actually causing OOM too because we run
multiple tests in parallel, which increases the memory pressure.
This can affects other tests running in parallel, causing an increase of
the flakiness.
It is better to skip all of them
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33763>
It looks like even if we pass the header not present in the sampler descriptor,
it's not helping with the correct behavior of texelFetch.
Experiment on real HW shows that if we just zero out the header and include it
in the message, it helps with the correct behavior. I'm not sure if there is a
valid HW workaround for this one.
We can skip masking the sampler message header bits 4:0 but masking them out
doesn't hurt in this case.
Increasing number of parameter impact sampler performance, For example,
a sample message using 5 parameters will not be able to sustain the same
throughput as a sample message with only 4 valid parameters. We should
look out for any perf impact with respect to texel fetch.
This patch fixes ~3k tests involving texelFetch instruction on Xe3+
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33562>
If we have a single instruction that uses only combiner unit and previous
instruction doesn't use this unit, two instructions can be safely merged.
Implement compactification pass to do that.
The pass doesn't update instruction dependencies, so it should be run
right before codegen.
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33570>
By actually setting the state packets according to the program data.
Also ensure that we correctly flag that the program may be dirty when
the geometry shader state changes
Fixes piglit tests: `spec@!opengl 3.2@gl-3.2-adj-prims * pv-first`
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Backport-to: 25.0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33658>
Introduce an optimizer for ppir with 3 passes:
1) remove empty blocks: this one currently doesn't have any effect on
code generation, but it's required by other passes
2) remove redundant mov that is generated for store_output intrinsic when
possible
3) dead code elimination
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33636>
Discard block is the only block that we generate internally, and it
currently just gets an index of 0 which collides with the very first
block. It is not an issue for compiler, but an eyesore for debug output
for a program with discard_if.
Assign INT_MAX index for it.
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33636>
Currently regalloc doesn't mark write destinations in the single
instructions as conflicting, as a result regalloc may assign the same
register to a multiple write destinations.
Before we started scheduling multiple root nodes into a single instruction
it was pretty much hidden. Fix it by marking destination registers as
conflicting if instruction has multiple writes.
Also stop handling a special case for output registers in regalloc and just
mark them as live in the last instruction of "stop" block(s)
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33636>
Recently, Indiana Jones and The Great Circle messed up this by adding
duplicates and this was causing the game to crash at launch.
Of course, this was an application bug that VVL was also able to catch
but I think maybe Mesa should ignore those instead of failing to create
the logical device.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33705>
The number of bound vertex buffers is now always equal to the number of
used buffers in the vertex elements state even if some buffers are NULL.
set_vertex_buffers doesn't unbind [count..last_count-1] buffers anymore.
bind_vertex_elements_state does that. It lets us remove code from
si_set_vertex_buffers.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27736>
Setting vertex elements before vertex buffers is a new requirement of gallium.
This is the only way to set the vertex elements state after vertex buffers
in st/mesa while setting the state before vertex buffers in tc_batch_execute.
A new TC call is added to set both vertex elements and vertex buffers.
Vertex buffers are filled by st/mesa first, and then the vertex elements
state is set in the same call. When TC calls it, it binds vertex elements
before vertex buffers.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27736>
Otherwise, the UUID changes for games that have shader-based drirc
workarounds and this breaks precompiled shaders on SteamDeck.
Instead, use this pdev cache key to compute the logical device hash
which is common to all pipelines.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33717>
As reported in issue #11825 the code that is meant to clean up old
cache dirs actually ends up creating an empty dir due to reusing
existing code to create the cache path required for the potential
cleanup.
Here we make the code more flexible allowing cache path strings
to be returned by the helpers if the directory already exists
or returning NULL if we don't want to create a new directory.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11825
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33699>
Make the "block after DO" more stable so that adding instructions after
a DO doesn't require repairing the CFG. Use a new SHADER_OPCODE_FLOW
instruction that is a placeholder representing "go to the next block"
and disappears at code generation.
For some context, there are a few facts about how CFG currently works
- Blocks are assumed to not be empty;
- DO is always by itself in a block, i.e. starts and ends a block;
- There are no empty blocks;
- Predicated WHILE and CONTINUE will link to the "block after DO";
- When nesting loops, it is possible that the "block after DO" is
another "DO".
Reasons and further explanations for those are in the brw_cfg.c comments.
What makes this new change useful is that a pass might want to add
instructions between two DO instructions. When that happens, a new
block must be created and any predicated WHILE and CONTINUE must be
repaired.
So, instead of requiring a repair (which has proven to be tricky in
the past), this change adds a block that can be "virtually" empty but
allow instructions to be added without further changes.
One alternative design would be allowing empty blocks, that would be
a deeper change since the blocks are currently assumed to be not empty
in various places. We'll save that for when other changes are made to
the CFG.
The problem described happens in brw_opt_combine_constants, and a
different patch will clean that up.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33536>
We never write the traversal shader address out to shader group handles,
so this is not necessary. On the flipside, it can cause conflicts if the
traversal shader is allocated in a range occupied by a replayed shader.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33711>
as previously discussed.
this is using "library CL" instead of kernel CL, which is the older way of doing
things. it works, it just has more boilerplate per-kernel than we'd want
otherwise. but library CL is basically free to integrate into a driver, whereas
kernel CL requires a lot more upfront investment. (I'm working on cleaning that
up but we're not quite there yet.)
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33362>
With some of the jobs migrated to the new brask and nissa devices, we can
increase zink-on-anv coverage on brya. Reduce the fraction of Piglit
tests and introduce fractional GLESCTS testing.
Also increase the parallelism of the zink nightly job, but lower its
FDO_CI_CONCURRENT variable to avoid OOMkills. To accommodate this,
decrease the parallelism of the anv-adl-full job.
Additionally, drop redundant HWCI_START_WESTON from full runs that
inherit the variable from their pre-merge jobs.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33671>
FDO_CI_CONCURRENT was getting overwritten by .intel-common-test
inheriting FDO_CI_CONCURRENT: 6 from .lava-test, so change the order of
these definitions to fix that.
This change unfortunantely means that GPU_VERSION has to be overwritten
in some cases.
Additionally, drop redundant .anv-test where .anv-angle-test is used.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33671>
Instead, only indicate that exec should be zero and do
so in the successive helper block. This allows to insert
the parallelcopies from logical phis directly before the
branch in break and continue blocks.
Totals from 56 (0.07% of 79377) affected shaders: (Navi31)
Latency: 2472367 -> 2472422 (+0.00%); split: -0.00%, +0.00%
InvThroughput: 253053 -> 253055 (+0.00%); split: -0.00%, +0.00%
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33527>
A proper emulation of a second queue requires handling of
wait-before-signal behavior of timeline semaphore. It's doable in Venus
but not that much useful since 1.4 requires a second transfer queue
family if not implementing hostImageCopy. So this change has limited
the second queue emulation as a workaround for android framework on
Android 14 and above.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33698>
There is a spec issue about this to clarify this behavior, but the current
wording can be interpreted that the platform always lists all extensions
supported by all drivers.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33667>
What we need is a way to tell GitLab "queue `build-only` jobs after
`build-for-tests` jobs have started", to make sure that `build-only`
jobs don't start before `build-for-tests` jobs and thus delays test jobs
and the overall pipeline.
The best I had found was "queue `build-only` jobs after *all* the
`build-for-tests` jobs have finished", but this introduces a larger
delay than we want, and causes `build-only` jobs to often be the last
ones to finish in a pipeline, after test jobs that respect the 15min
runtime limit.
Instead, we can tell GitLab "queue `build-only` jobs after the
`build-for-tests` jobs have been queued for X minutes", which is closer
to what we want, and in particular this ensures the correct order of
*starting* jobs as long as the CI is not overwhelmed and doesn't manage
to actually start a queued `build-for-tests` job within 5min, in which
case I'd argue we don't care about job order anymore because we have
bigger problems anyway and likely everything's going to timeout.
This also gets rid of the hard-to-maintain `.build-for-tests-jobs` list
of `needs:`, which also needed to be manually merged in half the jobs.
The trade-off is that we need to make a (shallow) copy of the
`.container+build-rules` list, that replaces all the `when: on_success`
with `when: delayed` + `start_in: 5 minutes`. This means that we'll need
to make sure the two lists of conditions remain identical, but this
seems more manageable; nevertheless, I added a comment to remind us.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33564>
Imported linear images may have an arbitrary row pitch. As long as it is
aligned to 16 agx can support. Initialize `.linear_stride_B` from the
supplied parameter and let ail verify it.
Fixes gtk dmabuf based tests with a pitch aligned to 256.
Signed-off-by: Janne Grunau <j@jannau.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33682>
`command_count` is under control of the vulkan application and can
become quite large. At a command count around 30000 the size of the
alloca() allocated buffers exceeds the default stack size of 16MB.
Fixes fixes segfaults in 'gtk:compare vulkan lots-of-offscreens-nogl*'
gtk 4 test cases which end up with a `command_count` around 32768.
Fixes: https://gitlab.freedesktop.org/asahi/mesa/-/issues/47
Signed-off-by: Janne Grunau <j@jannau.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33682>
libwrap.dylib is helpful to trace control streams on macOS. When it was
originally implemented, we..
* supported macOS in our OpenGL driver and needed to actually exercise these
interfaces
* didn't have Linux support or hypervisor support or anything so needed the
traces to be utterly thorough
* only had a single macOS version to worry about
The landscape today is very different
* no macOS support in our driver stack
* we can trace registers via the hypervisor - libwrap.dylib is no longer
"correctness" bearing, it's just a convenience tool
* what counts is the hardware side - tracing all the macOS software structs is
not actually useful, the hypervisor is the right place to grab control regs
* piles of macOS versions, this code only ever worked properly on 11.x and 12.x,
but with m4 r/e coming up soon we need a lot more versions working.
So... we keep around libwrap.dylib, but slim it down to only decode the bare
minimum of macOS versioned structures, just enough to grab the control stream
pointer and dump that. This is a loss of functionality around CRs (but we have the
hypervisor as a much better way to grab CRs). In exchange it makes the code much
more manageable and less likely to break every 6 months.
So in exchange for all this deletion we also get things working again, this time
on 13.x. But porting back to 12.x or 11.x would be a very small diffstat given
the reduced focus of the new code.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33682>
I dumped assembly generated by our driver with INTEL_DEBUG=shaders,
copied and pasted it into a lua file, tried to run it with
src/intel/executor, but the disassembler started telling me some
instructions were invalid.
This happened because we print the "compacted" flag in our assembly
text, so when brw_gram.y parses our assembly flag, it sees the
"compacted" flag and sets it to the instruction by calling
add_instruction_option(). But the executor tool never sets the
BRW_ASSEMBLE_COMPACT flag when it calls brw_assemble(), so when
brw_assemble() calls dump_assembly(), which calls brw_disassbemble(),
the disassembler gets confused and prints misinterpreted instructions
and calls them invalid.
It is not the job of brw_gram.y (our text assembly parser) to mark
instructions as compacted. Whatever is later assembling the
instruction is the entity that should decide if the instructions are
compacted or not. So in this patch we just ignore this flag.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33614>
The kernel+rootfs jobs previously downloaded the prebuilt kernel iamge,
but this was unnecessary as LAVA doesn't use them here, and the images
were never uploaded to S3. LAVA acquires the kernel in lava_submit.sh,
and baremetal downloads the required images and dtbs in baremetal_build.sh.
The kernel modules are still required for some devices.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33606>
Turns out we were missing the glapi bits, making it impossible to use get
the function pointers for this extension. Whoops?!
[daniels: Squashed in a618 SkQP fails, presumably caused by these not
being skipped anymore.]
Fixes: 9f5af68995 ("mesa/main: expose `EXT_multi_draw_indirect`")
Reviewed-by: Antonino Maniscalco <antomani103@gmail.com>
Tested-by: Chris Healy <healych@amazon.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33546>
Add support to rewrite shared atomics into compare-and-swap loops,
previously the nir_lower_atomics pass only supported global and ssbo
atomics.
Only freedreno irc3 reuses nir_lower_atomics, this change does not
impact their usage since they do not support shared atomics.
Signed-off-by: Lorenzo Rossi <snowycoder@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33572>
Adding the b2i(a) == 1 and b2i(a) != 1 patterns also helps prevent
regressions when spurious negations are removed from integer equality
comparisons, as is done in !33498.
v2: Make all variables part of the iteration instead of calculating some
of them. Suggested by Alyssa.
shader-db:
All Intel platforms had similar results. (Lunar Lake shown)
total instructions in shared programs: 16973331 -> 16973309 (<.01%)
instructions in affected programs: 266 -> 244 (-8.27%)
helped: 2 / HURT: 0
total cycles in shared programs: 915620774 -> 915620550 (<.01%)
cycles in affected programs: 4360 -> 4136 (-5.14%)
helped: 2 / HURT: 0
fossil-db:
All Intel platforms had similar results. (Lunar Lake shown)
Totals:
Instrs: 209748011 -> 209748003 (-0.00%)
Cycle count: 30514920286 -> 30514920400 (+0.00%); split: -0.00%, +0.00%
Non SSA regs after NIR: 237334726 -> 237334710 (-0.00%)
Totals from 8 (0.00% of 706651) affected shaders:
Instrs: 16956 -> 16948 (-0.05%)
Cycle count: 261052 -> 261166 (+0.04%); split: -0.92%, +0.96%
Non SSA regs after NIR: 20000 -> 19984 (-0.08%)
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33648>
At least some Total War: Warhammer3 vertex shaders associate the
comparisons differntly, so the existing patterns were not triggered.
No shader-db changes on any Intel platform.
fossil-db:
All Intel platforms had similar results. (Lunar Lake shown)
Totals:
Instrs: 209748654 -> 209748173 (-0.00%)
Cycle count: 30514333964 -> 30514361348 (+0.00%); split: -0.00%, +0.00%
Fill count: 622688 -> 622537 (-0.02%)
Max live registers: 65477039 -> 65477033 (-0.00%)
Non SSA regs after NIR: 237334768 -> 237334728 (-0.00%)
Totals from 512 (0.07% of 706651) affected shaders:
Instrs: 1000693 -> 1000212 (-0.05%)
Cycle count: 42174312 -> 42201696 (+0.06%); split: -0.15%, +0.21%
Fill count: 11456 -> 11305 (-1.32%)
Max live registers: 121599 -> 121593 (-0.00%)
Non SSA regs after NIR: 1253445 -> 1253405 (-0.00%)
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33648>
These are persistant objects that you can use to signal and wait over.
We need to import without VK_SEMAPHORE_IMPORT_TEMPORARY_BIT and we can't
throw away the Vulkan semaphore after each submit.
Fixes: 32597e116d ("zink: implement GL semaphores")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33549>
When the size of the signals[] array was changed to 3, the
signal_values[] array was not updated accordingly. If we have a
signal_semaphore and are presenting at the same time, this can lead to
an array overflow and the driver will read some random stack value as
the signal value. This is causing chromium to lock up when running
WebGL.
Fixes: 7f56fd9655 ("zink: it's kopperin' time")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33549>
From the Vulkan documentation, the queueFamilyIndex value will be
created with VkDeviceQueueCreateInfo. So let's avoid counting the
index value and just refer to the already-created value.
This will resolve crashes on some GPUs for various workloads.
v2: Needed to use GetDeviceQueue() in order to map the queueFamilyIndex
values. These values can be different when obtaining the queue used
for presentation, so we need to ensure we update the mapped
queueFamilyIndex value for the associated queue_data struct.
Signed-off-by: Casey Bowman <casey.g.bowman@intel.com>
Reviewed-by: Felix DeGrood <felix.j.degrood@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33487>
Not sure if this was intentionally left when block_check_for_allowed_instrs's
param was changed from bool to int, but it certainly was broken without the
previous commit for discards. Now those should work, so the (unintentional?)
special case can be removed.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33590>
MemScope::System has to synchronize with everything in the system,
including across PCIe so it's horribly slow. MemScope::GPU, on the
other hand, only has to synchronize within the GPU. This is way faster
and still satisfies all of Vulkan's requirements because Vulkan never
allows CPU<->GPU access without full semaphores and barriers.
Reviewed-by: Mel Henning <drawoc@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33649>
Implementing alpha-to-coverage dithering broke the non-dithering case.
(Discovered by accident, not really a big deal since it's almost always
enabled and can only be disabled by using a Nvidia GL extension, and
can't be disabled with Vulkan.)
Fixes: ad4635d6ef
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33586>
This hasn't been hooked up to the build since we deleted autotools back
in 2019. It's effectively dead code anyway, as GLX is not a moving
target, and at this point is it easier to modify the generated code
directly than to modify the generator. xserver is encouraged to copy
the generators from 2019 into its own build if it wants, or -
preferably, in this GLX greybeard's opinion - find a prettier codegen
solution in the process of finishing GL 3.0 support.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33623>
Using memcpy with the max size generates a global-buffer-overflow, as
the performance counter strings are smaller than the max size.
Instead, use a string copy function to get a copy.
This was detected with address sanitizer enabled and running vulkaninfo.
Fixes: 3e8b2fe053 ("broadcom/simulator: Add DRM_IOCTL_V3D_GET_COUNTER to simulator")
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33627>
We can't use the local variable key to insert in the hashtable, as the
key needs to be persistent for future searches.
This makes a copy of the key in the pipeline, which is kept persistent
in the hashtable.
This fixes a stack-buffer-overflow.
Backport-to: 25.0
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33630>
_mesa_make_current will use st_flush(ctx) to execute pending
commands before switching to the new context.
Since we can't have multiple threads using a pipe_context at
the same time, we must finish glthread to avoid having the
unmarshalling thread executing at the same time.
It's fixing random crashes where a thread would do:
st_destroy_context ->
_mesa_make_current ->
st_glFlush(save_ctx) ->
tc_execute_batch
While there's a glthread unmarshalling thread that's still
adding commands to TC.
Fixes: 08d97aadd1 ("st/mesa: fix texture deletion context mix-up issues (v2)")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33552>
On v11+, V2F32_TO_V2F16 doesn't exist anymore.
This commit ensure we stop using it on every codepath except when a
vectored conversion is prefered. (v9-v10)
Instead, we use FADD.F32 to handle data conversion thanks to the
swizzle defined for the destination.
This also work on older Valhall gens, so let's follow that
logic when we only have one component used.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33608>
Validation was checking that if an instruction was accessing FAU RAM,
only one 64-bit slot was accessed, and if it was accessing a FAU special
value, only one was accessed, however it was not checking if both RAM
and special were used, which is only allowed in messaging instructions
except ATEST and BLEND.
Fixes Piglit:
spec/ati_fragment_shader/ati_fragment_shader-render-ops/mov c0.r
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Fixes: fd1906afea ("pan/va: Add FAU validation")
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33608>
Previously deqp tests with *.multisampled_image_sparse_residency.* would
crash with "Unknown image intrinsic" because
nir_intrinsic_bindless_image_sparse_load was not handled in the lowring
code.
This commits handles MSAA sparse residency lowering as with other cases.
Signed-off-by: Lorenzo Rossi <snowycoder@gmail.com>
Fixes: 7604697ec6 ("nvk: Implement shaderStorageImageMultisample")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33625>
Add support for GL_OVR_multiview's GL_MAX_VIEWS_OVR which can be
accessed with glGetIntegerv().
MaxViews is accessed via the hash table set up by get_hash_params.py as
a constant (MAX_VIEWS_OVR) using GL_MAX_VIEWS_OVR.
v2: Add this patch (thanks to Mike's guidance)
v3: Drop unnecessary enum size element in OVR_multiview.XML
v4: Switch to CONST(MAX_VIEWS_OVR) instead of gl_constants::MaxViews
(Marek's suggestion)
Fixes: 328c29d600 ("mesa,glsl,gallium: add GL_OVR_multiview")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: James Hogan <james@albanarts.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32992>
Implement the OVR_multiview framebuffer attachment parameters in
get_framebuffer_attachment_parameter():
- GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_NUM_VIEWS_OVR: This reads the
attachment's NumViews.
- GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_BASE_VIEW_INDEX_OVR: This reads the
attachment's Zoffset, but only if NumViews is non-zero.
This allows apitrace (PR 937[1]) to show the correct layers for
multiview framebuffer attachment surfaces, as well as to show this
information in the framebuffer attachments state.
[1]: https://github.com/apitrace/apitrace/pull/937
Fixes: 328c29d600 ("mesa,glsl,gallium: add GL_OVR_multiview")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: James Hogan <james@albanarts.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32992>
The OVR_multiview spec specifies the INVALID_VALUE error to be generated
by FramebufferTextureMultiviewOVR if:
"- <texture> is a two-dimensional array texture and <baseViewIndex> +
<numViews> is larger than the value of MAX_ARRAY_TEXTURE_LAYERS."
Implement this in check_multiview_texture_target(), similar to the test
in check_layer().
Fixes: 328c29d600 ("mesa,glsl,gallium: add GL_OVR_multiview")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: James Hogan <james@albanarts.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32992>
The OVR_multiview spec adds the following condition for framebuffer
completeness:
"The number of views is the same for all populated attachments.
{ FRAMEBUFFER_INCOMPLETE_VIEW_TARGETS_OVR }"
So add a condition to _mesa_test_framebuffer_completeness to check that
all attachments have identical NumViews. This avoids an infinite
recursion between zink_clear() and zink_clear_depth_stencil() in the
event of an incomplete FBO.
Fixes: 328c29d600 ("mesa,glsl,gallium: add GL_OVR_multiview")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: James Hogan <james@albanarts.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32992>
NumViews needs considering along with the other attachment data when
reusing a multiview framebuffer texture attachment (i.e. shared depth
and stencil texture).
The depth and stencil attachments should match in all respects including
NumViews before reusing the existing one, and NumViews should also be
copied when reusing.
This avoids an infinite recursion between zink_clear() and
zink_clear_depth_stencil() in the case of reuse of a multiview
depth/stencil attachment.
Fixes: 328c29d600 ("mesa,glsl,gallium: add GL_OVR_multiview")
Signed-off-by: James Hogan <james@albanarts.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32992>
Symlinking $CARGO_HOME to /usr/local/bin made rustup uninstaller delete
the entire folder, causing mysterious build errors, so let's do the
traditional .cargo/env sourcing to make rustup available to the rest of
the build scripts.
Also make sure that required scripts run the shell's rcfile to be able
to setup the PATH correctly.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33519>
Use `rustup self uninstall -y` instead of manually removing folders to
ensure a proper cleanup of the rustup installation, including cargo and
init command injections in shell rc files.
Failing to do so can cause issues, such as bash failing to run in a `set
-e` environment due to a missing `$HOME/.cargo/env`, for example.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33519>
In 2183bc73a6 ("nvk: Use suld for EDB uniform texel buffers"), we
started using suld instead of tld for EDB uniform texel buffers because
we needed it for correctness. However, it's slow as mud. Using
suld.constant seems to fix the performance regression. I don't know if
it's quite tld performance, but it's close.
Backport-to: 25.0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33612>
This is way faster than suld.sys, which is what we're using today. So
far I haven't seen it matter for anything but texel buffers but it
likely helps some app somewhere.
Backport-to: 25.0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33612>
This should never happen as the client should always give us aligned
addresses. However, in the off chance that it does, aligning down is
probably safer than aligning up as it won't cause the top end of the
range increase and potentially fault.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33610>
The tricks we play for texel buffers with VK_EXT_descriptor_buffer don't
work with tld with very large buffers. suld, on the other hand, doesn't
seem to have these limitations.
Fixes: 3b94c5c22a ("nvk: Lower descriptors for VK_EXT_descriptor_buffer buffer views")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33610>
We can theoretically hit this if CmdProcessGeneratedCommandsEXT is
called with a state command buffer that doesn't have compute shader set
if execute commands bind a shader. We do, however, need to still call
nvk_cmd_upload_qmd() because it also uploads push constants and we need
those regardless of whether or not there's a shader bound.
Fixes: 976f22a5da ("nvk: Implement CmdProcess/ExecuteGeneratedCommandsEXT")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33610>
For the instructions we parse with brw_gram.y, don't unconditionally
call brw_eu_inst_set_cond_modifier(). Do it like we do in
brw_generator::generate_code() and only call it if we have a
cond_modifier to set.
Why? Because for ONE_SRC instructions, CondCtrl (bits 95:92) only
exists if Src.IsImm is false. If Src.Imm is true, then bits 95:64 are
actually Src0.ImmValue[63:32]. If we unconditionally call
brw_eu_inst_set_cond_modifier(), we'll end up zeroing bits 95:92 for
ONE_SRC instructions with 64bit immediates. See BSpec page
Structure_EU_INSTRUCTION_BASIC_ONE_SRC (56880).
This issue can be reproduced with src/intel/executor if you try to
have the following instruction:
mov(16) g10<1>Q 0xfedcba9876543210:Q { align1 WE_all 1H };
our parser will end up zeroing the top bits, so the value of the
immediate will be 0x0edcba9876543210.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33559>
It's entirely possible that the same GEM handle is referenced across
different Vulkan object instances. As per the warnings in xf86drm.h,
the caller is responsible for reference counting.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33451>
Since Xe2, the registers are bigger and even the instruction
structures got updated to have 6 bits.
The way I detected this issue was when I tried to use
src/intel/executor to add the following instruction:
add(8) g6.8<1>UD g4<8,8,1>UD 0x00000008UD { align1 WE_all 1Q I@1 };
Executor would read this and end up emitting an add with dst being
g6<1>UD instead of what we wanted. It turns out that inside
brw_gram.y, at dstoperand and dstoperandex we do:
$$.subnr = $$.subnr * brw_type_size_bytes($4);
which would overflow subnr back to 0.
The overflow doesn't seem to be a problem with code we emit directly
(unlike the code we parse, like above) due to the fact that we seem to
treat Xe2 registers as smaller all the way until we call phys_nr() and
phys_subnr() during code generation. The phys_subnr() function can
generate a value that would overflow reg.subnr, but this value is
never written back to reg.subnr, it's just returned as an unsigned
int.
Fixes: e9f63df2f2 ("intel/dev: Enable LNL PCI IDs without INTEL_FORCE_PROBE")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33539>
The intent here was to check if the tile we're trying to merge
vertically (prev_y_tile) has already been merged horizontally into a
neighboring tile, but I used the slot_mask which also contains the tiles
that have been merged into the prev_y_tile, so the check was too
conservative and would fail even if another tile had been merged into
prev_y_tile. This meant that we would fail to ever create 2x2 regions of
tiles. Fix this by just testing prev_y_tile's bit in the mask.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33534>
Even though we always try to merge a horizontally or vertically adjacent
tile, when we try to merge a vertically adjacent tile it may not
actually be adjacent because it was merged horizontally and the current
tile wasn't or vice versa. We have to detect this and reject merging it.
Fixes: 3fdaad0948 ("tu: Implement bin merging for fragment density map")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33534>
This custom builder implements fine-grained instance node bounds
calculation by looking at all AABBs at tree depth 2.
Shaves off 0.3ms in the start scene for Indiana Jones: The Great Circle
on Deck (roughly 29.1ms->28.7ms).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32797>
This allows drivers to inject custom functions to calculate the bounds
of instance nodes. For example, this can be used to determine instance
bounds by transforming the AABBs of all child nodes at some level in the
BVH. When instance transforms contain rotations of close to 45°, this
can yield a tighter AABB than just taking the instance's top-level AABB
and rotating it.
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32797>
For decode this is also done in decode_video.
This breaks if app doesn't call vkCmdEncodeVideoKHR before end, eg:
vkCmdBeginVideoCodingKHR
vkCmdControlVideoCodingKHR
vkCmdEndVideoCodingKHR
Cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33582>
KGSL unconditionally supports preemption so we cannot ignore it.
On a6xx, we have to emit VSC addresses per-bin or make the amble include
these registers, because CP_SET_BIN_DATA5_OFFSET will use the
register instead of the pseudo register and its value won't survive
across preemptions. The blob seems to take the second approach and
emits the preamble lazily. We chose the per-bin approach but blob's
should be a better one.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12627
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33580>
Combiner unit runs after fmul/smul/fadd/sadd units and it can consume
the results that previous units wrote to the registers. So prefer
placing scalar mul into combiner unit and predecessors (if any)
into other units
shader-db:
total instructions in shared programs: 29072 -> 27698 (-4.73%)
instructions in affected programs: 11237 -> 9863 (-12.23%)
helped: 163
HURT: 0
helped stats (abs) min: 1 max: 42 x̄: 8.43 x̃: 4
helped stats (rel) min: 0.64% max: 30.00% x̄: 13.03% x̃: 11.76%
95% mean confidence interval for instructions value: -9.89 -6.96
95% mean confidence interval for instructions %-change: -14.09% -11.97%
Instructions are helped.
total loops in shared programs: 2 -> 2 (0.00%)
loops in affected programs: 0 -> 0
helped: 0
HURT: 0
total spills in shared programs: 367 -> 372 (1.36%)
spills in affected programs: 16 -> 21 (31.25%)
helped: 1
HURT: 2
total fills in shared programs: 1208 -> 1224 (1.32%)
fills in affected programs: 51 -> 67 (31.37%)
helped: 2
HURT: 2
LOST: 0
GAINED: 0
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33568>
Fix multiple issues with atan in disassembler:
- arg1_en field in combiner unit actually seems to be a bit indicating
that one of sources is vector (e.g. for atan_pt2, or multiplication)
- atan2 has 2 arguments, not one
- properly handle all instruction variants
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33540>
Apparently fast path cannot handle mismatched mutability and we
should use CP_BLIT which has SP_PS_2D_SRC_INFO.MUTABLEEN to signal
src mutability. Previously it was partially handled by
tu_attachment_store_mismatched_swap.
Fixes: a104a7ca1a
("tu: Handle non-identity GMEM swaps when resolving")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33514>
If the program writes to shared variables after all reads, in the last
block of the program, no one will ever read the value we write. We can
just eliminate these dead writes.
(Thanks to Faith Ekstrand for improving the ends_program() conditions.)
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33452>
glx/egl "multibuffers" denotes if server side support DRI3
multi plane and modifiers which is version >= 1.2. But now
it returns true just when DRI3 version >= 1.
This causes problem when xserver with amdgpu DDX which only
support DRI3 1.0, so "multibuffers" gets set unexpectedly,
and client send DRI3 >= 1.2 request to server which gets
unimplemented error.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31657>
multibuffers_available denotes xserver side support for
DRI3 and Present protocols which should not affect client
side support for dmabuf import/export.
This is for xserver with amdgpu DDX in which case
multibuffers_available will be false, but dmabuf import/export
should be enabled to support applications like mpv which use
dmabuf import for vaapi decoded buffer.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31657>
This is part of VK_EXT_mutable_descriptor_type but we never did anything
with it. Since we use local memory for descriptor sets, copying from
them means reading VRAM through a WC map and it's pretty expensive.
Using malloc() for HOST_ONLY should be a nice perf boost for things
which give us the hint.
This massively improves the performance Dragon Age: The Veilguard,
taking it from 7 FPS to 25 FPS on an RTX 4060.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12622
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33571>
More are found missed from prior maint5 support. This change has
properly initialized the maint5 props as well as fixing its new
VkPipelineCreateFlags2CreateInfo integrations.
Verified with dEQP-VK.*maintenance5*
Fixes: be6fece6e1 ("venus: enable VK_KHR_maintenance5")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33566>
This machine registration command makes it possible to check for the
specified list of machine tags rather than just doing a full comparison
of tags between the expected state and the current state.
This is beneficial for multiple reasons:
* It enables having more than one GPU in a host, and we let the machine
registration container unbind the unwanted GPU before Mesa CI even
executes anything
* It makes it possible to alter the boot process so as to use a kernel
with a different architecture than the default kernel of CI-Tron uses
* Adding or modifying tags which are unused by a job won't fail the
first job after the new machine registration container lands.
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33551>
This is not conformant and it can cause hard to debug issues or hide
existing bugs. Getting rid of this limit will allow lavapipe to use the
common bvh building framework since the ploc build shader has a loop
that waits to start the next phase.
cc: mesa-stable
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31426>
iceil can return bogus (negative) values in case there's an overflow
(or a NaN). This would then take forever to run due to a couple billion
loop iterations.
Use unsigned minimum instead which will clamp iterations to max aniso
(not sure if that makes more sense than clamping negative values to 0,
probably doesn't really matter).
Fixes: 350a0fe632 ("llvmpipe: Use a simpler and faster AF implementation")
Reviewed-by: Brian Paul <brian.paul@broadcom.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33537>
Previously DGC alignment requirements declared by
getGeneratedCommandsMemoryRequirementsExt were not also reported by
getDeviceBufferMemoryRequirements for preprocess buffers.
This fixes 1554 dEQP-VK failures related to device-generated commands
that previously failed with "DGC alignment requirement larger than
preprocess buffer alignment requirement".
Fixes: 976f22a5da ("nvk: Implement CmdProcess/ExecuteGeneratedCommandsEXT")
Reviewed-by: Faith Ekstrand <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33555>
This should use the stride and offset from transfer, because
the values from resource_get_info may not match the mapped
memory if the driver uses staging texture for transfer.
This also gives us data size and we don't need to calculate
it for each format.
Unfortunately we only know the values when mapping the buffer,
but VAAPI requires the values when creating the image and at
that point we don't know the usage yet (read/write).
Do a dummy map of all planes first time DeriveImage is called
for each surface and cache the values for subsequent calls.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32326>
This function is no longer the only concept we have of "Vulkan version",
so let's rename it to reflect that it's only about the API-versin. We
don't really need to specify that it's about Vulkan versions, that seems
pretty obvious here.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33254>
This will be needed in order to check off passing the VK CTS properly.
Please note, this does *not* mean that we are formally conformant, only
that we have passed the VK CTS at least once. Those are not the same
thing.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Backport-to: 25.0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33254>
Previously, we stored the full color output before lighting, then compute
lighting and store just the .xyz of the result to .xyz.
We can save followup optimization work to clean up the unused .w
calculations during lighting, and DCEing the first .xyz store if we just
store .w when it's done, and only do lighting on .xyz. Some of that
redundant store work may not have been happening on all backends.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33501>
bi_opt_mod_prop_backward tries to propagate values backwards, but
stops checking for uses when it reaches the SSA definition. For
ordinary blocks that's fine, but for loops the definition can come
after a PHI that uses the value. This causes incorrect code to be
generated in shaderdb test `shaders/skia/2134.shader_test`. Fix this
by special casing PHI instructions, in a manner similar to done in
asahi/compiler/agx_optimizer.c.
This bug has been present a long time, so we want it back-ported to
stable.
Cc: mesa-stable
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33483>
Normally the driver & compiler work together to use as few
3DSTATE_VERTEX_ELEMENTS/VERTEX_BUFFER_ELEMENT data as possible.
The compiler ignores unused bits and driver avoids emitting the
corresponding elements in 3DSTATE_VERTEX_ELEMENTS.
For device generated commands, we want an 3DSTATE_VERTEX_ELEMENTS
programming that is independent from the shader so that we can
implement indirect pipeline binding without complicating the
generation shader as well as emitting fewer generated commands.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32418>
It turns out that the change from CENTER_Y to CENTER_X for
422 YUV didn't actually happen until generation 14 of the
hardware, not generation 10 as some documents claimed. This
fixes the failing piglit tests ext_image_dma_buf_import-sample_yuv
associated with 422 formats (which apparently we aren't running on CI).
Fixes: 23aa784c
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33516>
When using VK_EXT_acquire_drm_display, the Vulkan API user must provide
the DRM master fd that will be used. This operation is performed through
`vkAcquireDrmDisplayEXT()` in which `drmFd` will be assigned to
`wsi->fd` and will be used for privileged operations.
This means that, when we are creating the physical device, we need to
open a DRM primary node (as the specification states that "The provided
drmFd must correspond to the one owned by the physicalDevice."), but it
doesn't need to be the DRM master.
Therefore, when using VK_EXT_acquire_drm_display, keep the primary fd
open and don't check if the fd is the DRM master.
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33096>
Based on observations of the generated assembly, this instruction appears to:
- Swizzle the 8/16 component vector in src0 according to the pattern defined in src1.
- Apply a enable mask from src2 to selectively modify elements.
I encountered this instruction while experimenting with _viv_asm and
packed types.
Here is one exmaple kernel:
kernel void k(global int* out, int a, int b) {
_viv_char2_packed s;
_viv_asm(MOV, s.x, s, a);
_viv_asm(MOV, s.y, s, b);
out[0] = s.x + s.y;
}
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33474>
We currently assume the implicit offset shift is always 2. However, this
shift is actually based on the type, making sure the offset fields are
in units of the type size. The full offset calculation is as follows:
((SRC2<<SRC2_SHIFT) + OFF)<<TYPE_SHIFT
Where SRC2, SRC2_SHIFT, and OFF are instruction fields while TYPE_SHIFT
is implicit and derived from the TYPE field.
This commit implements (dis)assembly support for this, adopting the
syntax used by the blob.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33503>
For bin merging, we will have to first sample all bins in the pipe, then
determine which bins can be merged, then iterate over bins. Combine all
of the information required to render a bin into a tu_tile_config struct
and pass it down to tu6_emit_tile_select(). This will let us more
flexibly construct a list of bins later.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33230>
This was causing a crash on
"dEQP-VK.graphicsfuzz.cov-function-large-array-max-clamp" where the
test was trying to allocate ~6GB of TLS.
Considering we were already doing something identical before those changes,
we can just add nir_lower_scratch_to_var before nir_lower_vars_to_scratch
to get the expected behavior (Cleaning LLVM spilling mess around pan_pack)
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Fixes: 1619fc596a ("bi: Optimize scratch access")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33510>
When a command buffer ends with pending barriers we were emitting a
serialized noop job, but this only works to ensure serialization of
follow-up CL jobs, it won't do what we want if the barrier was
intended for compute or TFU transfers for example. Fix this by
merging the barrier state into follow-up jobs in the same queue
submission.
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33507>
Instead of the cmd_buffer. Also, rename it to drop the cmd_buffer
reference, make it a public helper, make it accumulate the
barrier state instead of overwriting it and make it return whether
it actually applies a barrier into the job.
We will use this new public helper in a follow-up change from the
queue to better handle barriers at the end of a command buffer.
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33507>
For devices that load shader consts through preamble, HLSQ_INVALIDATE_CMD
should be used to invalidate VS state before CP_DRAW_INDIRECT_MULTI. This
avoids previous consts loaded through CP_LOAD_STATE6_GEOM for non-indirect
draws to affect the consts needed for the current indirect draw.
Fixes two failing vkd3d-proton test cases on a750:
test_vertex_id_dxbc
test_vertex_id_dxil
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32924>
Make setting the ANGLE_ARCH variable optional by providing a default
based on DEBIAN_ARCH, while keeping it possible to override it, which is
expected to be necessary for the Android-arm64 build.
Exclude unnecessary third party dependencies in the .gclient file, which
allows us to delete our first local patch. Thanks to Yuly Novikov for the
suggestion.
Use -no-history for gclient sync, which is equivalent to git's --depth=1
argument. This greatly speeds up the process of fetching sources.
Thanks to this speedup fetching third_party/catapult is no longer an
issue, allowing us to remove our second local patch.
Since we're no longer applying local patches, use ANGLE_REV and
/angle/version as the base for our version check on Android.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Reviewed-by: Antonio Ospite <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33467>
ANGLE really wants to use its own toolchain and sysroot by default.
Unfortunately, for AArch64, that toolchain is actually a cross-compiling
toolchain designed to be hosted on x64, which is ... not what we want.
Use the system toolchain, and since we're not using the bundled
compiler, also don't use LLVM's libc++ and abseil, since those don't
always work with the system toolchain.
v2 (Valentine)
* Only use native toolchain on linux
* Contain clang-19 environment variables within a subshell
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Antonio Ospite <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33467>
Handle phis in two groups: first those which already have a preferred
reg set and then those without. The second group should be rare but by
handling them last, they don't accidentally occupy a preferred reg of
another phi, preventing excessive copying in some cases.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33489>
The as_build and related functions only appear when MESA_GPU_TRACES=
perfetto is set. By default, when running an RT workload for profiling,
these traces should be recorded alongside other trace points. This
commit ensures that acceleration structure build events are properly
captured when running an RT workload.
v2(Michael Cheng): Move this logic up to anv_device_init_accel_struct_build_state
v3(Michael Cheng): Set emit_markers = true and let the generated
functions handle the check for u_trace_enable and intel_gpu_tracepoint
Signed-off-by: Michael Cheng <michael.cheng@intel.com>
Reviewed-by: Casey Bowman <casey.g.bowman@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33461>
This lets us remove some special casing from update_renames and make it
simpler. Doing this in update_renames was also fragile, since the
parallelcopies vector is not final when update_renames is called, so it
might not have been safe to do so in the end.
No fossil-db changes.
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/33444>
It seems we have some issue with the driver, due the high number of
(random) flakes that appear in different jobs, and that eventually are
causing issues with Marge.
While we don't identify where is the problem, let's disable the job to
avoid interferences with Marge.
Acked-by: Valentine Burley <valentine.burley@collabora.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33490>
init_queue() calls cleanup_queue() if anything fails in the middle, which
means finish_render_desc_ringbuf() will be automatically called if
init_render_desc_ringbuf() failed. Get rid of the the error path and
return directly instead. The one exception we have is the dev_addr
allocation, which needs to be explicitly freed if an error occurs between
util_vma_heap_alloc() and pan_kmod_vm_bind().
Reported-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Fixes: 5544d39f44 ("panvk: Add a CSF backend for panvk_queue/cmd_buffer")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33471>
Between Rust's love of the stack, the size of Rust objects, and the
number of parameters we have to pass in order to sort out lifetime
issues, Rust recursion can be quite expensive. Combine that witn
Windows' tiny stack sizes and this call is blowing out the stack on
games running on DXVK and VKD3D-Proton. This gets rid of this bit of
recursion and replaces it with a loop and a worklist.
Reviewed-by: Mel Henning <drawoc@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33472>
This code is old, copied from the old nouveau GL driver. As of Pascal,
we have have 32k images so we need 32k scissors as well. Use the
max_image_dimension() helper instead of hard-coding it.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33478>
Add current time when generating the stream handle initial value.
When running inside PID namespace there can be multiple processes
in the system that will share the same PID and with current code
this could result in the same stream handle being used at the same
time from different processes.
This can easily happen with Flatpak when running two instances of the
same application - both processes will have the same PID and we
will use the same stream handles.
For older UVDs kernel will reject the CS if we use duplicated handles.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12575
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33374>
Indeed, has_atomics is not yet initialized at the time of the
call of r600_init_shader_caps(). This change fixes this issue.
For instance, this issue is triggered with
"piglit/bin/clearbuffer-depth-cs-probe -auto -fbo":
clearbuffer-depth-cs-probe: ../src/gallium/drivers/r600/evergreen_state.c:5039: evergreen_emit_atomic_buffer_setup: Assertion `resource' failed.
Aborted
Fixes: 7cd606f01b ("r600: add r600_init_screen_caps")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33438>
The offset is measured in bytes. Some of the code here acted as though
it were measured in src.type units. Also modify the assertion to check
that all extracted bits come from data in the immediate value.
Fixes: 580e1c592d ("intel/brw: Introduce a new SSA-based copy propagation pass")
Fixes: da395e6985 ("intel/brw: Fix extract_imm for subregion reads of 64-bit immediates")
Yes, I missed this error *twice* in code review.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33049>
Add support for GL_EXT_protected_textures to create protected
texture in OpenGL ES 3.2. This enables allocating standard
GL textures as protected surfaces. This allows use-cases such
as depth, stencil, or mipmapped textures to be supported as
destinations for rendering within a protected context.
Signed-off-by: Saroj Kumar <saroj.kumar@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33358>
Starting from Android 14 (Android U), framework HWUI has required a
second graphics queue to avoid racing between webview and skiavk. For
non-Android, we leave the second queue emulation behind a debug option.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30985>
Line smoothing should only be enabled for line primitives.
So far we were only checking the pipeline topology, but this is not
enough if there is a geometry shader, as it can change the primitive
from line to anything else, or the other way around.
This fixes several failures in
dEQP-VK.draw.renderpass.non_line_with_params.*.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33395>
Command buffer private object destroy callbacks receive a 64-integer so their
signature should respect that to avoid alignment issues when passing pointers.
This is the same we were already doing for color pipelines, but now for D/S
pipelines too.
Fixes crash on 32-bit build with:
dEQP-VK.synchronization2.op.single_queue.fence.write_clear_attachments_read_copy_image_to_buffer.image_128x128_d16_unorm
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33463>
The proper name for the meson options changed to meson.options in Meson
1.1. Since we don't support older versions of Meson anyway, let's just
rename the options-file to the new name.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33445>
Since the binding value can be any 32-bit number, we cannot assume that
it is <= 27 bits. We need 64-bit keys to accommodate a 32-bit binding.
This will also provide more bits to store the subdesc id, which will be
needed for multiplane texture and sampler descriptors.
Fixes: 7bea6f86 ("panvk: Overhaul the Bifrost descriptor set implementation")
Signed-off-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32563>
We're about to start lowering these in the IR, at which point the
scheduler will see SEND instructions with fence messages. Previously,
we handled those in the generator, and didn't handle the virtual opcodes
here, letting them fall through to the default case of 14 cycles.
These new numbers are completely fabricated, matching the times we have
for atomic operations. This is basically what we did for LSC atomics.
While it may not be accurate, it's at least better than 14 cycles.
Acked-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33297>
Memory fences do not refer to an element of a binding table. Rather,
the reason we had "BTI" in these opcodes was to distinguish what in
modern terms are called UGM (untyped memory data cache) vs. SLM
(cross-thread shared local memory) fences.
Icelake and older platforms used the "data cache" SFID for both
purposes, distinguishing them by having a special binding table
index, 254, meaning "this is actually SLM access". This is where
the notion that fences had BTIs came in. (In fact, prior to Icelake,
separate SLM fences were not a thing, so BTI wasn't used there either.)
To avoid confusion about BTI being involved, we choose a simpler lie: we
have Icelake SLM fences target GFX12_SFID_SLM (like modern platforms
would), even though it didn't really exist back then. Later lowering
code sets it back to the correct Data Cache SFID with magic SLM binding
table index. This eliminates BTI everywhere and an unnecessary source.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33297>
For some reason, we were using UW type for the destination of memory
fences at the generator level, while in the IR we selected UD.
There are some comments in the documentation for the message about it
writing the notification register to the destination, which is 32-bit.
Prior to Xe2, bits 31:16 were Reserved/MBZ. But on Xe2, all 32 bits
are populated with actual data.
I don't know whether this will fix anything in practice, but it seems
like a better plan to use UD. Often we used UW types to avoid having
the destination region of sends span too many registers, but we're in
SIMD1 here, so it shouldn't matter.
Acked-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33297>
brw_memory_fence() overrides the instructions generated by the
MEMORY_FENCE or INTERLOCK opcodes to be force_writemask_all with
exec_size == 1. But the IR was emitting it in SIMD8 (regardless
of dispatch width). Instead, just emit the IR as SIMD1/NoMask so
the IR matches what we actually generate. Have size_written indicate
that the entire destination is written, however, as it is ultimately
going to be a SEND that writes a whole register.
We were also using a UD register for the source of
FS_OPCODE_SCHEDULING_FENCE when the generator overrides it to UW,
so just specify UW in the IR as well so that they line up.
Also add validation for MEMORY_FENCE/INTERLOCK that we've done the
exec_size and masking right in the IR.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33297>
Rather than using a bit in the generic fs_inst data structure, we can
simply set a source on our logical FB write messages. (We already do
so for many other cases.)
In the repclear shader, setting this wasn't actually having an effect,
as we were setting it on a SHADER_OPCODE_SEND message which ignored it.
(We had already correctly set the bit in the message descriptor.)
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33297>
On armhf integer divide by 0 can raise SIGFPE, whereas on aarch64
it just returns 0. This has become an issue because the recently
added panfrost_init_screen_caps always calls pan_gpu_time_to_ns to
calculate caps->timer_resolution, whereas before we only called it
when PIPE_CAP_TIMER_RESOLUTION was queried, and only OpenCL
does that (and not always).
Fixes: 205669e3a9 ("panfrost: add panfrost_init_screen_caps")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33435>
Noticed one by chance and searched for any others with find that were
clearly not meant to be executable.
For the curious:
33aa039acf changed texstore.c to
executable.
ed176e2c71 introduced si_vpc.c and
si_vpc.h which have always been executable.
d0e5203855 changed lava-gitlab-ci.yml to
executable.
328c29d600 introduced OVR_multiview.xml as
executable.
ac912b3754 introduced
OVR_multiview_multisampled_render_to_texture.xml as exectuable.
Signed-off-by: Dudemanguy <random342@airmail.cc>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33436>
Prevent following warning if not running as a normal user:
Failed to create /home for shader cache (Permission denied)---disabling
disk_cache_delete_old_cache() is going to create first the cache directory
using disk_cache_generate_cache_dir(). From mkdir_if_needed(), the stat()
of "/home" is failing with "Permission denied" under some circumstances
when using Firefox.
Fixes: #12168
Fixes: c3bc6991d2 ("util/disk_cache: Delete the old multifile cache if using the default.")
Signed-off-by: Benjamin ROBIN <dev@benjarobin.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32886>
The release branch contains only what was on the staging branch first,
so testing it again is a waste of resources.
To do this, we split the rule into specifically "default branch" and
"staging branch", and "release branch" gets dropped by virtue of no
longer being caught by any rule.
Cc: mesa-stable
Reviewed-by: Martin Roukala <None>
Reviewed-by: Dylan Baker <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33411>
It's too late to run all the tests by then, the release has been made
based on the staging pipelines results
Cc: mesa-stable
Reviewed-by: Martin Roukala <None>
Reviewed-by: Dylan Baker <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33409>
Previously this used the {Min,Max}Tile{Rows,Cols} as returned by the
driver capabilities. Those parameters should be used to determine
implementation supported tile configurations for a specific resolution.
In the case of header coding, the {min,max}Log2Tile{Rows,Cols} should be
derived exactly as the AV1 spec defines it.
Signed-off-by: Benjamin Cheng <benjamin.cheng@amd.com>
Reviewed-by: Sil Vilerino <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32762>
Forcing a dedicated sparse queue is problematic in real-world scenarios.
In the current implicit sync world for sparse updates, we can rely on
submission order.
For use cases where an application can take advantage of the separate
sparse queue to do "async" updates, the existing implementation works
well, but problems arise when trying to implement D3D-style submission
ordering. E.g., when a game does sparse on a graphics or compute queue,
we need to guarantee that previous submissions, sparse update and future
submissions are properly ordered.
The Vulkan way of implementing this is to:
- Signal graphics queue to timeline N (i.e. last submission made)
- Wait on timeline N on the sparse queue
- Do sparse updates
- Signal timeline N + 1 on sparse queue
- Wait for timeline N + 1 on graphics queue (can be deferred until next
graphics submit)
This causes an unavoidable bubble in GPU execution, since the
existing sparse queue ends up doing:
- Wait pending signal. The implication here is that all previous GPU
work must have been submitted.
- Do VM operations on CPU timeline
- Wait for semaphores to signal (this is required for signal ordering)
- ... GPU is meanwhile stalling in a bubble due to GPU -> CPU -> GPU roundtrip.
- Signal semaphore on CPU (unblocks GPU work)
Letting the GPU go idle here is not great, and we can be screwed over by bad thread scheduling.
Another knock-on effect is that the graphics queue is now forced into
using a thread for submissions. This is because when the graphics queue
wants to wait for timeline N + 1, the sparse queue may not have
signalled the timeline yet on CPU, so effectively, we have created a
wait-before-signal situation internally in RADV. Throwing another thread
under the bus is not great either.
Just letting the queue in question support sparse binding solves all
these issues and I don't see a path forward where the D3D use case can
be solved in a separate queue world.
It is also friendlier to the ecosystem at large. RADV is the only driver
I know of that insists on separate sparse queues and multiple games
assume that graphics queue can support sparse.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33166>
Prepare for building ANGLE for Android, which requires applying a
patch to fix building with minimal dependencies.
Rework the existing script by allowing passing the ANGLE_TARGET and
ANGLE_ARCH environmental variables to specify the target platform,
Android or Linux, and also allow building for arm64 in addtition to
x64 by setting ANGLE_ARCH.
Also build the GLESv1 compatibility mode library (libGLESv1_CM),
which is required for EGL testing on Android.
Based on work by Antonio Ospite.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Reviewed-by: Eric Engestrom <None>
Reviewed-by: Antonio Ospite <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33377>
After commit 83d1553391 (ci: Don't build Vulkan for GL dEQP, 2025-01-29) deqp
does not build cleanly anymore for the Android target.
Fix that by updating the
build-deqp-gl_Build-Don-t-build-Vulkan-utilities-for-GL-builds.patch patch.
Reviewed-by: Eric Engestrom <None>
Reviewed-by: Antonio Ospite <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33377>
The radv-stoney-angle-full was unintentionally inheriting the fraction
from the pre-merge job.
Also use the correct manual rules definition while we're here, and use
consistent naming for the restricted rules.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Reviewed-by: Eric Engestrom <None>
Reviewed-by: Antonio Ospite <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33377>
Lionel added a neat debugging tool. Let's make it work with the new-style
hashing approach too, since nir_printf_fmt is a lot more convenient than needing
to define a dedicated CL function to access printf (although that works too).
We remove the old non-hashed path, because it has no more functional users --
hashing is a hard requirement with vtn_bindgen2, which Intel has now switched
to.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33380>
It's unclear to me whether this is dead code that should be removed or
dead code that should be used, so I just marked it as unused to remove
a few thousand warnings when compiling.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33384>
This switches to disk_cache instead of our own mechanism which only
stored meta shaders when the logical was destroyed.
Meta shaders are still stored separately from the application shaders
because they are common to all applications on a given GPU/Mesa version.
The default cache is 32MiB which should be large enough.
This fixes massive stuttering in FF7 Rebirth but all apps are
technically affected.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33370>
The fix in e7ac1094f6 to emit preamble defs in the correct block would
move the cursor of the builder that is later used to insert descriptor
prefetches, emitting them at the wrong place. Fix this by resetting the
cursor before emitting the prefetches.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: e7ac1094f6 ("ir3: rematerialize preamble defs in block dominated by sources")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33399>
Somewhere between writing c1510ad72e ("nak: Optimize bindless to cbuf
textures on Volta+") and me rebasing it a year later, we switched to
using the NV-specific ldc_nv intrinsic for cbuf loads. It's basically
the same as load_ubo but we're detecting the wrong intrinsic so the
optimization does nothing.
Fixes: c1510ad72e ("nak: Optimize bindless to cbuf textures on Volta+")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33398>
These have been switching between failing and passing recently. Not
really sure what's going on here, but we don't want the CI to flip
randomly between failing and passing, so let's mark them as flakes.
Backport-to: 25.0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33381>
I think this was broken as there might be a store_output with
less than 4 components to a location that shouldn't be smoothed
anyway (i.e. not the first one).
nir_lower_poly_line_smooth now handles the case where the first location
doesn't have 4 components.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33340>
The if is really short so it should really use a conditional select,
but this pass is called too late go through all the usual lowerings
and opts.
Foz-DB Navi21:
Totals from 1128 (1.42% of 79377) affected shaders:
MaxWaves: 29358 -> 29342 (-0.05%)
Instrs: 552306 -> 549668 (-0.48%); split: -0.58%, +0.10%
CodeSize: 2796392 -> 2782360 (-0.50%); split: -0.59%, +0.08%
Latency: 2574361 -> 2566482 (-0.31%); split: -0.47%, +0.16%
InvThroughput: 644047 -> 647500 (+0.54%); split: -0.18%, +0.72%
Copies: 37521 -> 36460 (-2.83%); split: -2.92%, +0.09%
Branches: 12009 -> 10157 (-15.42%)
VALU: 350886 -> 349199 (-0.48%); split: -0.64%, +0.16%
SALU: 104459 -> 105415 (+0.92%); split: -0.00%, +0.92%
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33340>
Now using the same model as the compute shader.
As a result we temporarily disable the use of the Inline register for
providing push constants on Task & Mesh shaders. Since that register
is also available on the compute shader we'll try to find a way to use
the same mechanism for all 3 shaders in another MR and bring back that
optimization.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32895>
Some drivers implement luminance as RGBA. Since the code checks the
renderbuffer format instead of the internal format this can cause the
query to incorrectly return "signed" on the Alpha component for signed
luminance formats.
Fixes the following Piglit test for various drivers (at least Panfrost
and V3D):
spec/ext_packed_float/query-rgba-signed-components
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33372>
By having the DUTs download and extract from a CI-Tron artifact, we
deduplicate the downloading of the build artifact across all DUTs from
a CI farm, leading to quicker and more reliable jobs, and lower
bandwidth usage on both FD.o and the CI gateway.
Inside the CI-Tron infra, this should also drastically reduce the job
submission time by removing needless copies (executorctl -> executor,
executor -> S3, S3 -> B2C, and even B2C -> NBD when applicable).
As an additional bonus, the size of install.tar is reduced by virtue of
zstd providing better compression than zip/deflate.
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32927>
Rather than downloading the full history of deqp just to check a merge
base, let's ask github for this information directly.
This fixes the deqp build on arm32 platforms which do not have enough
address space to run git fetch on such a large repo.
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32927>
Both test-gl and test-vk install a bunch of stuff which is required to
just run tests. Instead of copy and pasting a bunch of random stuff into
derived containers, just keep it in the base container. Technically this
makes both containers very slightly larger, but the additions here pale
into comparison with 700MB of mostly-unused Proton, 400MB of deqp-vk
mustpass, etc.
v2 (Martin Roukala):
* Move spirv-tools to the list of dependencies as it is needed by
python3-renderdoc
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32927>
Use command:
find . -type d \( -path "./.git" -o -path "./docs/relnotes" \) -prune -o -type f -exec sed -i 's/PIPE_SHADER_CAP_\([A-Za-z0-9_]*\)/pipe_shader_caps.\L\1/g' {} +
find . -type d \( -path "./.git" -o -path "./docs/relnotes" \) -prune -o -type f -exec sed -i 's/PIPE_COMPUTE_CAP_\([A-Za-z0-9_]*\)/pipe_compute_caps.\L\1/g' {} +
Also remove value type in pipe_compute_caps doc because they
are explicit in struct now.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33176>
To remove ir_type param when get_compute_param. These caps depend
on IR type and used by clover only (only clover query with
PIPE_SHADER_IR_NATIVE, others query with PIPE_SHADER_IR_NIR).
Only r600 and radeonsi support PIPE_SHADER_IR_NATIVE.
These caps can be removed when clover is deprecated.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33176>
Vulkan defines the line rasterization to *always* use perpendicular
rather than aligned line ends (unless otherwise specified by
VK_EXT_line_rasterization). So let's remove the code that conditionally
sets the bit, we always want the default value (0) here.
It might seem confusing because we kinda named this field wrong. It's
really about perpendicular vs aligned line ends. That's a cleanup we
might want to deal with later, but deleting the assignment is sufficient
to fix this issue. This is also what we do for v10.
This was probably just copied from the Gallium-driver, where this logic
is more or less correct.
Fixes: d970fe2e9d ("panfrost: Add a Vulkan driver for Midgard/Bifrost GPUs")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33373>
The check in check_multiview_texture_target() whether numViews <= 0 (as
required by the OVR_multiview spec) is never triggered since it is only
called by frame_buffer_texture() when numviews > 1, as numviews of 0 is
passed in by non multiview FramebufferTexture functions. Such cases are
incorrectly treated as non-multiview attachments.
Tweak frame_buffer_texture() to take an extra bool argument "multiview"
to distinguish between a multiview call with numviews=0, and a
non-multiview call.
Fixes: 328c29d600 ("mesa,glsl,gallium: add GL_OVR_multiview")
Signed-off-by: James Hogan <james@albanarts.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33346>
Fix the FBO attachment completeness test to ensure that multiview
attachments have all views referring to layers in range of the
underlying texture.
The OVR_multiview spec states:
Add the following to the list of conditions required for framebuffer
attachment completeness in section 9.4.1 (Framebuffer Attachment
Completeness):
"If <image> is a two-dimensional array and the attachment
is multiview, all the selected layers, [<baseViewIndex>,
<baseViewIndex> + <numViews>), are less than the layer count of the
texture."
Fixes: 328c29d600 ("mesa,glsl,gallium: add GL_OVR_multiview")
Signed-off-by: James Hogan <james@albanarts.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33346>
This is complicated by two things: mediump varyings, and the lack of u16
regfmt support in LD_VAR.
With mediump, a load(_interpolated)_input with a 16-bit dest size may
either be an explicit 16-bit type or a mediump type lowered by
nir_lower_mediump_io. With explicit 16-bit types, we write 16-bit values
in the VS, but with mediump we write 32-bit in the VS (for messy
reasons). bi_emit_load_vary needs to distinguish these cases by checking
for a mediump type, and set the appropriate source_format to convert the
type on the LD_VAR_BUF path. Types like 'mediump uint16' are luckily not
allowed.
The missing u16 regfmt for LD_VAR means that we take the obvious
approach for 16-bit int varyings of emitting 16-bit int formats in the
attribute descriptor and loading them to u16. Instead, we just
write/read all 16-bit varyings as f16 regardless of type. Unlike with
mediump, we don't need to do any 32bit->16bit conversion when loading in
the FS, so as long as we use the same type between the attribute
descriptor and LD_VAR, the conversion is a no-op and the mismatch
doesn't matter.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33078>
For Bifrost and newer, we always write mediump varyings from a 32-bit
source in the VS. This is needed because the FS does not unconditionally
lower mediump to 16-bit.
Previously we worked around this in panvk by replacing 16-bit formats
with 32-bit in emit_varying_descs, but once we support
storageInputOutput16, we will need to preserve 16-bit formats for
explicit 16-bit varyings.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33078>
The mesa screenshot layer attempts to use VK_FORMAT_R8G8B8_UNORM by
default. Using this, we can directly & efficiently write out to a
PNG file without further modifications. However, some GPUs don't
support the given format, so for those that don't, we'll attempt to
use VK_FORMAT_R8G8B8A8_UNORM, which will require some work to ensure
the alpha values are set to opaque to make RGB comparisons easier.
If both surface formats fail, a more descriptive failure
will be shown.
Signed-off-by: Casey Bowman <casey.g.bowman@intel.com>
Reviewed-by: Felix DeGrood <felix.j.degrood@intel.com>
Reviewed-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33295>
For Xe3+ the registers are tightly packed to make better use of GRF
space, so add a statistic to keep track of how many registers were used.
For previous versions this is not useful since the code is spreading
the registers among the whole space.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33311>
We do not have the TEX semaphore there anyway so the benefits are not as
high as with R500 and the chances of running out of TEX indirections are
just too high.
This will increase the register pressure in some shaders, but I believe
the gained shaders are worth it and there is also some cycles reduction
in some cases. I'm not sure how to optimize this further without
actually clonning the shader before the pair shceduling and than doing a
trial and error to see if there is some compromise where we can just hit
the indirection limit to not group it too much...
Shader-db RV410:
total instructions in shared programs: 112800 -> 112825 (0.02%)
instructions in affected programs: 5024 -> 5049 (0.50%)
helped: 23
HURT: 19
total temps in shared programs: 18170 -> 18244 (0.41%)
temps in affected programs: 1365 -> 1439 (5.42%)
helped: 39
HURT: 34
total cycles in shared programs: 169535 -> 166806 (-1.61%)
cycles in affected programs: 14229 -> 11500 (-19.18%)
helped: 84
HURT: 4
LOST: 0
GAINED: 8
GAINED: shaders/godot3.4/34-59.shader_test FS
GAINED: shaders/lightsmark/25.shader_test FS
GAINED: shaders/lightsmark/28.shader_test FS
GAINED: shaders/lightsmark/34.shader_test FS
GAINED: shaders/this-war-of-mine/144.shader_test FS
GAINED: shaders/this-war-of-mine/145.shader_test FS
GAINED: shaders/tropics/432.shader_test FS
GAINED: shaders/tropics/462.shader_test FS
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33275>
if there is no heap with device-local and host-visible, then
rebar cannot exist. the previous detection did not account for
the rebar heap using the device-local fallback, which of course
would have the same size as the device-local heap and pass the threshold
check
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33359>
Rather than assert (and otherwise write past the array size), guard against
this (and miscompile the shader), to make the code more robust.
This mimics the behavior of exceeding the cond_stack size (and other similar
stacks) - the if_stack is only used together with the cond_stack, the behavior
should be the same.
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33338>
The gen_header.py script is failing for older versions of python3 such
as python 3.5. Two issues observed with python 3.5 are ...
1. Python 3 versions prior to 3.6 do not support the f-string format.
2. Early python 3 versions do not support the 'required' argument for
the argparse add_subparsers().
Fix both of the above so that older versions of python 3 still work.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28780>
The handle and addr fields of drm_xe_sync is defined as the union:
union {
__u32 handle;
__u64 addr;
};
When initialized on the stack on certain implementations, setting
.handle will leave the upper bits of .addr/the overall union
uninitialized causing exec calls to fail with:
[drm:xe_sync_entry_parse [xe]] Ioctl argument check failed at drivers/gpu/drm/xe/xe_sync.c:136: upper_32_bits(sync_in.addr)
Somewhat awkward but init .addr first to 0 and then set the handle after
the struct init.
Cc: stable
Signed-off-by: Juston Li <justonli@google.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33172>
There were 4 fields:
- key: now will be passed explicitly, so we can reuse the existing
more general fs_visitor constructor;
- input_vue_map: used only by the client code brw_compile_gs, so
create it separatedly as a local variable;
- two unsigned parameters: just put them inside a nested struct in the
shader.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33228>
OpenCL C defines work-item functions to return a scalar for a particular
dimension. This is a really annoying papercut, and is not what you want for
either 1D or 3D dispatches. In both cases, it's nicer to get vectors. For
syntax, we opt to define uint3 "magic globals" for each work-item vector. This
matches the GLSL convention, although retaining OpenCL names. For example,
`gl_GlobalInvocationID.xy` is expressed here as `cl_global_id.xy`. That is much
nicer than standard OpenCL C's syntax `(uint2)(get_global_id(0),
get_global_id(1))`.
We define the obvious mappings for each relevant function in "Work-Item
Functions" in the OpenCL C specification.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33099>
This is a rewrite of vtn_bindgen. For now the two tools live in parallel, to
give Intel time to migrate off v1.
For a refresher, the classic vtn_bindgen reads a SPIR-V and generates a .h
containing nir_builder stubs for each exported function. The stub inserts an
unimplemented nir_function with the proper signature into the shader, and adds a
"call" to that function. The driver is responsible for linking with the library
later, which is annoying.
vtn_bindgen2 instead generates a .c/.h pair. The header are just prototypes with
identical signatures to what we have now. The .c implementations, however, are
very different. Instead of generating unimplemented nir_function, the
implementations contain the actual code (as serialized NIR, deserialized
on-the-fly). There is no linking step, nor a library nir_shader that the driver
has to keep around.
The programming model here is that this is "just" nir_builder ... just a
massively more competent way of using nir_builder.
Additionally, the whole SPIR-V -> optimized lowered serialized NIR step is now
all common code. There's no longer anything target-specific, and it's
disentangled from the nir_precomp infrastructure.
That means drivers can use CL with zero integration, except a few meson.build
rules. This gives a very gentle on-ramp to CL for drivers. (Note: that applies
only for library-style CL. For precompiled kernel-style CL, that still requires
significant driver integration. I do have plans there, though. Also,
printf/abort support requires a minimal amount of driver code.)
Furthermore, this unblocks the use of CL library functions in common code. That
makes this an important step towards common code geom/tess or maybe saner
raytracing.
For drivers already using classic vtn_bindgen, porting to vtn_bindgen2 should
just be deleting all your linking/deserializing code. The .cl's are unchanged,
as are the function prototypes exposed.
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33099>
When the core supports unified instruction memory, don't clamp individual
shader sizes to 256 instructions. Allow shaders to make full use of the
state instruction memory, as long as both VS and FS fit into the memory
region.
Allows to run the shaders from glmark2 terrain from state instruction
memory, so we don't need to use icache mode on GC3000 and makes the app
work on GC2000, which doesn't have icache but unified instruction memory.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33229>
Currently we statically partition the unified intsruction memory range
into a VS and a FS range, with each of the shader types getting half
of the memory. Change this to place the FS instructions right behind
the VS instructions, which potentially allows larger shaders to be
executed from the instruction memory states when VS are FS are
unbalanced in size, which is quite common.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33229>
According to _InitializeContextBuffer() in the downstream kernel driver
all GPUs claiming to support more than 256 shader instructions have unified
instruction memory and the shader range registers to partition usage of
this unified memory region.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33229>
There is no reason to emit those states on framebuffer changes. While the
framebuffer format change might change the fragment shader due to R/B
swapping in the shader, this triggers compilation of a new shader variant
which will dirty the shader state as needed.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33229>
Some cores with the the instruction cache feature, such as the GC3000 found
on the i.MX6QP, have a wrong instruction limit encoded in hardware. The HWDB
entry for this core has the correct number (512). Fixup all cores with the
instruction cache feature to report at least 512 instructions, which was
already assumed when configuring the VS/FS instruction state memory split in
other parts of the driver.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33229>
The existing code relies on assert to identify when a cs overlow
occurs. On builds without asserts, a cs overflow won't be detected
and it will likely lead to a hang.
Reporting a preemptively a PIPE_UNKNOWN_CONTEXT_RESET error seems
ok as the context is lost anyway.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33288>
Annotating ssa defs without affecting compilation is impossible with
debug info instructions since referencing a nir_def from the debug info
instr will add uses.
The old approach also stops worrking if passes reorder instructions.
This patch proposes a solution which should not regress performance just
like the old approach. The difference is that this one allocates a bit
more space for debug info instead of adding a new instruction for it.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33141>
We now use `parse_debug_string` to parse debug strings from files, which
may have newlines in them. This change ensures that newline characters
are ignored during parsing, a similar change was made to
`parse_enable_string` for consistency.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32906>
Currently the `nolrz` TU_DEBUG options are only checked during
device creation and image creation, respectively. This means that if
the options are enabled after the device/image is created, LRZ
will still be used. Similarly, if the options are disabled after the
device/image is created, LRZ will still be disabled.
This change moves the checks to the point where the LRZ is actually
used, allowing for runtime toggling of LRZ.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32906>
This adds a new environment variable, TU_DEBUG_FILE, which can be used to
enable/disable various debug options at runtime via writing to a file. This
is useful for switching between different debug options (such as toggling
between SYSMEM/GMEM) without needing to restart the application.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32906>
debian-testing is the critical path: the shortest possible job to build
exactly what we need to execute on hardware, and nothing else.
debian-build-testing exists to give us better coverage at the expense of
running longer.
Since the only jobs using r300 and Nine, and the only jobs using NVK,
are in post-merge stages which are manually triggered, move these builds
to debian-build-testing. This makes the critical path to those a little
longer, but we do get to make it shorter for everyone else just running
regular Marge jobs.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33287>
We don't need these Vulkan bits, so let's try not building them. This
might seem kind of petty, but given that we build dEQP four times for GL
(once for GL, once for GLES, once for EGL/X11, and once for
EGL/Wayland), it does actually make a measurable difference to the time
spent rebuilding dEQP.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33287>
This avoids a whole pile of nonsense that we don't need during the dEQP
build, which is helpful when you build it five times in a row. In
particular, not building the Vulkan validation layers means we don't
waste three minutes building a second copy of SPIRV-Tools which we never
use.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33287>
Create separate branches for output processing and exports.
Normally, emit attribute ring stores at the end of the shader,
but with the attribute ring wait bug, insert them between the
primitive and position export branches.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33218>
There is a possibility that some waves in an NGG workgroup
don't have any input vertices, only primitives. When these
waves store the primitive ID as a per-primitive attribute,
they will need to wait for those stores before the primitive
export, because the other waves can't wait for them.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33218>
This case is unlikely but possible. We forgot to handle it here,
because it was originally handled by the backend compiler.
On GFX10 chips that have issues with 0 vertices and primitives
exported, this will always export at least 1 vertex and primitive.
This could theoretically fix some hangs on Navi 10, although we are not aware of a specific issue caused by this problem.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33218>
These have been tested only with x86_64->i686 cross-compilation but I
don't see why they couldn't work with other architectures if/when Linux
distributions support them. For at least x86_64->i686 cross-compilation,
these commands save an enormous amount of time.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31945>
After optimization happen, if the sources are still in one or two
contigous spans for some reason (e.g. some data read from memory
now being written), it is beneficial to just use regular SEND
and avoid having to set the ARF scalar instruction.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Lionel Landwerlin <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32410>
Add an optimization pass to turn regular SENDs into SEND_GATHERs.
This allows the payload to be "broken" into smaller pieces that
can be further optimized, which _may_ result in
- less register pressure (no need to contiguous space), and
- less instructions (no need to MOV to such space).
For debugging, the INTEL_DEBUG=no-send-gather option skips this
optimization, and reporting how many opportunities were missed.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Lionel Landwerlin <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32410>
Starting in Xe3, there's a variant of SEND that take the
register numbers from the ARF scalar register, and don't
require them to be contiguous. The new opcode added here
represents that kind of SEND.
To make the original sources still reachable, we keep them
around during the IR, just ignoring them at generator time.
This allow software scoreboard to properly reason the
dependencies without trying to decode the contents of ARF
scalar register being used.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Lionel Landwerlin <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32410>
Isolate the BRW/ELK differences in a single place. The way is done now,
we are not reusing the isa_info between calls. For the tools here this
is probably fine, if its someday this gets in the way, we can add an
opaque pointer to store the right data.
This intentionally is not used in Iris, since there the driver need more
detailed view into BRW/ELK and we don't want to create an all
encompassing abstraction for that.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33054>
v2: Use MOV and wrap in conditional during BTD spawn header setup
(Lionel). Remove references to SIMD8 (Tapani).
v3: Update brw_bsr() to specify number of registers per thread, don't
initialize Registers Per Thread on BTD spawn header (Lionel).
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32664>
This is similar to what we used to do on pre-SNB platforms, the number
of GRF registers used by the shader will be used on Xe3+ to adjust the
trade-off between thread-level parallelism and size of the GRF file.
Plumb the value through prog_data so the driver can set up the
hardware state accordingly.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32664>
This is similar in principle to the previous commit "intel/brw/xe3+:
brw_compile_fs() implementation for Xe3+." but applied to compute-like
shader stages. It changes the implementation of brw_compile_cs/task/mesh()
to reduce compile time and take advantage of wider dispatch modes more
aggressively than the original logic, since as of Xe3 SIMD32 builds
succeed without spills in most cases thanks to VRT.
The new "optimistic" SIMD selection logic starts with the SIMD width
that is potentially highest performance and only compiles additional
narrower variants if that fails (typically due to spilling), while the
old "pessimistic" logic did the opposite: It started with the
narrowest SIMD width and compiled additional variants with increasing
register pressure until one of them failed to compile.
In typical non-spilling cases where we formerly compiled SIMD16 and
SIMD32 variants of the same compute shader, this change will halve the
number of backend compilations required to build it.
XXX - Possibly don't do this in cases with variable workgroup size
until effect on runtime performance can be measured directly.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
v2: Don't do this for now in cases with variable workgroup size, still
compile every possible variant in such cases.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32664>
This reworks the implementation of brw_compile_fs() to reduce compile
time and take advantage of wider dispatch modes more aggressively than
the original logic.
The new "optimistic" PS compilation logic starts with the SIMD width
that is potentially highest performance and only compiles additional
narrower variants if that fails (typically due to spilling or hardware
restrictions), while the old "pessimistic" logic did the opposite: It
started with the narrowest SIMD width and compiled additional variants
with increasing register pressure until one of them failed to compile.
The main disadvantage of this is that selectively throwing away some
of the compiled variants based on the static analysis of their
performance behavior will no longer be possible, however this is
expected to be less useful on Xe3+ since the GRF space allocated to a
thread can be scaled up or down, which leads to less dramatic
differences in scheduling between SIMD variants.
In typical non-spilling cases where we formerly compiled SIMD16 and
SIMD32 variants of the same fragment shader, this change will halve
the number of backend compilations required to build a shader. With
multi-polygon PS dispatch enabled (which is disabled by default right
now) this has an even more dramatic effect since the number of
compiler iterations can be reduced down to a fifth in the best case
scenario.
Even though in most cases we will only attempt to return a single
binary from the pixel shader compilation, the hardware allows a pair
of PS kernels to be specified, and we'll still take advantage of this
when the multi-polygon PS kernel has the potential to have worse
performance than the single-polygon shader because only the latter
register-allocates successfully at SIMD32 -- Only in such case
(SIMD2x8 multi-polygon, SIMD32 single-polygon) we'll continue
programming both so the hardware will chose one or the other at
runtime depending on the SIMD fullness and number of polygons it can
buffer at runtime.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32664>
This avoids running the optimizer uselessly if compilation of the
current kernel failed due to some hardware (e.g. SIMD-width)
restriction. This isn't only inefficient but it can break assumptions
throughout the compiler which would lead to crashes on Xe3 when this
arises during translation from NIR.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32664>
Xe3+ benefits from packing register allocations tightly in order to
make optimal use of the GRF space. The round-robin heuristic
previously in use often causes the whole GRF space to be used even if
register pressure is substantially lower, which would severely
decrease thread-level parallelism on Xe3+.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32664>
Xe3 supports 32 SBID tokens per thread regardless of the number of
register blocks allocated per thread. Take advantage of the increased
number of SBIDs in the scoreboard pass to reduce the frequency of
false dependencies on Xe3+.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32664>
These don't seem to be disallowed by recent hardware anymore. Stop
disabling SIMD32 due to hardware restrictions of multisample
rasterization, since it should have better performance, and on Xe3+
there may be no shader variant available other than SIMD32.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32664>
Request a fixed subgroup size for pixel shaders that require it due to
the hardware restrictions of fast clears and repeated data clears.
This requires plumbing the "is_fast_clear" boolean across several
callers since blorp_compile_fs_brw() currently has no information
regarding whether the kernel is intended for a fast clear operation.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32664>
On older hardware the "use_rep_send" compile parameter was being
implicitly used to request the compilation of the SIMD16 variant of
clear pixel shaders that require it due to hardware restrictions.
However starting on Gfx12+ this flag is never set since replicated
data clears are no longer supported, but BLORP still implicitly relies
on the SIMD16 variant being generated even though there's no way for
BLORP to explicitly request it. This doesn't cause much of a problem
right now since brw_compile_fs() typically generates a SIMD16 kernel
unless the SIMD8 kernel spills or SIMD debugging flags are enabled,
but it won't work reliably on Xe3+ since we'll start using SIMD32 more
aggressively.
In order to avoid these issues use the standard required subgroup_size
parameter from shader_info to signal that the SIMD16 variant of the
shader is needed by the caller.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32664>
The lavacli version 1.5.2 has been released in December 2022.
Use the most recent version 2.2.0, released in October 2023, instead.
Notable changes since 1.5.2:
- Authentication tokens are now stripped from exceptions when HTTP
requests fail. (1.6)
Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33266>
The panfrost-g52-piglit-gles2:arm64 job was taking 19 minutes on
average, and the pending durations of the meson-g12b-a311d-khadas-vim3
DUTs in LAVA were reaching 5-6 minutes, so we have to make this job
manual instead of pre-merge.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33082>
This fixes depth-only rendering with mesh shaders,
as well as array derefs in unlinked shaders in general.
Lowering array derefs of vectors is necessary for correctness.
Without this, nir_lower_io will incorrectly add the array index
to the IO intrinsic base instead of to the component offset.
This was previously only done during shader linking, which leaves
some problems with unlinked shaders and depth-only rendering.
Whether these calls can be safely removed from shader linking
will be investigated in a future commit.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12516
Cc: mesa-stable
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33264>
This is a preliminary implementation of detiling for
NV12_16L32 tiled format external images. When we
encounter such an image, decode it into a secondary
buffer which will then be used to actually texture from.
In some cases applications may wish to represent the individual
planes of an NV12 image separately, we support that by allowing
detiling of just an R8 (luma) or R8G8 (chroma) plane.
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31899>
After commit 44bda7c258 (dri: put shared-glapi into libgallium.*.so,
2024-12-26) the mesa Android build does not have a separate libglapi.so
object anymore in the install dir, so stop pushing it to the Android
device in cuttlefish-runner.sh
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33261>
Add a trailing dot to the remote directoyy in the `adb pull` command to
make sure to recursively pull only the **content** of the directory and
not the directory itself.
This prevents having `results/results/` in the artifacts.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33261>
This initial support should be good enough but it's missing two
features (cooperative matrix and video decode/encode) compared to
GFX11 (RDNA3) because lack of time.
DCC is still under active development but it might be possible to
finish it during the RC period.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33281>
There is no test for this, but it's been broken.
ARB_sample_shading doesn't set fs.uses_sample_shading in shader_info,
which causes us to enter this path to force per-sample interpolation,
but doing so breaks the shader if the PS prolog is used.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32910>
It just indicates that sample shading is enabled, which we were
checking already. The state is redundant.
Just check shader_info::fs::uses_sample_shading. ARB_sample_shading (GL3.3)
doesn't set fs.uses_sample_shading in shader_info (which is for GL4.0), and
that's why we have this codepath that forces per-sample interpolation.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32910>
All PS lowering that changes, adds, or removes system values based on
the shader key is done first, which is done in ac_nir_lower_ps_early and
other passes, so now we just need to gather them.
This should improve performance for ACO due to fewer VGPRs needed
for optimized shader variants of PS.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32910>
It will be done in a different place later, but for now, we need to get
it out of si_update_shader_binary_info because the function will be
removed and PS input gathering will be moved, which will be quite
complicated, but it's needed for having a linker in radeonsi.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32910>
This is a prerequisite for linking merged shaders.
At the beginning of get_nir_shader (renamed to get_nir_shaders), we get
both shaders that are going to be merged, and then we optimize them together
and pass them to LLVM or ACO-specific code as struct si_linked_shaders.
The code setting uses_instance_id is moved because the previous place
doesn't work with this new organization.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32910>
This splits shader variant compilation into the following stages:
* get_input_nir
* run_pre_link_optimization_passes
(not implemented yet: run linking optimizations here)
(not implemented yet: gather shader_info here)
* run_late_optimization_and_lowering_passes
This order is important when we start adding linking optimizations for
shader variants and start getting shader_info from shader variants instead
of input NIR.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32910>
We don't need to look at the framebuffer state and record how many color
buffers to write. Instead, we can deduce which color buffers are enabled
from spi_shader_col_format, which already does the right thing.
So PS epilogs only need a single bool flag that determines whether all
enabled color buffers should be written.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32910>
This adds an option into the prolog key to replace frag_coord.xy with
pixel_coord when sample shading is disabled, which is most of the time.
This reduces the number of input VGPRs.
It's already implement in ac_nir_lower_ps_early for monolithic shaders
and the PS prolog in ACO, so this just implements it for the PS prolog
in LLVM IR.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32910>
Using the used component count is not enough. We need to consider
the component mask because any component can be disabled. This might
fix tests.
This removes the component counting from ac_get_fs_input_vgpr_cnt
and determines the component mask where it's needed.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32910>
Liveness info can be huge, since with larger shaders it essentially
grows quadratically (linear increase in number of SSA defs *
linear increase in blocks).
Freeing liveness info early helps somewhat mitigate memory usage here.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29577>
LLVM 15 is pretty old, and notably not supported by either ANGLE nor
Skia anymore. So let's move up to LLVM 19 using packages provided by
LLVM themselves, apart from PPC and ARMv7 which don't have builds.
The Skia build now requires a bunch of new warning exclusions; hopefully
most of these are no longer needed when we can upgrade Skia shortly.
The ci-deb-repo revision has also been bumped to get us a new version of
xtensor which builds with LLVM 19, and a version of spirv-tools which
also works with LLVM 19.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Closes: mesa/mesa#11538
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
We don't actually need this anymore. We were previously using it to find
ccache, but Meson will do this for us. Now that we pass
-Wl,--fatal-warnings, we don't need to pass -Werror to the link stage
either.
This removes two shell execs, one subshell, and one call to each of grep
and printf, per compile.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
Enabling Werror on our code is good, but it's less good on external
projects. Some of the Rust subprojects are now failing due to warnings
exposed by the newer Rust toolchain in Fedora, which we don't care about.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
When building for the dynamic loader used by e.g. Clover, pipe_i915 was
the only target failing to declare a driver descriptor. This becomes an
error with more aggressive linkers.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: 87392385b5 ("gallium/drm: Define the DRM entrypoints in drm_helper.h")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
We now have to do five builds of dEQP: one each for tools, GL, GLES,
Vulkan (release branch), and Vulkan (main).
dEQP is not a quick build, with even the tools build taking ten minutes,
at least three of which go to just pulling the SPIRV-Tools source.
Building all five takes a cumulative 60 minutes (10 tools, 11 GL, 9
GLES, 15 VK release, 13 VK main). That doesn't give us a load of time to
build everything else we need.
Two hours is obviously a completely unreasonable amount of time to spend
doing builds, especially for jobs which shouldn't really exist. But the
yak shave to allow the container jobs to be able to run on non-b2c
hardware has been a long one, and with no big-bang solution turning up
any time soon, we need to be able to actually do rootfs builds.
So, let's do the worst possible thing and go for a gigantic timeout.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
Sitting here trying to get something else done tonight, I watched the
ASan and UBSan jobs, both on AArch64 and x86_64, regularly blow through
their timeouts.
They should be fixed to do less, but this makes them at least succeed in
the meantime.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
Building and linking drivers, Rust code, and tools, takes an inordinate
amount of time with sanitisers. That could be justified if we used the
results to test, but we don't.
Reduce the coverage to get reasonable runtimes back.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
Running the Meson tests doesn't take forever, but it does take a
noticeable amount of time.
For jobs in the critical path - like debian-testing and debian-arm64 -
we need them to complete as soon as possible to produce a build for the
hardware tests to consume. Running the tests here lengthens that time,
and introduces more hazard since the tests have previously been prone to
hitting timeouts, requiring the whole job to be retried before we can
proceed. These jobs also have build-only jobs which are not in the
critical path, and can run the tests just as well.
Running the tests under sanitisers is just too slow to deal with in
pre-merge pipelines.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
NEW util/conversion.rs
Adds traits `TryFromWithErr` and `TryIntoWithErr` and their
implementation for types with `TryFrom` and `TryInto` traits
former
```
try_into().map_err(|_| CL_OUT_OF_HOST_MEMORY)
try_from(val).map_err(|_| CL_OUT_OF_HOST_MEMORY)
```
can now be written as
```
try_into_with_err(CL_OUT_OF_HOST_MEMORY)
try_from_with_err(val, CL_OUT_OF_HOST_MEMORY)
```
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33267>
cat3 instructions read their 3rd src later than their first two srcs.
This was implemented in two different places: once for scheduling and
once for legalization. Extract this logic in a new helper and also add
similar logic for gat/swz there (which the scheduling logic failed to
account for).
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33183>
Preamble defs were rematerialized at the end of the preamble. However,
when some of the sources were defined inside control flow, this would
lead to these sources not dominating their use. Fix this by finding the
block that is dominated by all sources and inserting the new instruction
there.
Also make sure we only de-duplicate instructions if the new instruction
is dominated by the existing one.
Fixes a NIR validation error in Devil may cry 5.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: fdfe86aa52 ("ir3: Expand preamble rematerialization")
Fixes: 6a744ddebc ("ir3: Initial support for pushing globals with ldg.k")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33270>
This was accidentally deleted when rewriting to use common Vulkan
dynamic state. This meant we wouldn't correctly fall back when someone
accidentally used FDM together with multiple viewports.
Fixes: 97da0a7734 ("tu: Rewrite to use common Vulkan dynamic state")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33241>
Scheduling an alias.rt right before an alias.tex causes a GPU hang.
Follow the blob and schedule all alias.rt at the end of the preamble to
prevent this from happening.
Fixes a hang in Borderlands 3 on medium or higher graphics settings.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: 0aa9678d4d ("ir3: add support for alias.rt")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33238>
Textures opcodes can't read from the contant registers, however we can
just handle this fine in the native swizzle pass. Others like saturate
for tex instructions) can't happen anyway since we swithed to nir_to_tgsi
long time ago. However, keep the asserts just to be safe.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33066>
The pass tried to convert shaders to a SSA-like form. However since
we no longer allocate registers in NIR, and we try hard to keep the
SSA-like form during the later passes, this is now superfluous.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33066>
Prevents shader-db regression, since NIR puts just everything to x and the
pair scheduling is not smart enough to fix it later, espetially after
presubtract happens.
Together with the previous patches that move the shadow lovering to NIR
this results in the following shader-db stats:
RV530:
total instructions in shared programs: 129598 -> 128697 (-0.70%)
instructions in affected programs: 19001 -> 18100 (-4.74%)
helped: 124
HURT: 9
total presub in shared programs: 8554 -> 8314 (-2.81%)
presub in affected programs: 1099 -> 859 (-21.84%)
helped: 17
HURT: 50
total temps in shared programs: 17514 -> 17000 (-2.93%)
temps in affected programs: 1368 -> 854 (-37.57%)
helped: 45
HURT: 18
total cycles in shared programs: 191286 -> 190593 (-0.36%)
cycles in affected programs: 32369 -> 31676 (-2.14%)
helped: 110
HURT: 29
RV410:
total instructions in shared programs: 112805 -> 112618 (-0.17%)
instructions in affected programs: 7089 -> 6902 (-2.64%)
helped: 65
HURT: 21
total presub in shared programs: 3244 -> 3314 (2.16%)
presub in affected programs: 228 -> 298 (30.70%)
helped: 7
HURT: 47
total temps in shared programs: 18163 -> 18138 (-0.14%)
temps in affected programs: 710 -> 685 (-3.52%)
helped: 36
HURT: 19
total cycles in shared programs: 169530 -> 169369 (-0.09%)
cycles in affected programs: 11304 -> 11143 (-1.42%)
helped: 63
HURT: 27
The stats are a bit less awesome for Rv410, since it can't run the heavy
Unigine Tropics shaders where this helps the most due to the TEX
indirection limits.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33066>
This means we now do fragment shader-variants at the NIR level and we
therefore need to run nir_to_rc translation later during the shader
variant creation.
This is a temporary instruction count as well as registers count
regression, due to NIR putting everything to x instead of w, this is
fixed in the next commit which also shows some nice shader-db stats
improvements in total.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33066>
We only care that the negates of the relevant components are the same.
Specifically the assert would incorectly trigger for code like this
ADD temp[3].x, 1.250000 (0x3a).-x___, -const[0].x___;
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33066>
The texture_map functions can fail, due to for instance address-space
exhaustion during mmap calls. Handling this by asserting turns this
into a fatal error when doing debug builds, which might not be what
users want.
Instead, let's allow this to fail. This is alredy what we do for
util_clear_color_texture and util_clear_render_target.
While we're at it, let's add some breadcrumbs to applications here, by
emitting an error at the same time. We should really consider returning
a proper pipe_error here instead, but that requires changing a lot of
function signatures, as this function are used as an implementation of
p_context::resource_copy_region()... So let's save that for later.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32431>
The DRIVER_NAME variable is used to locate the DRIVER_NAME-skips.txt
file. It was not used for panfrost, so remove the three places where
it was set, assign it to panvk, and add a panvk-skips.txt file.
Additionally, properly track changes to this file.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32817>
Due to the slow startup time of deqp-vk, the previous default of
500 tests per group caused the jobs to run up to twice as slowly
compared to using a higher number of tests per group.
Since the CTS uprev did not introduce any new leaks that caused
the entire caselist to get marked as fails, increasing the number
of tests per group is considered safe and improves efficiency.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32817>
This is simply following the redirects the same way the browser does.
The new pages were manually verified to still contain the corresponding
information.
For URLs where this was not the case, see the next commits.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33159>
The Vulkan spec says:
"If logicOpEnable is VK_TRUE, then a logical operation selected by
logicOp is applied between each color attachment and the
fragment’s corresponding output value, and blending of all
attachments is treated as if it were disabled. Any attachments
using color formats for which logical operations are not supported
simply pass through the color values unmodified."
When logic op and blending are both enabled, logic op takes precedence
and values should be passed through unmodified. Also RB+ shouldn't
have any effects when blending is disabled.
Fixes new VKCTS coverage dEQP-VK.pipeline.*.logic_op_na_formats.*.
Fixes: 03b037a0e3 ("radv: disable logic op for float/srgb formats")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33235>
From OpenGL 4.6 - 8.23.1 Depth Texture Comparison Mode
Let Dt be the depth texture value and St be the stencil index
component. If there is no stencil component, the value of St is
undefined. Let Dref be the reference value, provided by the shader’s
texture lookup function. If the texture’s internal format indicates
a fixed-point depth texture, then Dt and Dref are clamped to the
range [0, 1]; otherwise no clamping is performed.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33140>
..where N = # of functions in the shader. We were accidentally reprocessing the
whole shader for every function impl. Noticed when reading a vtn_bindgen2
profile.
We elect to port the relevant part of the pass to instrctions_pass which fixes
the perf problem while deleting a pile of code.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33245>
Only keep context mutex locked while waiting for fence.
This fixes issue with multi-threaded use of VAAPI where SyncSurface
and SyncBuffer would block all contexts, even those used in different
threads. The issue exists for all API calls, however in most cases this
is not a big deal as most calls will return fast, but sync is expected
to take up to tens of ms.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33165>
Changes required after commit 44bda7c2
Fixes the following building error:
FAILED: out/target/product/x86_64/obj/SHARED_LIBRARIES/libglapi_intermediates/libglapi.so
...
'out/target/product/x86_64/obj/MESON_MESA3D/install/usr/local/lib/libglapi.so': No such file or directory
Fixes: 44bda7c2 ("dri: put shared-glapi into libgallium.*.so, remove the remap table to reduce GL dispatch overhead")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33224>
VINTRP(gfx6-gfx10.3) is mostly just VALU, but we treated it like memory
instructions as an afterthought. This had issues as VINTRP was never reordered
with itself, or other memory instructions. Reordering VINTRP in clauses
increases ILP. We don't really need collect_clause_dependencies for VINTRP
either, because they ususally have the same dependencies already. That means
we can still form VINTRP clauses by selecting preferably VINTRP after a
previous one.
Foz-DB Navi21:
Totals from 34184 (43.16% of 79206) affected shaders:
Instrs: 18811270 -> 18812046 (+0.00%); split: -0.01%, +0.02%
CodeSize: 103627276 -> 103630056 (+0.00%); split: -0.01%, +0.01%
Latency: 188379364 -> 187936731 (-0.23%); split: -0.27%, +0.03%
InvThroughput: 42600163 -> 42590608 (-0.02%); split: -0.03%, +0.00%
VClause: 378960 -> 378912 (-0.01%); split: -0.02%, +0.00%
SClause: 727560 -> 720573 (-0.96%); split: -1.08%, +0.12%
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Reviewed-by: Daniel Schürmann <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33111>
After the fix in commit b016f218fb (ci/android: fix meson C++
cross-compiler argument detection, 2025-01-14) the cross-build meson
hacks should not be necessary anymore for the CI builds to pass.
Remove the hacks making sure that the removed arguments are all in the
regular list of arguments passed through cpp.get_supported_arguments()
Reviewed-by: Rob Clark <robclark@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33209>
For whatever reason NXP decided to call the GC3000 in the i.MX6QP a
GC2000+. This being a lie is marked in the IP core by the upper half
of the revision register being all ones. The kernel driver already
fixes the model and revision when it encounters this core, but this
breaks matching in the HWDB, which uses the bogus model/rev from the
core.
Revert the fixup done by the kernel for the lookup in the HWDB.
Fixes: 2192e620bb ("etnaviv: hwdb: Add etna_query_feature_db(..)")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33223>
In unified uniform mode the constant memory is dynmically partitioned
between VS and FS, which allows to use far more FS constants than
currently supported with the fixed split when VS constant usage is low.
Limit computation taken from the Vivante kernel driver.
Fixes dEQP-GLES2.functional.uniform_api.random.79 on GPUs with
unified uniform support.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32983>
Unified uniform mode allows to dynamically partition the constant memory
by specifying the start of VS and FS constants within the memory area. Use
this to place the FS uniforms directly behind the VS uniforms, potentially
making more space available to FS uniforms.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32983>
This adds an option to replace frag_coord.xy with pixel_coord when sample
shading is disabled, which is most of the time. This reduces the number of
input VGPRs.
It's already implement in ac_nir_lower_ps_early for monolithic shaders.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33024>
- really update sample shading state when it's changed
- reduce log state bits in the shader key to 2 because we don't support
16x EQAA
- exit early from si_update_ps_iter_samples if ps_iter_sample has the same
value since the last call
- set missing wqm for the PS prolog (this might fix tests)
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33024>
In theory you can build a driver using OpenCL kernels with a
-Dmesa-clc=system. That shouldn't require any LLVM/Clang/etc...
But the checks to find the pre-compiled mesa_clc & vtn_bindgen
binaries are in meson files or conditions only triggered if you build
with LLVM (:
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Tested-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Dylan Baker <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33014>
This kernel was built using b2c's linux builder without any additional
patches... aside from the usual ones I apply for b2c, so we are almost
to the point where we can run a stable kernel on it!
The next uprev should be made from gfx-ci/linux rather than being
hosted on my server, but I would like to use a released kernel for
that.
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33162>
This Vulkan layer allows reporting a limited VRAM size to the
application. This layer can be useful for testing applications and
games which query for the memory budget adjusting their behavior
accordingly.
They layer does not set a hard limit on the amount of VRAM thus
applications can still make allocations even though the reported
budget might indicate no memory is left, if the set limit is lower
than of actually available VRAM.
Signed-off-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30095>
Rename the variable ANDROID_NDK to ANDROID_NDK_VERSION and only use it
to specify the version itself.
This makes it consistent with ANDROID_SDK_VERSION and it is also in
preparation for using the same variable to build ANGLE in the future.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33188>
This change moves freedreno specific ForEachMacros from the top level
.clang-format to the freedreno specific .clang-format.
This is done to avoid triggering CI for all drivers when making changes
to this list.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32107>
Whenever we insert a (nopN) on the previous instruction to add nops, we
initially add them to the current cycle count. However, existing (nopN)
fields are not accounted for. This means the if a (nopN) gets inserted
and the block is processed again, the cycle count will be too low and we
might insert more nops than necessary.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33178>
Instead the complicated logic we currently have, do this :
We start with this shader :
int main() {
...
if (...) {
SetMeshOutputsEXT(0, 0);
return;
} else {
SetMeshOutputsEXT(...);
}
...
}
We turn it into this :
int main() {
uint __temp_prim_count = 0;
...
if (...) {
__temp_prim_count = 0;
return;
} else {
__temp_prim_count = ...;
}
...
if (is_first_group_lane()) {
SetMeshOutputsEXT(..., __temp_prim_count);
}
}
This works because the SPIRV spec says this :
"The arguments are taken from the first invocation in each
workgroup. Any invocation must execute this instruction no more
than once and under uniform control flow."
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12388
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33038>
This supports everything the blob does.
The registers exist on later a6xx gens, but they would be way more
inconvenient to use since they're mixed up with binning/not-binning and
compression state, and I'm not sure if it works.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33152>
These fields don't actually enable binning, but rather disables the FS.
This seems to happen automatically on a7xx when binning, because the
blob doesn't set them specially during the binning pass.
Move them to rasterization, because RB_RENDER_CNTL will start depending
on rasterization state in the next commit.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33152>
When WSI is working in prime/dma-buf mode, it has one additional
VkBuffer or VkImage where the main VkImage is copied to without any
compression or tiling different from linear
The batch buffer to do this copy is created in
wsi_finish_create_blit_context(). It performs a barrier transitioning
the VkImage to VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL, performs the
copy, and then transitions it back to VK_IMAGE_LAYOUT_PRESENT_SRC_KHR.
However, in this prime/dma-buf mode, no display modifiers are involved,
which causes compression to be disabled when switching to
VK_IMAGE_LAYOUT_PRESENT_SRC_KHR.
This change adds an exception to allow the Vkimage to remain compressed
because we can handle the compressed-to-uncompressed copy.
Doing so fixes an issue that was reported with BMG + integrated GPU
and should also improve performance by keeping the VkImage compressed.
Cc: mesa-stable
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12354
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33044>
When encountering pipeline barriers in secondary command buffers that do
not start their renderpasses, our barrier logic would not detect the
need to flush existing draws, leading to race conditions in case of
subpassLoad.
This change ensures we flush existing draws when required in secondary
command buffers.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33182>
if e.g., multiview framebuffer is enabled, shader objects cannot be used,
requiring the bound shaders to be compiled into a pipeline on-demand
this is not knowable in advance and will always result in a stall
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33005>
Setting zs_update_operation = FORCE_EARLY for color preloads triggers
hangs in the dEQP-VK.rasterization.rasterization_order_attachment_access
depth/stencil tests. I didn't determine why this is the case, but the
DDK uses WEAK_EARLY for color preload, and doing the same here fixes the
hang.
WEAK_EARLY requires ATEST, so I removed .is_blit=true from the compiler
inputs.
There aren't any known hangs outside of the one set of vulkan CTS tests,
and in particular no known hangs in the gallium driver. Because the
reason for the hangs is not understood, I also changed the gallium
driver to use WEAK_EARLY, under the assumption that the same conditions
that trigger the hang in vulkan might occur in GL.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Fixes: edd98aac3f ("panfrost: Add support for native wallpapering on Bifrost")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32954>
On bifrost, zs_update_operation=STRONG_EARLY, is equivalent to
WEAK_EARLY except that it may test/update without waiting for pixel
dependencies if it can prove that the test will pass.
STRONG_EARLY no longer exists on valhall, and the value 2 is reserved.
Even on bifrost, all of our current uses of STRONG_EARLY are
incorrect. For color preload, the shader skips ATEST, so FORCE_EARLY is
required. In the no-FS case, ATEST is skipped by definition (because
there is no shader), so FORCE_EARLY is required.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Fixes: 519643bbe0 ("panfrost: Adjust the renderer state definition")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32954>
a7xx introduced support for aliasing render target components using
alias.rt. This allows components to be bound to uniform (const or
immediate) values in the preamble:
alias.rt.f32.0 rt0.y, c0.x
alias.rt.f32.0 rt1.z, (1.000000)
This aliases the 2nd component of RT0 to c0.x and the 3rd component of
RT1 to the immediate 1.0. All components of all 8 render targets can be
aliased.
This is implemented by replacing const and immediate components of the
RT sources of end with alias.rt instructions in the preamble. If no
preamble exists, an empty one is created.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31222>
a7xx introduced support for aliasing render target components using
alias.rt. This allows components to be bound to uniform (const or
immediate) values in the preamble:
alias.rt.f32.0 rt0.y, c0.x
alias.rt.f32.0 rt1.z, (1.000000)
This aliases the 2nd component of RT0 to c0.x and the 3rd component of
RT1 to the immediate 1.0. All components of all 8 render targets can be
aliased.
In addition to using alias.rt, the hardware needs to be informed about
which render target components are being aliased using the
SP_PS_ALIASED_COMPONENTS{_CONTROL} registers. This commit implements
those registers.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31222>
a7xx introduced support for aliasing render target components using
alias.rt. This allows components to be bound to uniform (const or
immediate) values in the preamble:
alias.rt.f32.0 rt0.y, c0.x
alias.rt.f32.0 rt1.z, (1.000000)
This aliases the 2nd component of RT0 to c0.x and the 3rd component of
RT1 to the immediate 1.0. All components of all 8 render targets can be
aliased.
In addition to using alias.rt, the hardware needs to be informed about
which render target components are being aliased using the
SP_PS_ALIASED_COMPONENTS{_CONTROL} registers. This commit implements
those registers.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31222>
The clear FS shaders will statically use slot numbers from 0 up to the
number of supported render targets. However, the driver will remap those
slots to the actual render targets being cleared.
This means that ir3 should not make any assumptions about the static
slot number in those cases. This is especially important when
implementing alias.rt, which statically encodes the render target.
Add an new ir3_shader_option (fragdata_dynamic_remap) which allows the
driver to indicate to ir3 that it will perform such dynamic remapping.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31222>
When alias.rt is used to alias certain output components, we might end
up with a situation where some, but not all, of the components of
collects end up being unused. This is currently not supported which
means we end up with useless moves (coming from copy lowering) for
aliased output components.
Fix this by adding support for partial wrmasks for collects in DCE. The
wrmasks are initially zeroed out and then updated based on the wrmask of
their users. Sources of collects for which the corresponding dst ends up
being unused are treated as unused as well. This allows us to remove
the useless output moves by simply updating the wrmask of the end
sources.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31222>
Allocate alias registers for an alias group while trying to minimize the
number of needed aliases. That is, if the allocated GPRs for the group
are (partially) consecutive, only allocate aliases to fill-in the gaps.
For example:
sam ..., @{r1.x, r5.z, r1.z}, ...
only needs a single alias:
alias.tex.b32.0 r1.y, r5.z
sam ..., r1.x, ...
Also, try to reuse allocations of previous groups. For example, this is
relatively common:
sam ..., @{r2.z, 0}, @{0}
Reusing the allocation of the first group for the second one gives this:
alias.tex.b32.0 r2.w, 0
sam ..., r2.z, r2.w
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31222>
alias.tex allows us to construct an "alias table" that creates a mapping
between virtual alias registers and concrete GPRs, consts, or
immediates. The following texture instruction will lookup its sources in
this table and use the mapped value instead. This has a few advantages:
- We don't have to allocate consecutive registers (necessary for many
tex sources) as we can just map them to consecutive alias registers.
- We don't have to allocate GPRs at all for consts and immediates.
- There's no delay penalty when initializing alias registers with consts
or immediates.
For example, this code:
mov.u32u32 r1.x, r3.z
mov.u32u32 r1.y, c0.x
mov.u32u32 r1.z, 0
(rpt2)nop
sam ..., r1.x, ...
Can be implemented as follows:
alias.tex.b32.2 r40.x, r3.z
alias.tex.b32.0 r40.y, c0.x
alias.tex.b32.0 r40.z, 0
sam ..., r40.x, ...
Note that the alias registers (r40.xyz in this case) do not occupy GPR
space.
(More intelligent allocation strategies are possible; e.g., just mapping
r3.w and r4.x to c0.x and 0. This is implemented by the next commit.)
Support for alias.tex is implemented in two passes in ir3.
In a first pass, sources of tex instructions are replaced by alias
sources (IR3_REG_ALIAS) as follows:
- movs from const/imm: replace with the const/imm;
- collects: replace with the sources of the collect;
- GPR sources: simply mark as alias.
This way, RA won't be forced to allocate consecutive registers for
collects and useless collects/movs can be DCE'd. Note that simply
lowering collects to aliases doesn't work because RA would assume that
killed sources of aliases are dead, while they are in fact live until
the tex instruction that uses them.
The second pass inserts alias.tex instructions in front of the tex
instructions that need them and fixes up the tex instruction's sources.
This pass needs to run post-RA as discussed above. It also needs to run
post-legalization as all the sync flags need to be inserted based on the
registers instructions actually use, not on the alias registers they
have as sources.
This commit uses a very simple allocation strategy for alias registers:
simply allocate consecutive registers starting from r40.x. Note that
this works because the alias table is reset after a tex instruction is
executed so we don't have to worry about aliasing a live register.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31222>
Alias registers allow us to allocate non-consecutive registers and remap
them to consecutive ones using alias.tex. We implement this by adding
the sources of collects directly to the sources of their users. This
way, RA treats them as scalar registers and we can remap them to
consecutive registers afterwards. To keep track of the scalar sources
that should be remapped together, the IR3_REG_FIRST_ALIAS flag is
introduced. Every source of such an "alias group" will have the
IR3_REG_ALIAS set, while the first one will also have
IR3_REG_FIRST_ALIAS set.
This commit also adds a number of helpers to iterate over sources while
keeping track of the original src index (i.e., before they were expanded
to alias goups), and to iterate the sources within an alias group. It
also introduces a new notation (@{regs...}) to clearly show alias groups
when printing instructions.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31222>
Take the properties of alias.{rt,tex} and its registers into account:
- Don't count alias registers for GPR usage;
- Allow all immediates in alias regs;
- Fix properties like is_barrier and (ss) support;
- alias.rt dst is not a GPR, don't use it in legalize/postsched to track
dependencies;
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31222>
The UNK field encodes the table size for alias.tex: the first alias.tex
instruction uses it to indicate how many follow (i.e., it is the total
table size minus one).
Also switch from using a src to a cat7 field to store this value which
makes it a bit easier to handle.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31222>
The alias scope and type bits are intertwined in the encoding:
- bit 47: low scope
- bit 48: type
- bit 49: high scope
- bit 50: type size
Combining the low and high scope bits, the value is used as follows:
- 0: tex
- 1: rt
- 2: mem
- 3: mem
I don't know what the difference between 2 and 3 is. The blob currently
doesn't use mem at all.
The type bit seems to be used to make a distinction between floating
point (f) and integer (b) sources. There doesn't seem to be any
functional difference and it only affects how immediates are displayed.
Note that I haven't exactly mimicked the blob in these cases:
- alias.tex.f16/32: the blob uses b16/32 while printing immediates in
floating point notation. I think it make more sense to use f16/32.
- alias.rt.b16/32: the blob uses i16/32 here. I think it makes more
sense to stick to a single notation (b).
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31222>
There is a single swap field for each color attachment, regardless of
whether it's in GMEM or not, and this does appear to be used in
GMEM mode when MUTABLEEN is set on the attachment. This means that when
a color attachment has a non-identity swap because it's mutable on a750,
we have to use the same corresponding swap when it's a source in a
GMEM resolve. When using the fastpath, we have to make sure that the
swaps match because there aren't separate fields for GMEM and sysmem
swap.
This fixes dEQP-VK.image.mutable.2d.*_b8g8r8a8_unorm_draw_copy_resolve
with TU_DEBUG=gmem.
Fixes: 247d11d635 ("tu: Allow UBWC with images with swapped formats.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33115>
We don't currently support building acceleration structures on the CPU
or indirect building in the common framework, and drivers using it don't
either, but drivers have to return non-NULL entrypoints for CPU building
functions if they claim to support VK_KHR_acceleration_structure. Add
stub entrypoints here so that drivers don't have to have this
boilerplate.
Fixes dEQP-VK.api.version_check.entry_points on turnip.
Fixes: 671e3a65a6 ("tu: Support VK_KHR_acceleration_structure")
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33153>
The alignment was considered only for offset, but its users
(at least ir3_nir_opt_preamble) expect the size itself to also
be aligned.
Fixes tests:
dEQP-VK.spirv_assembly.instruction.graphics.16bit_storage.struct_mixed_types.uniform_buffer_block_geom
dEQP-VK.spirv_assembly.instruction.graphics.16bit_storage.struct_mixed_types.uniform_buffer_block_tessc
dEQP-VK.spirv_assembly.instruction.graphics.16bit_storage.struct_mixed_types.uniform_buffer_block_tesse
gmem-dEQP-VK.spirv_assembly.instruction.graphics.16bit_storage.struct_mixed_types.uniform_buffer_block_tesse
Fixes: 922ef8e720
("ir3: Make allocation of consts more generic and order independent")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33161>
Previously, we just used the next block after a loop that
has a back-edge. This assumes that loop-exit blocks can
only be removed when falling through to the next block,
when in fact it can also be a jump to somewhere else,
in future even to some block before the actual loop.
12 (0.02% of 79395) affected shaders.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32477>
They might be needed as convergence point in order to
insert code (e.g. for loop alignment, wait states, etc.).
Totals from 1 (0.00% of 79395) affected shaders:
CodeSize: 12672 -> 12716 (+0.35%)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32477>
TS can be valid and flushed at the same time when no compression is
used. This state is beneficial if we needed to flush TS to the base
surface (filling cleared tiles) for any reason, but still use TS
state to accelerate read requests into PE or TX caches.
The current seqno based tracking of the TS flush state has a major
drawback with the following sequence of events:
1. fast clear surface (TS is now valid)
2. flush TS (base surface tiles filled, TS still valid,
flush seqno == surface seqno)
3. render to surface (surface seqno increased)
4. flush resource
Step 4 will now execute a full TS flush as the flush and surface seqnos
are different after rendering and TS is still valid, wasting memory
bandwidth to fill already filled tiled that are still marked as clear
in the TS state. If the TS has been flushed already, step 4 should be
a no-op.
Switch from the seqno based tracking to tracking the flush state itself,
marking the TS state un-/flushed as needed. With this boolean tracking
of the flush state step4 above will correctly see that the TS has already
been flushed since the last fast clear and skip the tile fill blit.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32956>
If we determine that the amount of varyings will fit within the 8-bit
offset of LD_VAR_BUF[_IMM], instruct the compiler to use it for varyings
and skip setting up Attribute Descriptors.
This should save a bit of memory and overhead in reading varyings.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32969>
Introduce a varying load count pass to get the maximum amount of varying
loads from a fragment shader (prior to optimization passes), in order to
only allocate as many Attribute Descriptors as required. This will
generally lead to smaller buffers in SRT0 for fragment shaders.
As the amount of ADs is now dynamic based on the shader, we need to
lower varying loads early for fragment shaders in v9+, as the amount of
ADs will determine the offset for dummy_sampler, required during
nir_lower_descriptors.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32969>
The current implementation uses LD_VAR_BUF[_IMM] to look up varyings,
which limits the number of varying components to 64 due to an 8-bit
offset value.
As this does not align to maxVertexOutputComponents (128), this change
replaces the use of LD_VAR_BUF[_IMM] with LD_VAR[_IMM] + Attribute
Descriptors, which do not have this limitation.
As allocating Attribute Descriptors is potentially expensive, this can
be further optimized by falling back to LD_VAR_BUF[_IMM] in cases where
we can ensure we do not use more than 64 varying components.
This change currently does not change behavior for gallium/panfrost,
though that should be done as well.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32969>
The fields "Attribute stride" and "Packet stride" are in the wrong
order, and "Packet stride" should not be shr() modified.
This has probably not shown up as an issue before due to the use of
LD_VAR_BUF[_IMM] for varyings, which does not require us to create
Attribute Descriptors with type vertex_packet.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32969>
If line smooth, stipple, quad_prims and a collection of other things are needed, zink produces a geometry shader to create them.
This code is disabling that from happening when there is no geometry shader support.
This removes a constant barrage of validation issues when trying to draw basic triangles.
Some of this missing functionality will be added back in later.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33059>
This returns the underlying device pointer but as an opaque
uintptr_t.
This will be required because libdrm_amdgpu will return the
same device when called multiple times from the same process.
radeonsi relies on the pointer value to identify if the device
are the same and adjust the synchronisation logic based on that.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33081>
This reported support for Profile2 on all VCNs that support Profile0
and reported no supported formats if Profile2 was not supported.
Instead, we should not advertise the Profile2 at all if not supported.
Fixes: e359b3c525 ("radeonsi/vcn: support 12bit YUV420 AV1 decoding")
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33092>
The progressive YUV shader used in vl_compositor_yuv_deint_full
does the same thing as util_compute_blit, but it also supports rotation.
Remove vlVaPostProcBlit and instead move the code to vlVaPostProcCompositor.
Reviewed-by: Thong Thai <thong.thai@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32919>
We're already limiting the maximum texture-size based on the available
system memory, so we shouldn't really need to limit this here. In
addition, the state-tracker also limits the max framebuffer size to
16384, so we don't have to worry about limiting this to the framebuffer
size either.
So I don't think we have a good reason to artificially limit the texture
size here. This allows us to support larger textures than 8192, which is
especially useful to support OpenCL images with RustiCL.
Unfortunately, while the HW supports up to 64k texture sizes, Gallium
currently caps us at 32k. So let's stick with that as the new limit for
now.
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32866>
We don't want huge textures to take up large amounts of system memory.
On a system with 1GB of RAM, this would limit us to 256 MB, which is the
same memory usage as a texture of 8192 x 8192 with 4 bytes per
component, which is what we currently limit max texture size to anyway.
The goal here is really to allow using larger textures on systems with
more memory, but that bit comes in a later patch in this series.
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32866>
We're doing a better job at selecting the tiler hierarchy mask in PanVK,
so let's move that to common code and reuse it for the Gallium driver as
well.
The logic to disable the first level for large tile-sizes has been left
at the call-sites, because this is specific to V10 GPUs and later, so it
doesn't apply to the JM code-paths.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32866>
We can handle invalidation of the FBO attachments at job
creation. It solves that we were skipping invalidations in jobs
that had been created by a clear call, as before this change
invalidations were only taken into account the first draw calls
of the job. In these cases where there is a clear after FB
invalidation the resource attachment was tracked as invalidated
for more time than expected. So the stores of the job with the
clear were not being loaded by the next job attaching it because
of the not correct application of the invalidation.
Fixes: 6c46890325 ("v3d: avoid load/store of tile buffer on invalidated framebuffer")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12456
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33148>
When a 2D_ARRAY view of a 3D image is created, the layer count of the 2D
view should be based on the depth of the 3D image. When
VK_REMAINING_ARRAY_LAYERS is used, we were incorrectly calculating them
from the layer count of the base image.
Fixes future tests: dEQP-VK.renderpass*.remaining_array_layers.*
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33075>
On AMD, this is a clear win. 2.0 is a free constant,
the multiplication can be fused into fma, or it can
be done as a free output modifier. Otherwise, fmul
and fadd have the same throughput/latency, with the only
possible downside being potentially power consumption.
For other hardware this might not be as clear,
but we should at least choose one option for NIR because
it allows more CSE.
Foz-DB Navi21:
Totals from 12231 (15.41% of 79395) affected shaders:
MaxWaves: 309068 -> 309032 (-0.01%)
Instrs: 11826395 -> 11790132 (-0.31%); split: -0.31%, +0.00%
CodeSize: 63531496 -> 63512868 (-0.03%); split: -0.03%, +0.00%
VGPRs: 551256 -> 551328 (+0.01%); split: -0.00%, +0.02%
SpillSGPRs: 984 -> 979 (-0.51%)
Latency: 88486492 -> 88394296 (-0.10%); split: -0.11%, +0.01%
InvThroughput: 22360595 -> 22300790 (-0.27%); split: -0.27%, +0.00%
VClause: 226267 -> 226273 (+0.00%); split: -0.01%, +0.01%
SClause: 293820 -> 293783 (-0.01%); split: -0.02%, +0.00%
Copies: 727187 -> 727106 (-0.01%); split: -0.03%, +0.02%
PreSGPRs: 539623 -> 539625 (+0.00%)
PreVGPRs: 440843 -> 440946 (+0.02%); split: -0.00%, +0.03%
VALU: 8324962 -> 8288809 (-0.43%); split: -0.43%, +0.00%
SALU: 1278550 -> 1278538 (-0.00%); split: -0.00%, +0.00%
VMEM: 440600 -> 440599 (-0.00%)
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32989>
The drm device file is closed and re-opened between perfetto traces. So
we either need to re-create the fd_device, or use fd_device_new_dup() so
we hold on to our own fd. The former is preferred so that the kernel
can realize when we are no longer reading the perfcntrs.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33073>
Requests with no reply will report errors by default to the event
loop, which then usually cause the not very useful log like this
to be printed:
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 149 ()
Minor opcode of failed request: 2
Serial number of failed request: 33
Current serial number in output stream: 34
This commit introduce some helpers to handle the xcb errors in Mesa,
and be able to report errors properly.
For instance the same error will now log:
MESA: error: dri3_alloc_render_buffer:1634 xcb_dri3_pixmap_from_buffer[s] failed
MESA: error: X error: 11
It's not fixing the underlying issue, but at least now tests like
"glx-visuals-stencil -pixmap" and "glx-visuals-depth pixmap" fail
properly.
cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33036>
This allows us to drop the reboot condition on SaharaMode which means
that every time the reboot pattern is hit, it is due to a test
execution issue (GPU hang) and not something unrelated to the job.
Additionally, this allows us to try booting up to 5 times which should
help boot reliability.
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32572>
This will be helpful for DUTs that do not boot reliably due to firmware
issue as it will allow us to specify a boot retry count that only
counts towards booting linux and not other issues found during test
execution (like hitting a GPU hang).
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32572>
Indeed, has_streamout is not yet properly initialized at the time
of the call of r600_init_screen_caps(). This change fixes this
issue.
Here is the issue visible on palm at the glxinfo level; the right column is affected:
Preferred profile: core (0x1) | Preferred profile: compat (0x2)
Max core profile version: 4.5 | Max core profile version: 0.0
Max compat profile version: 4.5 | Max compat profile version: 2.1
Max GLES1 profile version: 1.1 Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1 | Max GLES[23] profile version: 2.0
Fixes: 7cd606f01b ("r600: add r600_init_screen_caps")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33106>
It's not rare when only last few draws in a big renderpass disable
LRZ, we shouldn't bail out in such case.
If LRZ is disabled in dir tracking bit during binning - LRZ would
be disabled for the whole IB in the tiling step, so we should avoid
disabling via dir tracking bit and track the state inside the driver.
This doesn't work with secondary command buffers (and renderpass
resume/suspend), in such cases we have to disable LRZ via dir tracking
bit, if LRZ is not valid.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32868>
If blend LRZ state was already calculated from static info,
re-calculating it with dynamic state would bring stale values
and therefor result in a wrong calculations.
This resulted in LRZ being disabled when it should have not in
native VK titles.
CC: mesa-stable
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32868>
Currently, when allocating the dst of shared collects, the registers of
its srcs would only be reused if they are killed. This results in a lot
of needless moves due to suboptimal register allocation.
This commit addresses this generically: allow unavailable registers to
be used for a new dst iff it shares a merge set with, and has the same
offset as, the currently live value.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32021>
Detecting non-trivial collects after the fact, i.e., once they are
created by a register assignment of their dst, does not work as this may
cause two different intervals to share a physreg. For example:
_meta:collect sssa_361:150(r50.x) (wrmask=0xf),
sssa_19:12(r50.x), sssa_103:13(r50.y),
sssa_355:102(r51.z), sssa_356:103(r51.w)
This is a non-trivial collect with a partial overlap with one of its
child intervals. After moving its dst to a new interval, it will have
the same physreg as the existing interval for sssa_19, causing all sorts
of trouble for RA.
Prevent this by detecting that a future collect may become non-trivial
at the moment one of its sources gets a register assignment that does
not correspond with it merge set's preferred reg and allocating a new
interval for this component.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: b36a7ce0f1 ("ir3/ra: prevent moving source intervals for shared collects")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32021>
The userq packets are added using _pkt_begin(), _pkt_add(), _pkt_end()
functions. As of now _pkt_being() and _pkt_add() is called once. It
is not advisible to update wptr value in mqd multiple times. Hence use
next_wptr as cache in the macros and update mqd mptr before job submission
only once.
Suggested-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32700>
The signal ioctl should only be called after guaranteeing that the hardware
started working on the submissions and that is only after doorbell is ringed.
Otherwise it can in theory happen that the application creates the fence and
is then interrupted before ringing the doorbell. That can result in a GPU
reset because the fence times out.
Suggested-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32700>
Determine whether the device has hardware raytracing support early, and
then use this result where needed, instead of checking for `gfx_level`
every time.
This is a prerequisite for CYAN_SKILLFISH chip enablement. This chip is
still GFX10, not GFX10_3, but has hardware support for accelerated
`image_bvh{,64}_intersect_ray` instructions. Just checking for `gfx_level`
is insufficient for it.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33109>
This should let us lower the RT query stack to registers instead of
scratch by getting rid of the rest of the members of the ray query
struct. This gives a 24% decrease in total time for 3DMark InVitro.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28447>
Remove the redundant error that will never be hit in practice (because
if fd_dev_name() succeeds then so will fd_dev_info()) and move it up so
that we can use the info when generating the name.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28447>
There is native support for D3D-style untyped UAVs, which are an unsized
array of "records."
This will be needed for acceleration structures, because normal SSBO
descriptors aren't large enough to cover all the 128-byte instance
descriptors for the maximum number of instances (2**24).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28447>
Make sure that struct vk_bvh_geometry_data is defined before
vk_fill_geometry_data(), to fix this error:
In file included from ../src/freedreno/vulkan/tu_acceleration_structure.cc:29:
../src/vulkan/runtime/vk_acceleration_structure.h:138:1: error: 'vk_fill_geometry_data' has C-linkage specified, but returns incomplete type 'struct vk_bvh_geometry_data' which could be incompatible with C [-Werror,-Wreturn-type-c-linkage]
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28447>
Currently, nir_lower_printf depends on a per-nir_shader table, writing out
indices into the printf buffer. This works for real OpenCL implementations
(rusticl, microsoft) which can associate the printf buffer with a particular
kernel, I guess. (Actually it's not clear to me that it works well there either
but that's not my problem.)
This mechanism is unsuitable for internal driver shaders, where printfs with
unique format strings can come from many different nir_shaders. There are two
current solutions in tree to this for driver CL:
* Honeykrisp: Only use one single nir_shader (libagx). This prevents us from
using printf in common CL and requires extra driver tracking. It won't work
with my upcoming vtn_bindgen rework, which is why I'm addressing this now.
* Anv: Offset format-string indices by a dynamic "base identifier" using relocs
or a push constant, then pool format strings into a table from nir_shader's
across the device. The problem here is that these indices now depend on the
order that nir_shaders are seen (which causes a mess for caching if relocs are
used, or requires extra push constants and extra bookkeping if relocs aren't
used). And the driver tracking required to do this pooling correctly is even
more complicated than what Honeykrisp does. I do not want every driver in-tree
needing to go down this path, and it wouldn't work with my upcoming
vtn_bindgen.
This MR introduces an alternate approach: rather than writing indices into the
table, we instead hash the format string itself and write the hash. That doesn't
depend on what nir_shader we came from, so we can freely mix & match and get
consistent hashes. That greatly alleviates driver tracking burden. To make that
possible, we need a global hash table mapping hashed format identifiers to the
format strings themselves.
That approach still requires a step to "register" format strings into the table.
That step would not be required if we wrote the actual strings themselves into
the table, but that was ruled out for performance/code size reasons. However, we
do not want drivers to need to explicitly register all the strings they use,
because once we have OpenCL in common code via vtn_bindgen2, drivers won't know
all the strings they use. Fortunately, there's a neat solution for that too.
By making this global table a singleton (with internal locking), vtn_bindgen2
can automatically register format strings via a static constructor. In
conjunction with the infrastructure added here, that eliminates all driver
bookkeeping required for format-strings.
The code itself is inspired by the glsl type singleton. Is it pretty? Not
really, but it gets the job done well.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33067>
We actually want to know if the backing memory is the same, it's also
easier to implement than checking on the parent memory object.
This will also allow for more flexibility if more memory types are
supported, e.g. proper SVM allocations.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32581>
This will handle the raw memory operations in the future, mostly focused
on guaranteeing consistency across devices.
It also handles sub allocation because it is the better place of tracking
this.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32581>
Various vkd3d-proton tests run via Turnip exposed an issue with the
a7xx-specific instantiation of the fd_lrzfc_layout struct used to allocate
memory for LRZ fast-clear operations.
The correct layout is quite bigger in size, and the duplicated FC buffers
are positioned at the beginning and the end of it. Smaller part of the area
in the middle is used for metadata, but it already seems to be used more
extensively than how we currently understand it.
Fixes in vkd3d-proton on tu/a750:
test_clear_depth_stencil_view
test_copy_texture
test_early_depth_stencil_tests
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33080>
This job is somehow failing to expand $RUNNER_TAG, and it seems to have
happened around the time that the last entry from the variables list was
removed.
Let's remove this, it's no longer needed anyway. And it seems to fix the
problem, so yay.
Fixes: 61d9c47944 ("ci/lava: Use CI_JOB_TIMEOUT instead of separate variable")
Reviewed-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33086>
Without this, WQM is only used for the lds_param_load like this:
s_wqm_b64 exec, exec
lds_param_load v5, attr0.x wait_vdst:15
s_mov_b64 exec, s[0:1]
v_mov_b32_dpp v5, v5 quad_perm:[0,0,0,0] row_mask:0xf bank_mask:0xf
With this change we get:
s_wqm_b64 exec, exec
lds_param_load v5, attr0.x wait_vdst:15
s_mov_b64 exec, s[0:1]
...
s_wqm_b64 exec, exec
v_mov_b32_dpp v5, v5 quad_perm:[0,0,0,0] row_mask:0xf bank_mask:0xf
s_mov_b64 exec, s[0:1]
This fixes KHR-GL46.shaders.uniform_block.random.nested_structs_instance_arrays.0
and other similar tests with LLVM.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32959>
The documentation says that if we don't use force_delta, the LOD will be
-infinity for non-active lanes before bias and clamp are applied. This
is not what we want, so let's instead assume all threads are active, and
let helper-invocations do their job to compute correct values.
While this is only needed for the second iteration, let's just leave it
on for both for simplicity.
Fixes: e317136536 ("pan/va: Add support for nir_texop_lod")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33069>
With the improved GPU recovery thanks to the new kernel, we can now
complete a full, non-fractioned run on the a660 in just over an hour.
To stay within this runtime, the fractions for the gmem-forced runs
have been increased.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Reviewed-by: David Heidelberg <None>
Reviewed-by: Sergi Blanch Torné <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32788>
Buffers with compression enabled (eg. DCC) have auxiliary planes that
needs to be all imported, but should not be used to create sampler views
and surfaces.
Only use main planes and ignore the remaining planes.
Also remove vl_video_buffer::num_planes as it's now unused.
Cc: mesa-stable
Acked-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32893>
MoltenVK fails to create a depth format target if `optimalDeviceAccess`, `info.have_EXT_host_image_copy` and `VK_IMAGE_USAGE_HOST_TRANSFER_BIT_EXT` are in used.
The specification seems to claim it is not needed if `hic.identicalMemoryLayout` is set, so for a MoltenVK build unset optimalDeviceAccess.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32651>
MoltenVK support for VK_DYNAMIC_STATE_VERTEX_INPUT_BINDING_STRIDE depends on the Metal API version in use. Which is directly related to the MacOS version.
Even if all the correct extensions or Vk versions are supported.
Detect if the feature is supported, assume it is not on MacOS unless told otherwise, and adjust the pipelines to honor this.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32651>
Applications tend to forget to describe subpass dependencies, especially
when it comes to write -> read dependencies on attachments. The
proprietary driver forces "others" invalidation as a workaround, and this
invalidation even became implicit (done as part of the RUN_FRAGMENT) on
v13+.
We will consider adding a dri-conf hook for this option in the future,
but for now, let's just keep it as an opt-in debug flag.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33056>
On the host side virglrenderer creates dmabuf on demand when:
* cpu mapping is requested
* setting up scan out
* sharing buffers between guest processes
On-demand dmabuf creation only works if the ctx that created the
BO still exists and knows about this BO. This assumption works ok for
the first 2 cases, but can break with the last one (and it does cause
issues on Android). eg:
* process A allocates BO and exports it as a guest dmabuf
* process A closes its handle to the BO (-> detach_resource)
* process B imports the guest dmabuf -> this triggers the attach_resource
function in virglrenderer. If the given resource isn't a
VIRGL_RESOURCE_FD_DMABUF it'll try to get one... But for this to work,
process A needs to be used -> this fails because this resource was
detached from it.
The reason we create dmabuf on demand is to avoid hitting the number of
open file descriptor limit. So to cover the 3rd case, we'll use the
VIRTGPU_BLOB_FLAG_USE_SHAREABLE flag, but try to limit to as few possible
buffers as possible.
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658>
The virtio-gpu guest kmd reports timelines as supported, so querying
DRM_CAP_SYNCOBJ_TIMELINE as vk_drm_syncobj_get_type() does will return
true.
The native context code on the other hand doesn't support timelines,
and support is disabled in the "ac/virtio: disable timeline_syncobj support"
commit.
Fix the inconsistency by manually disabling timeline support when
info.has_timeline_syncobj is false.
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658>
No big code changes are needed to support virtio. The main caveat with
radv is about buffer allocations.
Allocating a cpu visible buffer requires the host process (eg qemu) to
create a dmabuf, mmap it, then map the host CPU address into the guest
application CPU address space.
The first issue is about the number of dmabuf created because we
might hit the number of open file limit. The host process limit can
be raised but we would hit the second issue - at least on qemu:
there's a limit on how many sections can be mapped and ultimately
we hit this assert:
assert(map->sections_nb < TARGET_PAGE_SIZE);
(the third issue is a performance one: these operations have a cost,
and this increases some Vulkan app loading times)
radeonsi is not really affected because it's using pb_slab to
suballocate small buffers from larger ones.
radv on the other hand doesn't, so if an app decides to allocate
lots of cpu visible small buffers, we're likely to fail.
Earlier versions of the amdgpu nctx code had a suballoctor, but it
was removed to simplified the code. It could be restored later; or
radv could be modified to use a suballocator (like anv does AFAICT).
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658>
Native context support is implemented by diverting the libdrm_amdgpu functions
into new functions that use virtio-gpu.
VA allocations are done directly in the guest, using newly exposed libdrm_amdgpu
helpers (retrieved through dlopen/dlsym).
Guest <-> Host roundtrips can be expensive so we try to avoid them as much as
possible. When possible we also don't wait for the host reply in case where
it's not needed to get correct result.
Implicit sync works because virtio-gpu commands are submitted in order to the
host (there a single queue per device, shared by all the guest processes).
virtio-gpu also only supports one context per file description (but multiple
file descriptions per process) while amdgpu only allows one fd per process,
but multiple contexts per fd. This causes synchronization problems, because
virtio-gpu drops all sync primitive if they belong to the same fd/context/ring:
ie the amdgpu_ctx can't be expressed in virtio-gpu terms.
For now the solution is to only allocate a single amdgpu_ctx per application.
Contrary to radeonsi/radv, amdgpu_virtio can use libdrm_amdgpu directly: the
ones that don't rely on ioctl() are safe to use here.
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658>
This is required to implement virtio native-context.
In a virtualized environment, most of the functions provided
by libdrm_amdgpu will be implemented using virtio.
This allows to implement efficient virtualization, by
forwarding the kernel API to the host, instead of the GL/VK calls.
Similarly, the raw 'fd' or 'gem_handle' arguments are replaced
by opaque types. This allows to encapsulate all the needed
state in the handle, and use unmodified API between baremetal
and virtualized contexts.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658>
This unifies the behaviour between the LAVA, baremetal, and CI-Tron
farms by ensuring every job has access and runs the same scripts.
The init-* scripts are however still sourced from outside the build
artifact, hopefully not for too long.
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33026>
Just like other input loads, radeonsi needs to know the barycentric
coordinates for it. This adds the src and determines the optimal barycentric
coordinates in nir_lower_point_smooth, the only producer of the intrinsic.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33046>
When using Zink with VK_EXT_descriptor_buffer enabled on IMG proprietary
drivers, the rendering behavior is incorrect and uniforms are not
updated properly (the gears of es2gears_x11 become all red and
overlaps).
Use lazy descriptors for IMG proprietary driver unless explicitly
overriden for testing purpose.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32343>
The goal is to reduce symbol pollution, especially when building
with Perfetto support, which previously led to an excessive number
of exported symbols.
objdump -T build/src/egl/libEGL_mesa.so.0.0.0 | grep perfetto | wc -l
- before: 6963
- after: 0
The new egl.sym version script explicitly exports only relevant egl and
MesaGLInteropEGL symbols, while marking all others as local.
While this change effectively removes all Perfetto-related exported symbols,
some C++ standard library symbols remain as undefined. These are pulled in
by the linker due to dependencies.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33001>
Initial "compilable" version of mesa/gfxstream on Windows. For now it is
achieved through "#if !DETECT_OS_WINDOWS" directives hence it is NOT
functional. The compilation works with mingw only and the compilation is
tested in a windows host. This commit is intended to only pass the
compilation process without errors.
Also created stub code for a future windows implementation.
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32795>
After the SPIR-V generator is optimized to generate multiple constant
types, the shader compiler of Imagination proprietary drivers can no
longer correctly handle these shaders and will bail out.
Handle this as a driver quirk and revert to the old behavior with only
uint constants when IMG proprietary drivers are detected.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32342>
Right now, we have a problem when we flush draws inside a render pass
and we don't have enough information to re-emit the framebuffer/tiler
descriptors.
Turns out the only situations where this happens is when an occlusion
query end happens, but we shouldn't really flush the draws in that case.
What we should do instead is record the OQ in our command buffer, so we
can signal OQ availability when the fragment job is done.
In order to solve that, we add an OQ chain to the command buffer to
track OQs ending inside the render pass. We then walk this chain at
fragment job emission time to signal the syncobjs attached to each
query.
This also simplifies the whole occlusion query synchronization model:
instead of waiting for each syncobj individually, we now wait on
the iterators to make sure all OQs have landed. Thanks to this new
synchronization, we can batch OQ reset/copy operations and make the
command stream a lot shorter when big query ranges are copied/reset.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Benjamin Lee <benjamin.lee@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32973>
The SYSTEM scope triggers CPU interrupts we don't really need, so let's
use the CSG scope to avoid those. Note that the scope doesn't encode
the visibility aspect, meaning changes to the sync object with a CSG
scope will still be instantly visible to the CPU, it's just that the
CPU needs to poll the value to detect a change, which is basically what
we're doing for syncobjs attached to events/queries, so we're good.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Benjamin Lee <benjamin.lee@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32973>
Descriptor sets which have `size` of `0`, such as a descriptor set
with just dynamic descriptors, weren't being freed in
`vkDestroyDescriptorPool()` since that relies on keeping track of
descriptor sets in the `entries` list. Keep track of them in the
`entries` list.
Fixes a memory leak in:
dEQP-VK.binding_model.descriptor_copy.compute.uniform_buffer_dynamic_5
Signed-off-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32968>
We can disable FDM in the renderpass based on
`tu_render_pass_disable_fdm()` however a pipeline could have
been bound before starting the renderpass which had
`...RENDERING_FRAGMENT_DENSITY_MAP_ATTACHMENT_BIT_EXT` set, in
which case the shader is compiled with FDM support. We still
need to apply the patchpoints. Previously `patchpoints_ctx` was
created only based on whether FDM was enabled in the renderpass,
which was leading to the patchpoints being allocated with no
context so they were never getting freed. Now setup `patchpoint_ctx`
regardless of FDM being disabled or not.
Fixes memory leaks in some tests from:
dEQP-VK.dynamic_rendering.*_cmd_buff.fragment_density_map.*
e.g.
dEQP-VK.dynamic_rendering.partial_secondary_cmd_buff
.fragment_density_map.2_views .render.divisible_density_size
.1_sample.static_subsampled_1_2
Fixes: 05f96dd00f ("tu: Add core FDM patchpoint infrastructure")
Signed-off-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32968>
When no attachments are used in a renderpass we should ignore the
clear values. It seems to be valid applications to still pass clear
values in such a case.
Fixes memory leaks in some tests from:
dEQP-VK.image.texel_view_compatible.graphic.basic.*d_image.texture_read.*
dEQP-VK.image.texel_view_compatible.graphic.extended.*d_image.texture_read.*
Signed-off-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32968>
On Bifrost/Midgard, when an attribute has a non-zero divisors, the
attribute offset is tweaked to take the base_instance into account,
which implies we have to re-emit the attributes if the base instance
value changed.
Let's not bother tracking the last base instance and re-emit
unconditionally in that case, which is still better than what we had
before 3db963a135 ("panfrost: Emit attribs in
panfrost_update_state_3d() on bifrost/midgard") and fixes the regression
introduced by this commit.
Fixes: 3db963a135 ("panfrost: Emit attribs in panfrost_update_state_3d() on bifrost/midgard")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Tested-By: Chris Healy <healych@amazon.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33010>
Although in some cases python 3.x will come without "3" as suffix,
"python3" should still be preferred because sometimes "python" is python
2.x instead.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33025>
Halti5 has no interpolation setting which will take into account the
rasterizer flatshade state. Force the interpolation qualifier to flatshade
for the color varyings when API level flatshade is enabled. Only set the
new bit in the shader key on halti5 GPUs to avoid generating unnecessary
shader variants on GPUs where the rasterizer flatshade state is properly
applied to the varyings.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32991>
During loading of snapshot, there will be a single-threaded
decoder that aquires the same mReconstructionMutex, repeatedly.
Since the mReconstructionMutex is intentionally changed to
be non-recursive, we should not aquire it at the beginning of
load call; otherwise, we will be deadlock the decoder thread.
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33018>
Replace tryLock / unlock with regular scoped lock now that the
"extra handles" have been moved out of VkReconstruction and into
the VkSnapshotApiCallInfo.
Switch to regular std::mutex and std::lock_guard.
Annotate mReconstruction with GUARDED_BY to start to get more
thread safety analysis.
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33018>
... so that `VkDecoderGlobalState` can append additional information
needed for snapshotting. Specifically, `VkDecoderGlobalState` may create
additional boxed handles that are not visible directly in the API surface.
For example, `vkCreateDevice()` creates boxed handles for the `VkQueue`-s
and `vkCreateDescriptorPool()` creates boxed handles for pre-allocated
`VkDescriptorSets`. These boxed handles are not recoverable from the API
for `vkCreateDevice()` nor `vkCreateDescriptorPool()` directly. This was
previously worked around by just sticking the extra boxed handles in
`VkReconstruction::mExtraHandlesForNextApi` but this is not thread safe.
Instead, let's give `VkDecoderGlobalState` and `VkDecoderSnapshot` exclusive
access to individual `VkSnapshotApiCallInfo` objects.
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33018>
Removes the additional saving of opcode and packet len as this is
all available from within the packet itself.
Removes the "trace" position from `VulkanMemReadingStream` as these
seemed to only be used for getting the packet start and packet size
but these are already available.
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33018>
Indirect draw calls upload VS params themselves, if indirect draw call
has zero instances GPU seem to still try to upload consts, however
with zer instances it doesn't apply draw state. Without the draw state
the the HLSQ_VS_CNTL values is stale, so less constants may be specified
than draw call expects. It is found that if CP_DRAW_INDIRECT_MULTI_1_DST_OFF
is less than 0x3f - GPU is happy even if the constlen is less than that.
As a workaround we allocate driver params first and ensure that VS
constlen always has the minimum size which is enough to upload driver
params.
Fixes one of the GPU hangs in "Disney Epic Mickey: Rebrushed" on a750.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32140>
With all consts going through generic allocations it's now possible
to call ir3_setup_const_state once, and have lowerings that dynamically
lower things to consts just to update the max consts being used.
The only exception for now are immediates, since they eat up the space
that was left and allocated much later.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32140>
The order of allocation was backed into ir3_setup_const_state and
some other parts of ir3, which is rather brittle.
And don't assume offsets for consts in other part of code, their order
and offset calculation is not guaranteed.
This also potentially fixes indirect UBO effect on constlen size.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32140>
In the current API, precomp implicitly assumes full barriers both before & after
every dispatch. That's not good for performance. However, dropping the barriers
and requiring user to explicitly call barrier functions before/after would have
bad ergonomics.
So, we add a new parameter to the standard MESA_DISPATCH_PRECOMP signature
representing the barriers required around the dispatch. As usual, the actual
type & semantic is left to drivers to define what makes sense for their
hardware. We just reserve the place for it. (I think most drivers will want
bitflags here, but I don't think the actual flags are worth. If a driver wanted
to use a struct here, that would work too.)
Since the asahi stack doesn't do anything clever with barriers yet, we
mechnically add an AGX_BARRIER_ALL barrier to all precomp users in-tree. We can
optimize that later, this just gets the flag-day change in with no functional
change.
For JM panfrost, this will provide a convenient place to stash both their "job
barrier" bit and their "suppress prefetch" bit (which is really a sort of
barrier / cache flush, if you think about it).
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32980>
When cross-building for Android meson fails to find supported compiler
arguments for the C++ cross-compiler, e.g.:
```
Compiler for C++ supports arguments -Wno-array-bounds: NO (cached)
Compiler for C++ supports arguments -Wno-overflow: NO
Compiler for C++ supports arguments -Wno-c++11-narrowing: NO (cached)
Compiler for C++ supports arguments -Wno-vla-cxx-extension: NO (cached)
```
This is due to an **unrelated** and more generic compilation failure
when testing for the supported arguments, e.g.:
```
Command line: `/tmp/android-ndk-r27c/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android34-clang++ -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -static-libstdc++ /home/ao2/Collabora/GOO0042/mesa/_build/meson-private/tmpv6_hke9l/testfile.cpp -o /home/ao2/Collabora/GOO0042/mesa/_build/meson-private/tmpv6_hke9l/output.obj -c -Wno-error=c99-designator -Wno-error=unused-variable -Wno-error=unused-but-set-variable -Wno-error=self-assign -D_FILE_OFFSET_BITS=64 -O0 -fpermissive -Werror=implicit-function-declaration -Werror=unknown-warning-option -Werror=unused-command-line-argument -Werror=ignored-optimization-argument -Wvla-cxx-extension -Wno-vla-cxx-extension` -> 1
stderr:
clang++: error: argument unused during compilation: '-static-libstdc++' [-Werror,-Wunused-command-line-argument]
-----------
Compiler for C++ supports arguments -Wno-vla-cxx-extension: NO
```
The issue is caused by how the cross compiler is set up by
.gitlab-ci/container/create-android-cross-file.sh
Allow the cross compiler to still start even when the
`-Werror,-Wunused-command-line-argument` error occurs in order to be
able to actually detect other arguments:
```
Command line: `/tmp/android-ndk-r27c/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android34-clang++ -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables --start-no-unused-arguments -static-libstdc++ --end-no-unused-arguments /home/ao2/Collabora/GOO0042/mesa/_build/meson-private/tmpm6eolxed/testfile.cpp -o /home/ao2/Collabora/GOO0042/mesa/_build/meson-private/tmpm6eolxed/output.obj -c -Wno-error=c99-designator -Wno-error=unused-variable -Wno-error=unused-but-set-variable -Wno-error=self-assign -D_FILE_OFFSET_BITS=64 -O0 -fpermissive -Werror=implicit-function-declaration -Werror=unknown-warning-option -Werror=unused-command-line-argument -Werror=ignored-optimization-argument -Wvla-cxx-extension -Wno-vla-cxx-extension` -> 0
Compiler for C++ supports arguments -Wno-vla-cxx-extension: YES
```
This makes argument detection work again, e.g:
```
Compiler for C++ supports arguments -Wno-array-bounds: YES (cached)
Compiler for C++ supports arguments -Wno-overflow: YES
Compiler for C++ supports arguments -Wno-c++11-narrowing: YES (cached)
Compiler for C++ supports arguments -Wno-vla-cxx-extension: YES (cached)
```
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12441
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Valentine Burley <valentine.burley@collabora.com>
Reviewed-by: Rob Clark <robclark@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33013>
The Xe uAPI is designed to use bind queues such that binds without input
dependencies (sync objects) do not block on binds with input
dependencies.
For example:
- Bind A (sparse) is submitted with a list of input dependencies.
- Bind B (immediate) is subsequently submitted without a list of input
dependencies.
If Bind A and Bind B share a single bind queue, Bind B will not be
scheduled until Bind A completes. Using individual bind queues decouples
Bind A and Bind B, allowing Bind B to make immediate progress.
This change creates a separate bind queue for each ANV queue, enabling
support for sparse bindings that may have input dependencies.
v2:
- Bail on bind queue creation failure (Linoel)
- Only create bind queue if VK_QUEUE_SPARSE_BINDING_BIT is set (Jose)
v3:
- Add comment around submit->queue usage (Jose)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32873>
It's split into ac_nir_lower_ps_early ac_nir_lower_ps_late.
ac_nir_lower_ps_early doesn't generate any AMD specific intrinsics except
some system values and is mainly an optimization pass with some lowering.
The new change here is that it also eliminates output components not needed
by spi_shader_col_format.
ac_nir_lower_ps_late lowers output stores to exports and does the bc_optimize
thing.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32966>
Add support for getting time elapsed values via glBeginQuery/glEndQuery.
When recording query start & end time, we ensure that all pending jobs have
been completed by using v3d cpu_queue & the multisync extension.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32547>
Add support for getting timestamp values via
glGet(GL_TIMESTAMP) and glQueryCounter(GL_TIMESTAMP). For the case of
glQueryCounter, we make use of v3d cpu jobs via
DRM_IOCTL_V3D_SUBMIT_CPU and DRM_V3D_EXT_ID_CPU_TIMESTAMP_QUERY.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32547>
The spec says
vkCmdCopyQueryPoolResults is considered to be a transfer operation,
and its writes to buffer memory must be synchronized using
VK_PIPELINE_STAGE_TRANSFER_BIT and VK_ACCESS_TRANSFER_WRITE_BIT before
using the results.
While STORE_MULTIPLE is not exactly VK_PIPELINE_STAGE_TRANSFER_BIT /
VK_ACCESS_TRANSFER_WRITE_BIT, we can still rely on user barriers to do
the right thing (e.g., flush caches for host access).
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32697>
On gfx12+, the pre-amble and post-amble flushes contain the stalls
necessary to ensure the prior operation is complete. Remove the extra
uses of ANV_PIPE_END_OF_PIPE_SYNC_BIT in post-amble flushes. Also do
this for the pre-amble flushes, but this doesn't have any impact. The
flush application function will implicitly add the bit.
For A750, this improves the TWWH3 trace in the performance CI by 0.52%
(n=2).
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31600>
Each reg may store a list of conflict regs. This was handled by
util_dynarray, however each of those hold an extra pointer for
the ra_regs (which serves as mem_ctx for that). Since the usage
here is very simple, we just handle the array growth manually.
The initial size remains the same as before.
The mem_ctx of each ra_reg was being used to identify the case
in which the list wasn't used. Change to use a bool in the
ra_regs struct instead.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25744>
Each node stores a list of adjacent nodes. This was handled by
util_dynarray, however each of those hold an extra pointer for
the ra_graph (which serves as mem_ctx for that). Since the usage
here is very simple, we just handle the array growth manually.
For now keep using the same initial size as was being used by dynarray.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25744>
Fast-clears require expensive flushes beforehand and afterwards. The
cost of flushes are decreased in a series of back-to-back fast-clears as
no extra fast-clear flushes are required in between them. If the ratio
of a command buffer's recorded back-to-back fast clears over independent
fast-clears falls below 1/2, prevent that command buffer from recording
any further fast-clears.
Averaging two runs of our Factorio trace on an A750 shows a +14.37%
improvement in FPS.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32984>
RBBM_PRIMCTR registers are used for different pipeline statistics that can
be queried, but current usage was wrong in some cases. Comments in the
register file are updated, and the per-statistic register index mapping is
updated accordingly.
Fixes on a750:
test_query_pipeline_statistics in vkd3d-proton
arb_query_buffer_object failures in piglit (zink)
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32900>
The `sad` instruction (used for iadd3) doesn't support the scalar ALU.
This means we might fall back to non-earlypreamble whenever we use it in
the preamble. Prevent this by emitting it as two adds instead.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32943>
If a polygon offset is set via glPolygonOffset, but the functionality
isn't enabled via glEnable(GL_POLYGON_OFFSET_FILL) the offset must not
be taken into account when computing the sample depth. As the Vivante
hardware does not have a separate enable state, the offset units and
scale must both be set to 0 to keep the sample depth unchanged.
Fixes dEQP-GLES2.functional.polygon_offset.default_enable
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32982>
Through the spec it's required that cl_kernel doesn't hold references to
its bound kernel arguments.
There is a CL CTS test verifying this, but because the arguments were not
used in the test kernel, a reference was never taken. This will change
with SVM and BDA as we need to know all bound memory objects even if they
aren't directly used in kernels.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32961>
Turnip already had a pipeline stat to indicate whether we were using
early-preamble or not. But no way to tell if there was a preamble at
all. Adding a preamble instruction count tells us whether there is a
preamble, but also how big it is.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32977>
This limits the address register to simple cases inside a block.
Validation ensures that the address register is only written once and
read once.
Instruction scheduling makes sure that instructions using the address
register in the generator are not scheduled while there is an usage of
the register in the IR.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28199>
force_gl_names_reuse is changed to integer.
-1 means default (currently disabled), 0 means disabled, 1 means enabled
The names reuse initialization is moved to _mesa_alloc_shared_state ->
_mesa_InitHashTable instead of _mesa_HashEnableNameReuse.
It will be enabled by default.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32715>
Rather than emitting FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD to do block
loads that were cacheline aligned, loading entire cachelines at a time,
we now rely on NIR passes to group, CSE, and vectorize things into
appropriately sized blocks. This means that we'll usually still load
a cacheline, but we may load only 32B if we don't actually need anything
from the full 64B. Prior to Xe2, this saves us registers, and it ought
to save us some bandwidth as well as the response length can be lowered.
The cacheline-aligning hack was the main reason not to simply call
fs_nir_emit_memory_access(), so now we do that instead, porting yet
one more thing to the common memory opcode framework.
We unfortunately still emit the old FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD
opcode for non-block intrinsics. We'd have to clean up 16-bit handling
among other things in order to eliminate this, but we should in the
future.
fossil-db results on Alchemist for this and the previous patch together:
Instrs: 161481888 -> 161297588 (-0.11%); split: -0.12%, +0.01%
Subgroup size: 8102976 -> 8103000 (+0.00%)
Send messages: 7895489 -> 7846178 (-0.62%); split: -0.67%, +0.05%
Cycle count: 16583127302 -> 16703162264 (+0.72%); split: -0.57%, +1.29%
Spill count: 72316 -> 67212 (-7.06%); split: -7.25%, +0.19%
Fill count: 134457 -> 125970 (-6.31%); split: -6.83%, +0.52%
Scratch Memory Size: 4093952 -> 3787776 (-7.48%); split: -7.53%, +0.05%
Max live registers: 33037765 -> 32947425 (-0.27%); split: -0.28%, +0.00%
Max dispatch width: 5780288 -> 5778536 (-0.03%); split: +0.17%, -0.20%
Non SSA regs after NIR: 177862542 -> 178816944 (+0.54%); split: -0.06%, +0.60%
In particular, several titles see incredible reductions in spill/fills:
Shadow of the Tomb Raider: -65.96% / -65.44%
Batman: Arkham City GOTY: -53.49% / -28.57%
Witcher 3: -16.33% / -14.29%
Total War: Warhammer III: -9.60% / -10.14%
Assassins Creed Odyssey: -6.50% / -9.92%
Red Dead Redemption 2: -6.77% / -8.88%
Far Cry: New Dawn: -7.97% / -4.53%
Improves performance in many games on Arc A750:
Cyberpunk 2077: 5.8%
Witcher 3: 4%
Shadow of the Tomb Raider: 3.3%
Assassins Creed: Valhalla: 3%
Spiderman Remastered: 2.75%
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32888>
The hope here is to replace our backend handling for loading whole
cachelines at a time from UBOs into NIR-based handling, which plays
nicely with the NIR load/store vectorizer.
Rounding down offsets to multiples of 64B allows us to globally CSE
UBO loads across basic blocks. This is really useful. However, blindly
rounding down the offset to a multiple of 64B can trigger anti-patterns
where...a single unaligned memory load could have hit all the necessary
data, but rounding it down split it into two loads.
By moving this to NIR, we gain more control of the interplay between
nir_opt_load_store_vectorize and this rebasing and CSE'ing. The backend
can then simply load between nir_def_{first,last}_component_read() and
trust that our NIR has the loads blockified appropriately.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32888>
The NIR vectorizer may produce block loads with unread trailing
components. Upcoming passes may produce unread leading components
as well. With a bit of finesse, we can skip loading those, and only
bother with the ones we actually need. This can sometimes save us on
loads and MOVs.
v2: Skip this for SLM reads on pre-LSC platforms (caught by Lionel).
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32888>
If we pass an immediate, just trivially return that immediate.
This preserves the property that if x was an IMM, emit_uniformize(x)
will also be an IMM, without the need for optimizations to eliminate
unnecessary operations. That way, you can call emit_uniformize() on
a value and still check whether it's constant afterwards.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32888>
We return an immediate for 32-bit constant values, but fall back to
calling get_nir_src() for other values, as 64-bit, and even 8-bit
immediates have odd restrictions. We could probably support 16-bit
here without too many issues, but we leave it be for now.
This makes it usable for case where we'd like to get constants for
32-bit values but where it may be a different bit-size too.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32888>
We were already skipping unread trailing components, but now we skip
them on both ends.
About -3.5% spills on Shadow of the Tomb Raider on Alchemist (mostly a
wash elsewhere, but it will help additional shaders with later patches).
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32888>
HDC doesn't support block loads/stores with sub-DWord (<4B) aligned
offsets, and shared local memory has to use the Aligned OWord Block
messages which require OWord (16B) alignment.
Make the validator detect this case and say no. Also make the lowering
code assert that the alignment is valid as a second line of defense.
LSC has no such restrictions.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32888>
This patch exposes shader hashes (computes and draws) to Perfetto and
utrace. By including these hashes in traces, developers can correlate
compute and draw calls with their assoicated ASM dumps when analyzing
the traces.
To achieve this, intel_tracepoint.py has been reworked to preprocess
tracepoint arguments dynamically. Any argument containing "hash" in its
variable name is now forrmated as hexadecimal before being passed to the
tracepoint definition.
Signed-off-by: Michael <michael.cheng@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32708>
Was causing trouble in some build configurations, we don't really need
them. Unless there's a good reason, defaults to use ralloc for
consistency with the larger codebase.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Antonio Ospite <None>
Reviewed-by: Kenneth Graunke <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32916>
This message has been confusing users, especially now that
popular toolkits such as Gtk started using a Vulkan renderer.
Printing a message on non-conformant implementations is also
actually not required. So let's remove it.
We haven't fully finished the GFX12 implementation yet, but on
all other hardware, RADV should work just fine, and is definitely
not meant for "testing use only".
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12314
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32930>
DONTBLOCK is sort of almost good enough except that the api frontend
can also use this and it can't use the full power of Trust Me Buddy™
that qbo maps require
this causes unnecessary ioctl syncs, which annihilates perf in games
that constantly check query results
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31823>
this allows a return without checking syncobj, avoiding overhead,
but when a query still isn't completing after multiple checks then
try checking the pool directly
this circumvents the usual qbo mechanism in specific cases (e.g., Everspace)
where an app fires off a million timestamp queries and the overhead of
checking a timeline semaphore kills perf
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31823>
If there is a 4-byte hole between 2 loads, they are vectorized. Example:
load 4 + hole 4 + load 8 -> load 16
This helps GLSL uniform loads, which are often sparse. See the code for more
info.
RADV could get better code by vectorizing later.
radeonsi+ACO - TOTALS FROM AFFECTED SHADERS (45482/58355)
Spilled SGPRs: 841 -> 747 (-11.18 %)
Code Size: 67552396 -> 65291092 (-3.35 %) bytes
Max Waves: 714439 -> 714520 (0.01 %)
This should have no effect on LLVM because ac_build_buffer_load scalarizes
SMEM, but it's improved for some reason:
radeonsi+LLVM - TOTALS FROM AFFECTED SHADERS (4673/58355)
Spilled SGPRs: 1450 -> 1282 (-11.59 %)
Spilled VGPRs: 106 -> 107 (0.94 %)
Scratch size: 101 -> 102 (0.99 %) dwords per thread
Code Size: 14994624 -> 14956316 (-0.26 %) bytes
Max Waves: 66679 -> 66735 (0.08 %)
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29399>
There is nothing preventing ACO from generating loads with unused
components. This happens often with GLSL uniforms. Some of those loads
are partially re-vectorized after this.
radeonsi+ACO:
TOTALS FROM AFFECTED SHADERS (19564/58918)
VGPRs: 732900 -> 728448 (-0.61 %)
Spilled SGPRs: 429 -> 433 (0.93 %)
Code Size: 38446004 -> 38485612 (0.10 %) bytes
Max Waves: 305440 -> 305549 (0.04 %)
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29399>
Walk the whole vertex stride thanks to XFB info sorted by offset, gather
individual components from same or different outputs, and once we have
gathered 4, store them as vec4.
It also removes the memory_modes field from VMEM stores because I don't
think it's needed.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32686>
Walk the whole vertex stride thanks to XFB info sorted by offset, gather
individual components from same or different outputs, and once we have
gathered 4, store them as vec4.
It also removes the COHERENT flag from VMEM stores because NGG streamout
doesn't use it either and I don't think it's needed.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32686>
The mesa crate should just provide the means of creating those, but the
logic of what to create shouldn't be there.
The passed in arguments also heavily vary, and this way we can be explicit
about what variants needs what inputs.
Reviewed-by: @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32903>
This allows us to use more contextual information of the image to create
the pipe_sampler_view properly instead of passing all the required
properties via function arguments.
Reviewed-by: @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32903>
This simplifies sampler view tracking a bit for us. Also, drivers will
automatically free the pipe_sampler_view as well.
It was wrong to call into sampler_view_destroy directly anyway, because
pipe_sampler_view is a refcounted object and pipe_sampler_view_reference
should be used instead.
Reviewed-by: @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32903>
I stumbled on this limit - it turns out that large local_sizes apply an
additonal limit on gprs per thread. If we violate this limit, then dmesg
just gives us a rather unhelpful message that the channel is killed:
nouveau 0000:01:00.0: gsp: rc engn:00000001 chid:64 type:13 scope:1 part:233
nouveau 0000:01:00.0: fifo:c00000:0008:0040:[hw_tests::test_[14761]] errored - disabling channel
Cc: mesa-stable
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32952>
Cast the value used in static assertion to be an unsigned integer,
instead of default signed integer.
This has been detected by Undefined Behaviour Sanitizer (UBSan).
```
../src/gallium/drivers/etnaviv/etnaviv_state.c:289:62: error: expression in static assertion is not constant
289 | static_assert((VIVS_PS_OUTPUT_REG2_SATURATE_RT4 << 24) == VIVS_PS_OUTPUT_REG2_SATURATE_RT7, "VIVS_PS_OUTPUT_REG2_SATURATE_RT7");
```
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30880>
This fixes VirglStagingMgr tests that tries to access a struct member of
a structure that is NULL.
This has been detected using Undefined Behaviour Sanitizer.
```
Running main() from ../src/gtest/src/gtest_main.cc
[==========] Running 9 tests from 2 test suites.
[----------] Global test environment set-up.
[----------] 7 tests from VirglStagingMgr
[ RUN ] VirglStagingMgr.non_fitting_allocation_reallocates_resource
stderr:
../src/gallium/drivers/virgl/tests/virgl_staging_mgr_test.cpp:72:22: runtime error: member access within null pointer of type 'struct virgl_hw_res'
```
Reviewed-by: Eric Engestrom <eric@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30880>
Detected when working on adding support for Undefined Behaviour
Sanitizer, this fixes:
```
../src/gallium/drivers/v3d/v3d_screen.c: In function 'v3d_get_compute_param.part.0':
../src/gallium/drivers/v3d/v3d_screen.c:480:17: error: null destination pointer [-Werror=format-overflow=]
480 | sprintf(ret, "v3d");
| ^~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
```
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30880>
Detected when working on adding support for Undefined Behaviour
Sanitizer, this fixes:
```
../src/gallium/drivers/radeonsi/radeon_vcn_dec.c: In function 'get_h264_msg':
../src/gallium/drivers/radeonsi/radeon_vcn_dec.c:239:50: error: 'k' may be used uninitialized [-Werror=maybe-uninitialized]
239 | && (k == ARRAY_SIZE(dec->h264_valid_poc_num))) {
| ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/gallium/drivers/radeonsi/radeon_vcn_dec.c:77:19: note: 'k' was declared here
77 | unsigned i, j, k;
| ^
cc1: all warnings being treated as errors
```
Reviewed-by: David Rosca <david.rosca@amd.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30880>
Detected when working on adding support for Undefined Behaviour
Sanitizer, this fixes:
```
../src/gallium/drivers/freedreno/a2xx/ir2_nir.c: In function 'load_const':
../src/gallium/drivers/freedreno/a2xx/ir2_nir.c:154:24: error: 'swiz' may be used uninitialized [-Werror=maybe-uninitialized]
154 | unsigned imm_ncomp, swiz, idx, i, j;
| ^~~~
../src/gallium/drivers/freedreno/a2xx/ir2_nir.c:195:30: error: 'imm_ncomp' may be used uninitialized [-Werror=maybe-uninitialized]
195 | so->immediates[idx].ncomp = imm_ncomp;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
../src/gallium/drivers/freedreno/a2xx/ir2_nir.c:154:13: note: 'imm_ncomp' was declared here
154 | unsigned imm_ncomp, swiz, idx, i, j;
| ^~~~~~~~~
cc1: all warnings being treated as errors
```
Reviewed-by: Rob Clark <robclark@freedesktop.org>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30880>
It could run the companion batch buffer even if the main batch buffer
failed, that was possible to happen in i915 and Xe KMD.
In case the main context/queue is banned and companion is not it could
still return that submission was properly start what was not.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32850>
Fix defect reported by Coverity Scan.
Side effect in assertion (ASSERT_SIDE_EFFECT)
assert_side_effect: Argument ++eot_count of assert() has a side effect.
The containing function might work differently in a non-debug build.
Fixes: ebd6738260 ("intel/elk/chv: Implement WaClearArfDependenciesBeforeEot")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32884>
Mesa3D is commonly used, as evidenced by the use of the Mesa3D.org domain.
Additionally, it is unnecessary to advise against using "MesaGL"
since we do not use it ourselves.
Cc: mesa-stable
Signed-off-by: David Heidelberg <david@ixit.cz>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32447>
This feature actually worked, but accidentally triggered some
CTS failures due do an unrelated sample_mask bug. That bug
is fixed in the previous commits in this series, so re-enable
fragmentStoresAndAtomics.
There are two spurious CI failures created by this change; one is in
a ycbcr test (which we're still working on) and the other is a CTS
bug (it's using a feature we don't advertise).
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32879>
this was missed in the original v3d pass, and then the common code port
inherited the bug. (so strictly this fix "should" be backported even farther
back but it won't apply before the Fixes here, and I don't think we do LTS that
far back anyway).
in theory this should fix a corner case with robustness on the gl (but not
vulkan, at least for apple) drivers on broadcom & apple.
Fixes: f0fb8d05e3 ("nir: Add nir_lower_robust_access pass")
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32907>
rather than try to enumerate everything a driver might want with an unmanageable
collection of booleans, just do a filter callback + data. this ends up simpler
overall, and will allow Intel to use this pass for just 64-bit images without
needing to add even more booleans.
while we're churning the pass signature, also do a quick port to
nir_shader_intrinsics_pass
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> [NIR and V3D]
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32907>
The loop checking if exec is overwritten didn't check for NULL
instructions, and didn't fix up reg write indices after inserting
instructions.
Fixes: fcd94a8c ("aco: move try_optimize_branching_sequence() to postRA optimizations")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32746>
We need to add a variant of the texld instruction, which is used with a shadow
samper and passed the shadow reference value via src2.
Blob generates such texld's for deqp's GLES3.functional.texture.shadow.2d.* (GC3000).
Fixes spec@arb_depth_texture@texdepth.
Fixes: abe5bd35 ("etnaviv: Switch to isa_assemble_instruction(..)")
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32926>
Marek recently changed hole_size to be signed, rather than unsigned.
A negative hole_size means that the two loads overlap - and thus are
prime candidates to be combined.
My original hole_size handling was:
if hole_size > 4 * (8 - low->num_components) then don't vectorize
For non-overlapping loads, this worked: NIR's largest vector is vec16,
and if low was already a vec16, combining it with anything would exceed
that, so it'd never be considered. That meant low would always be a
vec8 or less, so (8 - low->num_components) was a positive number.
Now that we see overlapping loads, we can see a vec16 low, vec4 high,
and also a negative hole size, giving us fun comparisons like:
-16 > 4 * (8 - 16) => -16 > -32 => true, don't vectorize
Which is absolutely the wrong thing to do, because the high load's data
is entirely included within the former load's data.
The idea here was to make sure the second load would be able to pack at
least one component into the first's V8 result. But even this isn't the
best, because...even if it's simply adjacent, doing one V16 load is more
efficient than requesting two back to back V8 loads.
So, we just simplify down to a static check: if there's an entire V8 of
hole, don't vectorize. This already won't happen because the core pass
has max_hole set to 28 bytes (7 32-bit components), but that could
change based on the needs of other drivers, so let's be defensive.
fossil-db results on Alchemist:
Instrs: 161533978 -> 161295137 (-0.15%); split: -0.20%, +0.05%
Subgroup size: 8092544 -> 8092568 (+0.00%)
Send messages: 7915233 -> 7844503 (-0.89%); split: -0.94%, +0.05%
Cycle count: 16577700697 -> 16702609256 (+0.75%); split: -0.59%, +1.35%
Spill count: 72338 -> 67226 (-7.07%); split: -7.36%, +0.29%
Fill count: 134058 -> 125980 (-6.03%); split: -6.83%, +0.80%
Scratch Memory Size: 4092928 -> 3786752 (-7.48%); split: -7.53%, +0.05%
Max live registers: 33031460 -> 32945994 (-0.26%); split: -0.27%, +0.01%
Max dispatch width: 5778384 -> 5778536 (+0.00%); split: +0.26%, -0.26%
Non SSA regs after NIR: 179809505 -> 152735471 (-15.06%); split: -15.08%, +0.03%
Fixes: c21bc65ba7 ("nir/opt_load_store_vectorize: make hole_size signed to indicate overlapping loads")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32932>
When a SEND instruction is a EOT, the scoreboard lowering will not
allocate a new SBID for it, since nothing needs to wait for it. In
Gfx12 this allowed the SEND to get out-of-order $.dst or $.src
dependencies.
Starting on Xe2+ this is not supported anymore, in favor of supporting
more combined modes.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32712>
Currently we scale the polygon offset units with a fixed factor,
matching the MRD (minimal resolvable distance) for a 16bpp depth
buffer. This wastes a lot of precision when a 24bpp depth buffer
is used.
Apply the correct MRD scale, depending on the format of the
currently bound depth buffer.
Fixes piglit spec@!opengl 1.4@gl-1.4-polygon-offset.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32756>
This is similar to what link_intrastage_shaders is doing and it
fixes the following test:
KHR-Single-GL46.subgroups.builtin_var.compute.subgroupsize_compute
Which was failing with SPIRV but passing with GLSL, the diff being:
- SPIRV: "subgroup_size: 1"
- GLSL: "subgroup_size: 2"
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32698>
The blitter VS expects coords to fit in a signed int16. When this
is not the case, use util_blitter_draw_rectangle instead.
Since util_blitter_draw_rectangle sets vertex elements, we need
to make sure they're properly restored.
The alternative to this fallback would be to pass coordinates
unpacked (so 4 SGPRs instead of 2), but this doesn't fix the
fbo-blit-check-limits test because of uv interpolation precision
issue.
Using 2 triangles instead of a rectangle + disabling
window_space_position helps but then this breaks some GLES3 tests,
like dEQP-GLES3.functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_x
(which doesn't pass either if u_blitter is used for all cases).
Using a single triangle covering the whole rectangles fixes all
cases but it then requires to setup scissors to not write too
much pixels...
So, instead of adding so much complexity, let's use u_blitter
for the "large coordinates" fallback, and keep the rectangle blit
for the other cases.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32698>
This is actually a false positive detected by static analyzer, because
it assumes that `device->instance->meta_cache_enabled` can change
between two execution points.
In order to instruct static analyzer this is not the case, we assing it
to a local variable, and do the checks based on that.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32819>
Declaring a variable-length array (VLA) based on a variable that can be
0 is declared dangerous.
In this case, the variable can't take value 0, so adding an assertion
fixes the issue.
This was detected by static analyzer.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32819>
We're about to add more sysvals, and the more we add, the bigger the
sysvals region gets, which increases the amount of memory we have to
allocate when push_uniforms are dirty.
Instead of allocating FAUs for all sysvals/push_constants, track FAU
usage per-shader, and pack those. This implies emitting an FAU buffer
per stage instead of trying to share it, but that's an acceptable
trade-off.
While at it, automate the sysval dirty tracking a bit.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32415>
Now that panvk_cmd_buffer.h is accessible from
src/panfrost/vulkan/panvk_vX_xxx.c files, there's no reason to pass
a gazillon arguments to blend_emit_descs(). We can just pass a cmdbuf
and let the helper extract the other parameters from there. It also
allows for extra automation, like dirtying the push_uniform buffer
when the new blend config reads the blend constant.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32415>
load_vertex_id_zero_base() is supposed to return the zero-based
vertex ID, which is then offset by load_first_vertex() to get
an absolute vertex ID. At the same time, when we're in a Vulkan
environment, load_first_vertex() also encodes the vertexOffset
passed to the indexed draw.
Midgard/Bifrost have a sligtly different semantics, where
load_first_vertex() returns vertexOffset + minVertexIdInIndexRange,
and load_vertex_id_zero_base() returns an ID that needs to be offset
by this vertexOffset + minVertexIdInIndexRange to get the absolute
vertex ID. Everything works fine as long as all the load_first_vertex()
and load_vertex_id_zero_base() calls are coming from the
load_vertex_id() lowering. But as mentioned above, that's no longer
the case in Vulkan, where gl_BaseVertexARB will be turned into
load_first_vertex() and expect a value of vertexOffset in an
indexed draw context.
We thus need to fix the mismatch by introducing two new
panfrost-specific intrinsic so we can stop abusing load_first_vertex()
and load_vertex_id_zero_base().
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32415>
The csel-ladder we have in bi_lower_load_push_const_with_dyn_offset()
is not great, and is relying on base/range being valid. It turns out
nir_lower_mem_access_bit_sizes(), which we rely on to make push constant
accesses 32-bit aligned, doesn't preserve those when splitting accesses.
Let's simplify the thing by lowering push constant accesses with a
dynamic offset to global loads.
We also reset the base and offset values in the lowering pass, to make
sure the backend doesn't rely on them for other things.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32415>
This is required to optimize FP64 and Int64 shaders generated by
virglrenderer. It generates pack/unpack around every 64-bit op,
which NIR currently can't eliminate. This fixes that.
There is a new constraint ".y", which means that the use of an instruction
should have swizzle.y. This allows us to add patterns that have Y swizzle
on results of instructions.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32172>
Currently marge will ignore an error message if it is just the word
"error" without any further information. However, if she never finds a
more informative message, then she will just print that meaningless
error message.
Instead of an empty error message, just leave the message blank.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32773>
If marge doesn't find deqp-runner results or trace errors, she will parse
a failed job log for error messages. The parsing ignores certain phrases
in an attempt to find more relevant errors.
Add a test to check marge's error log parsing to make sure that we don't
create regressions when adding new phrases to ignore.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32773>
Currently, if the pipeline_message script runs in an an env missing the
aiohttp package, the pipeline_message script will throw a
ModuleNotFoundError and crash marge.
Make sure to catch and ignore these errors since the pipeline message
should never interfere with a merge request.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32773>
The calibrate domain and the device domain period are determined in
vk_device_init. With them known, and with the vk_time_max_deviation
helper, GetCalibratedTimestampsKHR is straightforward.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32689>
VK_TIME_DOMAIN_DEVICE_KHR is always supported. Host time domains are
checked by vk_device_get_timestamp.
This is not used when the driver does not advertise
VK_{KHR,EXT}_calibrated_timestamps.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32689>
This change prevents the reuse of the bo when the counter is already
zero. At zero, the bo is in a state where the deletion is pending,
and this implementation relying on an atomic counter can't be safely
stopped. In other words, the previous fix ccd3bb4548 lower the
probability of this race condition, but doesn't fix it.
This change prevents a race condition which has a high probability
on r600 with the test below. This change was tested with the thread
sanitizer.
For instance, this issue is triggered on r600 with
"piglit/bin/ext_image_dma_buf_import-refcount-multithread -auto":
==9876==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d000021a20 at pc 0x7f2c9f59f748 bp 0x7f2c8f3aa600 sp 0x7f2c8f3aa5f8
READ of size 4 at 0x60d000021a20 thread T6
#0 0x7f2c9f59f747 in pipe_is_referenced ../src/gallium/auxiliary/util/u_inlines.h:65
#1 0x7f2c9f59f747 in radeon_bo_destroy ../src/gallium/winsys/radeon/drm/radeon_drm_bo.c:342
#2 0x7f2c9f63b541 in radeon_bo_reference ../src/gallium/include/winsys/radeon_winsys.h:794
#3 0x7f2c9f63b541 in r600_texture_destroy ../src/gallium/drivers/r600/r600_texture.c:571
#4 0x7f2c9d65662d in pipe_resource_destroy ../src/gallium/auxiliary/util/u_inlines.h:146
#5 0x7f2c9d65662d in pipe_resource_reference ../src/gallium/auxiliary/util/u_inlines.h:163
#6 0x7f2c9d65662d in st_FreeTextureImageBuffer ../src/mesa/state_tracker/st_cb_texture.c:459
#7 0x7f2c9d5b6991 in _mesa_delete_texture_image ../src/mesa/main/teximage.c:226
#8 0x7f2c9d5f2593 in _mesa_delete_texture_object ../src/mesa/main/texobj.c:532
#9 0x7f2c9d5f2be7 in _mesa_reference_texobj_ ../src/mesa/main/texobj.c:639
#10 0x7f2c9d5f3773 in _mesa_reference_texobj ../src/mesa/main/texobj.h:92
#11 0x7f2c9d5f3773 in delete_textures ../src/mesa/main/texobj.c:1578
0x60d000021a20 is located 0 bytes inside of 144-byte region [0x60d000021a20,0x60d000021ab0)
freed by thread T5 here:
#0 0x7f2ca8b2b4f7 in free (/usr/lib64/libasan.so.6+0xb14f7)
#1 0x7f2c9f59efb3 in radeon_bo_destroy ../src/gallium/winsys/radeon/drm/radeon_drm_bo.c:401
#2 0x7f2c9f63b541 in radeon_bo_reference ../src/gallium/include/winsys/radeon_winsys.h:794
#3 0x7f2c9f63b541 in r600_texture_destroy ../src/gallium/drivers/r600/r600_texture.c:571
#4 0x7f2c9d65662d in pipe_resource_destroy ../src/gallium/auxiliary/util/u_inlines.h:146
#5 0x7f2c9d65662d in pipe_resource_reference ../src/gallium/auxiliary/util/u_inlines.h:163
#6 0x7f2c9d65662d in st_FreeTextureImageBuffer ../src/mesa/state_tracker/st_cb_texture.c:459
#7 0x7f2c9d5b6991 in _mesa_delete_texture_image ../src/mesa/main/teximage.c:226
#8 0x7f2c9d5f2593 in _mesa_delete_texture_object ../src/mesa/main/texobj.c:532
#9 0x7f2c9d5f2be7 in _mesa_reference_texobj_ ../src/mesa/main/texobj.c:639
#10 0x7f2c9d5f3773 in _mesa_reference_texobj ../src/mesa/main/texobj.h:92
#11 0x7f2c9d5f3773 in delete_textures ../src/mesa/main/texobj.c:1578
previously allocated by thread T6 here:
#0 0x7f2ca8b2b9a7 in calloc (/usr/lib64/libasan.so.6+0xb19a7)
#1 0x7f2c9f5a36d5 in radeon_winsys_bo_from_handle ../src/gallium/winsys/radeon/drm/radeon_drm_bo.c:1198
#2 0x7f2c9f641b2a in r600_texture_from_handle ../src/gallium/drivers/r600/r600_texture.c:1105
#3 0x7f2c9d47550a in dri_create_image_from_winsys ../src/gallium/frontends/dri/dri2.c:1007
#4 0x7f2c9d47eeb9 in dri2_from_dma_bufs ../src/gallium/frontends/dri/dri2.c:1629
#5 0x7f2ca8854360 in dri2_create_image_dma_buf ../src/egl/drivers/dri2/egl_dri2.c:2564
#6 0x7f2ca8854f45 in dri2_create_image_khr ../src/egl/drivers/dri2/egl_dri2.c:2817
#7 0x7f2ca8846f2c in dri2_create_image ../src/egl/drivers/dri2/egl_dri2.c:1864
#8 0x7f2ca87f9dd8 in _eglCreateImageCommon ../src/egl/main/eglapi.c:1850
Fixes: ccd3bb4548 ("winsys/radeon: fix a race between bo import and destroy")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32896>
Enables use of async compute for shader format conversions.
Deinterlace filter still need gfx.
On my system with RX570 this fixes performance issues when using
gpu-screen-recorder to record gameplay at full GPU load. It can
now record with full framerate, compared to half framerate before.
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32794>
There were a couple of issues this fixes:
- Using the env "RUSTICL_DEVICE_TYPE" variable made no device be default.
- If multiple GPUs were detected, multiple devices were default.
- If zink was used, no default device was advertized either.
The spec requires that there must be one and only one default device.
Cc: mesa-stable
Reviewed-by @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32875>
It caused the Blender corruption, but the previous commit likely fixes it.
The workaround regressed performance for Furmark and Plot3D with 8xMSAA.
If you want to enable the workaround again in the future, just add this
line back: sscreen->info.gfx_level >= GFX11 ||
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32885>
This is based on the example given by the Vulkan specification: https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#textures-texel-anisotropic-filtering
The basic idea is to compute the axis in which the uv coordinates
change the fastest in screen space (rho_y and rho_y). If rho_x is larger
than rho_y, samples are summed up along the x-Axis and the y-Axis
viceversa. The x/y offsets are mapped back into texture (u/v) space
using a linear approximation of u(x,y) and v(x,y).
This approach does not use a nested loop and the number of samples is
basically limited to max_anisotropy (+/-). The sample count of the
previous approach could explode in some situations, leading to
frametimes >1s.
Reviewed-by: Aleksi Sapon <aleksi.sapon@autodesk.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31748>
Currently the list of buffer usage bits specified is hardcoded with
transform feedback bits, which leads to a validation layer error report
with ID VUID-VkBufferCreateInfo-None-09499 when EXT_transform_feedback
is not available.
Only set these bits when EXT_transform_feedback extension is really
available to suppress this error.
Cc: mesa-stable
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32386>
One new rv410 flake and one new rv530 fail which I can't reproduce
locally. Also remove the vs-varying-array-mat3* flakes, those were
failing because we run out of varyings, however this should no longer be
an issue since nir_opt_varyings was enabled for everyone.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32897>
The push_constant_loc[] array is always an identity mapping these days,
so it's kind of pointless. Just use the original uniform number and
skip the unnecessary "remap" step. With that gone, and shrinking UBO
ranges gone, assign_constant_locations() is now empty and can be removed
as well.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32841>
Back in the bad old days (vec4?) we had a bunch of smarts in the backend
to dead code eliminate unused vector components and re-pack regular
uniforms, so we really couldn't decide how much data we were pushing
until very late in the backend. Nowadays we have none of that - we do
all of our elimination and packing in NIR. anv shrinks ranges to deal
with Vulkan API push constants, and iris treats everything as a UBO and
as of the previous commit will also shrink appropriately.
So we don't need to do this anymore...which will let us simplify quite
a bit of code.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32841>
anv already does this limiting, since it needs to handle non-UBO push
constants as well. iris treats everything as a UBO, but doesn't have
a limiter and was relying on the backend to handle it.
Do this in the NIR pass so that we can eliminate the backend code.
It's not necessary for anv, but handling it here is simple and less
error prone for iris, which calls this in a number of places. We know
we need to limit things to this much; anv can limit more if needed.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32841>
The value of the PIPE_SHADER_CAP_MAX_CONST_BUFFERS parameter should be
less than PIPE_MAX_CONSTANT_BUFFERS, otherwise, it will lead to some
assert failures. For example:
void
cso_unbind_context(struct cso_context *cso)
{
...
int maxsam = scr->get_shader_param(scr, sh,
PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS);
int maxview = scr->get_shader_param(scr, sh,
PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS);
int maxssbo = scr->get_shader_param(scr, sh,
PIPE_SHADER_CAP_MAX_SHADER_BUFFERS);
int maxcb = scr->get_shader_param(scr, sh,
PIPE_SHADER_CAP_MAX_CONST_BUFFERS);
int maximg = scr->get_shader_param(scr, sh,
PIPE_SHADER_CAP_MAX_SHADER_IMAGES);
assert(maxsam <= PIPE_MAX_SAMPLERS);
assert(maxview <= PIPE_MAX_SHADER_SAMPLER_VIEWS);
assert(maxssbo <= PIPE_MAX_SHADER_BUFFERS);
assert(maxcb <= PIPE_MAX_CONSTANT_BUFFERS); // Crash here
assert(maximg <= PIPE_MAX_SHADER_IMAGES);
...
}
Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32889>
Now that ACO has become the default on pre-RDNA GPUs, all pre-merge CI
coverage of radeonsi+LLVM has disapeared. Let's fix this by making
our post-merge glcts-vangogh-valve job run inpre-merge pipelines.
However, we are limited in vangogh capacity, so rather than running the
full glcts/piglit test suites we run a fraction of it to stay under 15
minutes of execution time on a single Steam Deck.
Suggested-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32865>
It's not entirely clear to me why this has moved from Crash/Fail to
Pass, the only thing I can see in the commit history between the last
nightly pass and failure is an optimization of unpacing 8-bit values
from a 64-bit value. It's a bit suspicious that an optimization makes
somethign pass...
But we need to have correct CI expectations, otherwise we won't notice
new failures. So let's update to the new reality, and debug this if the
problem reappears in the future.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32833>
Looks like this changed when IO-lowering was changed in the GLSL
linker, but because the traces job here runs post-merge, it wasn't
noticed at the time.
There's only a single pixel that has changed, from a very dark color to
another very dark color. Neigher the before nor after images looks
obviously more correct than the other.
Fixes: 73d675451b ("ci: update fail lists and trace checksums")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32833>
In OpenGL, non-multisample targets always have full coverage, and shader
writes to gl_SampleMask are ignored. On Vulkan, sample mask writes on
single-sample targets are treated the same way as writes with >1 sample.
Fixes dEQP-VK.pipeline.*.multisample_shader_builtin.write_sample_mask.1_samples
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32636>
Fix defect reported by Coverity Scan.
Arguments in wrong order (SWAPPED_ARGUMENTS)
swapped_arguments: The positions of arguments in the call to
hk_ia_update do not match the ordering of the parameters:stat_c_inv is
passed to c_prims.stat_c_prims is passed to c_inv.
Fixes: a3b796ba19 ("libagx,hk: handle pipeline stats queries without a GS")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32853>
The Vulkan spec says:
"The application can enable a logical operation between the
fragment’s color values and the existing value in the framebuffer
attachment. This logical operation is applied prior to updating
the framebuffer attachment. Logical operations are applied only
for signed and unsigned integer and normalized integer
framebuffers. Logical operations are not applied to floating-point
or sRGB format color attachments."
Missing VKCTS coverage has been reported.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12345
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32826>
When linking FS and VS with mismatched interpolation qualifiers, we need
to read the FS qualifiers and pass them to the VS. I put
nir_collect_noperspective_varyings in a separate function instead of
merging it into the existing walk_varyings loop because it will later be
used on uncompiled shaders that don't have a pan_shader_info yet.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32127>
Mali only supports perspective-correct varying interpolation in
hardware, so we have to emulate noperspective with lowering in both the
VS and FS.
Both vulkan and opengl allow mismatched interpolation qualifiers between
stages. Because we need all varyings that are noperspective in the FS to
be lowered in the VS, we cannot rely on the interpolation qualifiers in
the VS. Loading the set of noperspective varyings as a sysval allows the
implementation to pass them as a compile-time constant when known
statically, or a runtime push constant when not. Passing noperspective
varyings dynamically has a performance cost with unnecessary branches
and fmuls.
This sysval is not hooked up yet in either panfrost or panvk, so shader
compilation will fail.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32127>
Video decode target needs custom height alignment, but tex descriptor
still needs to be set to the original size the image was created with.
This makes the descriptor wrong for layer > 0, so we need to calculate
the layer offset and add it to bo address for this case.
Fixes: 5deb476095 ("radv: align video images internal width/height inside the driver.")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32069>
Coverity notices that `err` might be used uninitialized, which is true
as we don't assign the value we want to check! Fix that assignment so
the EXPECT_EQ macro does what we expect.
CID: 1635272
Fixes: 6b931a68c7 ("intel/common: Implement Xe KMD in mi_builder tests")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32849>
When we moved building the docs to Meson, we accidentally dropped the -W
flag that we used to have. This lead to us no longer detecting certain
problems in the docs, which is unfortunate.
Let's bring this back gated by the werror meson-option, and wire that up
on the CI end.
Fixes: fdd204538b ("ci: build docs using meson")
Reviewed-by: Dylan Baker <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32831>
We need an empty line after ".. code-block: [...]", otherwise the first
lines are interpreted as arguments, not content. This makes the entire
code-blocks not render at all.
Fixes: 5d6d67a4d1 ("docs/android: improve documentation about building llvmpipe for Android")
Reviewed-by: Dylan Baker <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32831>
Also add a note in .gitlab-ci/container/debian/x86_64_test-android.sh
that DEBIAN_TEST_ANDROID_TAG needs to be updated when that file changes
too.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
For future reference add some disabled rules to for running tests using
llvmpipe on Android, and for that to work also add
deqp-android-llvmpipe.toml
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Cuttlefish performs some checks on the host system before launching,
setting VK_DRIVER_FILES to the path of the host artifacts makes sure
that a vulkan library can be found on the host side.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Set XDG_CACHE_HOME when invoking deqp-runner so that mesa can create the
shader cache and avoid this error:
-----------------------------------------------------------------------
ERROR - dEQP error: Failed to create //.cache for shader cache (Read-only file system)---disabling.
-----------------------------------------------------------------------
And also pass --shader-cache-dir to deqp-runner for vulkan tests.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Also copy mesa vulkan libraries to the Android guest, this makes it
possible to test venus with the latest upstream mesa build.
While at it also keep the *_angle libraries as they will be used by the
venus_guest_angle GPU_MODE.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Prefer libraries from /cuttlefish when loading binaries, in particular
this solves some loading problem when launching
/cuttlefish/bin/virgl_render_server
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
The /etc/init.d/cuttlefish-host-resources wnants to perform some
operations that are not really desirable on a gitlab shared runner, like
loading specific kernel modules.
Since the script does not seem to be strictly necessary for basic
operation of cuttlefish, don't call it at all, avoiding the kernel
modules problem.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Commit 4143199be7 (ci/android: Use common $RESULTS_DIR for cuttlefish,
2024-08-21) clarified the separation between the result dir used on the
host and shipped in the artifacts, and the result dir used in the
Android guest to collect test results, however the latter was not
correctly passed to deqp-runner.
Fix that so that deqp-runner can finally run.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Fix warning when using chown:
-----------------------------------------------------------------------
+ chown root.kvm /dev/kvm
chown: warning: '.' should be ':': 'root.kvm'
-----------------------------------------------------------------------
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Use a custom kernel when launching cuttlefish, this is needed for
-gpu_mode=venus.
And while at it also clean up the state from previous runs, this seems
to be required when passing a custom kernel.
In this change also pass -enable_bootanimation=false which makes
drm_virgl work, and pass -enable_minimal_mode=true to avoid using some
features which are not really needed.
Note that the file number limit has to be increased too in
.gitlab-ci/cuttlefish-runner.sh for cuttlefish to work properly.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Clarify that artifacts from the Android guest are downloaded explicitly
and put them under /mesa-android directory so that they don't clash with
the Linux host artifacts downloaded by gitlab under
"${CI_PROJECT_DIR}/install".
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Different Android images may contain different graphic libraries, for
example images from Google using an old mesa version may have
libGLES_mesa.so, while newer Android images built with mesa from
upstream have libGLESv1_CM_mesa.so, etc.
Use `rm -f` instead of just `rm` to avoid running into errors when
a file does not exist, resulting in a failing job.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
To test mesa on cuttlefish some special images tailored for upstream
mesa are needed, in particular these images may set properties or add
functionality that enable new use cases for upstream mesa on Android,
like for instance using venus via the vulkan.virtio mesa driver.
So instead of downloading the standard images from Google, get those
custom images from s3.freedesktop.org.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
The ./tools/buildutils/build_packages.sh script used by the
android-cuttlefish project built in debian/x86_64_test-android.sh uses
sudo, so install that as an EPHEMERAL dependency.
Also set SUDO_FORCE_REMOVE=yes when removing sudo to avoid some errors.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Save some logs and stop cuttlefish more cleanly when
.gitlab-ci/cuttlefish-runner.sh exits prematurely because of some
errors.
This makes it possible to have the logs available as artifacts even if
the script didn't run to completion.
This approach also leaves the system in a cleaner state and makes it
possible to relaunch the script and have launch_cvd work even if it had
been run in the past both with or without errors.
This is especially useful for local experiments.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
After copying the newly built mesa libraries to the Android vendor
partition the services have to be restarted to make sure that the new
libraries are used, in particular by Surfaceflinger, so call 'stop'
and 'start' for that.
Also print the GLES implementation used by Surfaceflinger before and
after restarting, to be able to compare and check that the new libraries
are effectively picked up.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
For the current tests the DRI drivers do not seem to be needed on
Android, so remove the ANDROID_DRIVER variable and stop copying the DRI
libraries to the guest file system, only copy libgallium_dri.so which is
really needed.
While at it, also copy libGLESv1_CM.so and libGLESv2.so
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
In order to build the mesa llvmpipe driver for Android, llvm libraries
for Android are needed; force meson to use a fallback for llvm and
provide prebuilt libraries making them available to meson thanks to
a wrap file.
Enable other software drivers for the x86_64-linux-android build, but
also disable the amd and intel hardware drivers for now which don't
build correctly on Android.
Download the prebuilt LLVM libraries for Android in the container job
rather than in the build job, to avoid downloading some big artifacts
for every mesa version built for Android.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
In commit ad42be50c9 (ci/deqp: fully isolate deqp builds, 2024-03-17)
the deqp module version file was changed from something like
`/deqp/version-$deqp_api` to something like `/deqp-$deqp_api/version`
and this seems to cause some issues when building for Android:
-----------------------------------------------------------------------
[439/1301] Building CXX object external/amber/src/src/vulkan/CMakeFiles/libamberenginevulkan.dir/blas.cc.o
FAILED: external/amber/src/src/vulkan/CMakeFiles/libamberenginevulkan.dir/blas.cc.o
/tmp/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ --target=x86_64-none-linux-android28 --sysroot=/tmp/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/sysroot -DAMBER_CTS_VULKAN_HEADER=1 -DAMBER_ENABLE_CLSPV=0 -DAMBER_ENABLE_DXC=0 -DAMBER_ENABLE_LODEPNG=1 -DAMBER_ENABLE_RTTI=1 -DAMBER_ENABLE_SHADERC=0 -DAMBER_ENABLE_SPIRV_TOOLS=0 -DAMBER_ENGINE_DAWN=0 -DAMBER_ENGINE_VULKAN=1 -DDE_ANDROID_API=28 -DDE_ASSERT_FAILURE_CALLBACK -DDE_COMPILER=DE_COMPILER_CLANG -DDE_CPU=DE_CPU_X86_64 -DDE_FENV_ACCESS_ON="_Pragma(\"STDC FENV_ACCESS ON\")" -DDE_MINGW=0 -DDE_OS=DE_OS_ANDROID -DDE_PTR_SIZE=8 -I/tmp/VK-GL-CTS/external/amber/../vulkancts/framework/vulkan/generated/vulkan -I/tmp/VK-GL-CTS/framework/delibs/debase -I/tmp/VK-GL-CTS/framework/delibs/decpp -I/tmp/VK-GL-CTS/framework/delibs/depool -I/tmp/VK-GL-CTS/framework/delibs/dethread -I/tmp/VK-GL-CTS/framework/delibs/deutil -I/tmp/VK-GL-CTS/framework/delibs/destream -I/tmp/VK-GL-CTS/execserver -I/tmp/VK-GL-CTS/external/spirv-headers/src/include -I/tmp/VK-GL-CTS/external/amber/src/include -I/tmp/VK-GL-CTS/external/amber/src -I/tmp/deqp-vk -I/tmp/deqp-vk/external/vulkancts/framework/vulkan/generated/vulkan -Wall -Wextra -Wno-long-long -Wshadow -Wundef -Wconversion -Wno-sign-conversion -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -frtti -fexceptions -fwrapv -fvisibility=hidden -fvisibility-inlines-hidden -O3 -DNDEBUG -std=gnu++17 -fPIC -w -fno-exceptions -fvisibility=hidden -Wall -Wextra -Wno-cast-function-type-strict -Wno-padded -Wno-switch-enum -Wno-unknown-pragmas -Wno-unsafe-buffer-usage -pedantic-errors -Werror -Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-format-pedantic -Wno-unknown-warning-option -Weverything -Wno-zero-as-null-pointer-constant -MD -MT external/amber/src/src/vulkan/CMakeFiles/libamberenginevulkan.dir/blas.cc.o -MF external/amber/src/src/vulkan/CMakeFiles/libamberenginevulkan.dir/blas.cc.o.d -o external/amber/src/src/vulkan/CMakeFiles/libamberenginevulkan.dir/blas.cc.o -c /tmp/VK-GL-CTS/external/amber/src/src/vulkan/blas.cc
In file included from /tmp/VK-GL-CTS/external/amber/src/src/vulkan/blas.cc:16:
In file included from /tmp/VK-GL-CTS/external/amber/src/src/vulkan/blas.h:19:
In file included from /tmp/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/vector:274:
In file included from /tmp/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/__bit_reference:14:
In file included from /tmp/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/bit:57:
In file included from /tmp/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/limits:105:
In file included from /tmp/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/type_traits:417:
In file included from /tmp/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/cstddef:37:
/tmp/deqp-vk/version:1:1: error: unknown type name 'dEQP'
dEQP base version vulkan-cts-1.3.10.0
^
-----------------------------------------------------------------------
This seems to be caused by `cstddef` from the Android NDK which includes
a file named `version`, i.e.:
-----------------------------------------------------------------------
#include <version>
-----------------------------------------------------------------------
To avoid the problem also add the deqp module name to the file name,
like: `/deqp-$deqp_api/deqp-$deqp_api-version`.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Collect the mustpass lists also for the Android target, in particular
this makes vk-main.txt to be found again when running vulkan tests on
Android.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
The main branch of dEQP build fine for android but the GL and GLES
branches fail with errors like the following:
-----------------------------------------------------------------------
.../external/openglcts/modules/common/glcFramebufferBlitTests.cpp:715:26: error: no member named 'floor' in namespace 'std'
return (GLubyte)std::floor(f == 1.0f ? 255 : f * 255.0);
~~~~~^
.../external/openglcts/modules/common/glcFramebufferBlitTests.cpp:1491:14: error: no member named 'fabs' in namespace 'std'
if (std::fabs(actual - expected) > eps)
~~~~~^
2 errors generated.
-----------------------------------------------------------------------
Cherry-pick a couple of commit from main that fix the errors.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
When adding patches wit git-am create the date format for
GIT_COMMITTER_DATE in a locale-agnostic format, this avoids potential
issues when running the scripts locally with a non-English locale, e.g.:
-----------------------------------------------------------------------
++ GIT_COMMITTER_DATE='gio 1 gen 1970, 01:00:00, CET'
++ git am
fatal: invalid date format: gio 1 gen 1970, 01:00:00, CET
-----------------------------------------------------------------------
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
This message is printed on non-panfrost/panthor systems on every
physical device enumeration when panvk is present like in distribution
mesa builds.
This "breaks" gtk-4 tests in the default configuration since they fail
on warning log messages. gtk-4 still forwards the vulkan debug report as
warning messages after fixes for issue 11451 to stop handling it as
critical message.
Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Fixes: d970fe2e9d ("panfrost: Add a Vulkan driver for Midgard/Bifrost GPUs")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11451
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32822>
If an instruction didn't already use SDWA convert_to_SDWA in apply_extract
will add ubyte0/uword0 selections for v1b/v2b operands. This loses information
that the instruction doesn't care about the high bits and makes the next
apply_extract_twice fail.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Fixes: 6cb9d39bc2 ("aco: combine extracts with sub-dword definitions")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32803>
Move the sym_config setting all together and ensure that we set either
a value or empty, since Meson complains about missing values.
Fixes the build warning
```
Configuring dri.sym using configuration
../src/gallium/targets/dri/meson.build:28: WARNING: The variable(s) 'va_driver_init',
'vdp_imp_device_create_x11' in the input file 'src/gallium/targets/dri/dri.sym.in' are
not present in the given configuration data.
```
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32808>
Due to the slow startup time of deqp-vk, the previous default of
500 tests per group caused the jobs to run up to twice as slowly
compared to using a higher number of tests per group.
Increase the number of tests per group in the deqp-runner suite
to bring job durations within a reasonable range.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32729>
Due to the slow startup time of deqp-vk, the previous default of
500 tests per group caused the jobs to run up to twice as slowly
compared to using a higher number of tests per group.
Increase the number of tests per group for both subsets of the
deqp-runner suite, which allows decreasing the fraction.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32729>
Due to the slow startup time of deqp-vk, the previous default of
500 tests per group caused the jobs to run up to twice as slowly
compared to using a higher number of tests per group.
Increase the number of tests per group in the deqp-runner suite,
which allows decreasing the fraction and lowering the timeout.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32725>
The goal of the commit is to fix a dead assignment detected by static
analyzer: value stored to `linear_ok` is never read.
But instead of just removing the dead assignment, we just remove the
full variable, and instead search for the linear modifier in the place
that is required.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32772>
The goal of the commit is to fix a dead assignment detected by static
analyzer: value stored to `linear_ok` is never read.
But instead of just removing the dead assignment, we just remove the
full variable, and instead search for the linear modifier in the place
that is required.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32772>
Static analyzer is complaining that value stored to `v3d` during its
initialization is never read.
But the variable is used just below in a loop, so it is not clear if
this is just a false positive.
In any case, having this intermediate variable provides nothing,
specially when it is used only in a single place. So rather remove it
and use the full variable.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32772>
In nested control flow this is nessecary to not demote/terminate invocations
that are part of the global but not part of the local mask.
At the top level, the masks are the same and no additional invocations
can be accidentally disabled.
Foz-DB Navi21:
Totals from 2095 (2.64% of 79395) affected shaders:
Instrs: 1058326 -> 1056839 (-0.14%)
CodeSize: 5632480 -> 5626616 (-0.10%)
Latency: 12082761 -> 12080520 (-0.02%); split: -0.02%, +0.00%
InvThroughput: 2246677 -> 2246636 (-0.00%); split: -0.00%, +0.00%
Copies: 114446 -> 114433 (-0.01%)
SALU: 230585 -> 229098 (-0.64%)
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32755>
This change caused the regression:
@@ -853,7 +853,7 @@ bool si_llvm_compile_shader(struct si_screen *sscreen, struct ac_llvm_compiler *
/* Reset the shader context. */
ctx.shader = shader;
- ctx.stage = sel->stage;
+ ctx.stage = nir->info.stage;
bool same_thread_count = shader->key.ge.opt.same_patch_vertices;
si_build_wrapper_function(&ctx, parts, same_thread_count);
because "nir" contains the previous shader (LS), not the current shader (HS).
Fix it by using prev_nir for the previous shader, so that we can keep using
"nir".
Fixes: 9b7ea720c9 - radeonsi: use nir->info instead of sel->info.base
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32780>
The lowering code does not generate efficient code. It is better to
just not emit the bad thing in the first place. The shaders that I
examined had blocks of NIR like:
con 32 %527 = extract_u8 %456.o, %5 (0x0)
con 32 %528 = extract_u8 %456.o, %35 (0x1)
con 32 %529 = extract_u8 %456.o, %14 (0x2)
con 32 %530 = extract_u8 %456.o, %11 (0x3)
con 32 %531 = u2f32 %527
con 32 %532 = u2f32 %528
con 32 %533 = u2f32 %529
con 32 %534 = u2f32 %530
In some cases the u2f results are multiplied with 1/255. There may be
a slightly more efficient way to do this by doing something like
mov(8) g40<1>UW g12.1<32,8,4>UB
mov(8) g41<1>UW g12.2<32,8,4>UB
mov(8) g42<1>UW g12.3<32,8,4>UB
mov(8) g60<1>F g12<32,8,4>UB
mov(8) g61<1>F g40<1,1,0>UW
mov(8) g62<1>F g41<1,1,0>UW
mov(8) g63<1>F g42<1,1,0>UW
In SIMD16 and SIMD32 that would save temporary register space. It could
save a register in SIMD8 by using g40.8 instead of g42. Making that
happen might be tricky. Maybe we should just add a special NIR opcode
that converts a packed uint32 to a vec4?
v2: Add a bunch of documentation explaining what's going on. Suggested
by Ken.
shader-db:
Lunar Lake, Meteor Lake, and DG2 had similar results. (Lunar Lake shown)
total instructions in shared programs: 18228689 -> 18228720 (<.01%)
instructions in affected programs: 43091 -> 43122 (0.07%)
helped: 0 / HURT: 30
total cycles in shared programs: 932542994 -> 932544290 (<.01%)
cycles in affected programs: 8150758 -> 8152054 (0.02%)
helped: 15 / HURT: 17
fossil-db:
Lunar Lake, Meteor Lake, and DG2 had similar results. (Lunar Lake shown)
Totals:
Instrs: 142890605 -> 142890392 (-0.00%); split: -0.00%, +0.00%
Cycle count: 21655049536 -> 21654693720 (-0.00%); split: -0.00%, +0.00%
Totals from 181 (0.03% of 553251) affected shaders:
Instrs: 188022 -> 187809 (-0.11%); split: -0.12%, +0.01%
Cycle count: 85291658 -> 84935842 (-0.42%); split: -0.47%, +0.05%
Tiger Lake, Ice Lake, and Skylake had similar results. (Tiger Lake shown)
Totals:
Instrs: 154438050 -> 154436980 (-0.00%)
Cycle count: 15334650326 -> 15334644375 (-0.00%); split: -0.00%, +0.00%
Spill count: 56754 -> 56706 (-0.08%)
Fill count: 95919 -> 95808 (-0.12%)
Scratch Memory Size: 2306048 -> 2304000 (-0.09%)
Max live registers: 32469924 -> 32469899 (-0.00%)
Totals from 112 (0.02% of 642922) affected shaders:
Instrs: 156186 -> 155116 (-0.69%)
Cycle count: 11111478 -> 11105527 (-0.05%); split: -0.62%, +0.56%
Spill count: 1766 -> 1718 (-2.72%)
Fill count: 2815 -> 2704 (-3.94%)
Scratch Memory Size: 78848 -> 76800 (-2.60%)
Max live registers: 11526 -> 11501 (-0.22%)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29884>
Between 5 and 10 shaders (depending on the platform) from Blender are
massively helped for spills and fills (e.g., from 45 spills to 0, and
180 fills to 0).
Previously this commit cause a lot of spill and fill damage to
Wolfenstein Youngblood and Red Dead Redemption 2. I believe due to
!32041 and !32097, this is no longer the case. RDR2 is helped, and
Wolfenstein Youngblood has no changes.
However, q2rtx/q2rtx-rt-pipeline is hurt:
Spill count: 126 -> 175 (+38.89%); split: -0.79%, +39.68%
Fill count: 156 -> 235 (+50.64%); split: -1.92%, +52.56%
By the end of this series this damage is fixed, and q2rtx is helped
overall by -0.79% spills and -1.92% fills.
v2: Fix for Xe2.
v3: Just keep using bld for the group(1, 0) call. Suggested by Ken.
v4: Major re-write. Pass bld and xbld to fs_emit_memory_access. The big
fix is changing the way srcs[MEMORY_LOGICAL_ADDRESS] is calculated
(around line 7180). In previous versions of the commit, the address
would be calculated using bld (which is now xbld) even if the address
source was not is_scalar. This could cause the emit_uniformize (later in
the function) to fetch garbage. This also drops the special case
handling of constant offset. Constant propagation and algebraic will
handle this.
v5: Fix a subtle bug that was ultimately caused by the removal of
offset_to_component. The MEMORY_LOGICAL_ADDRESS for
load_shared_uniform_block_intel was being calculated as SIMD16 on LNL,
but the later emit_uniformize would treat it as SIMD32. This caused GPU
hangs in Assassin's Creed Valhalla.
v6: Fix a bug in D16 to D16U32 expansion. Noticed by Ken. Add a comment
explaining bld vs xbld vs ubld in fs_nir_emit_memory_access. Suggested
by Ken.
v7: Revert some of the v6 changes related to D16 to D16U32
expansion. This code was mostly correct. xbld is correct because DATA0
needs to be generated in size of the eventual SEND instruction. Using
offset(nir_src, xbld, c) will cause offset() to correctly added
component(..., 0) if nir_src.is_scalar but xbld is not scalar_group().
v8: nir_intrinsic_load_shared_uniform_block_intel was removed. This
caused reproducible hangs in Assassin's Creed: Valhalla. There are some
other compiler issues related to this game, and we're not yet sure
exactly what the cause of any of it is.
shader-db:
Lunar Lake
total instructions in shared programs: 18058270 -> 18068886 (0.06%)
instructions in affected programs: 5196846 -> 5207462 (0.20%)
helped: 4442 / HURT: 11416
total cycles in shared programs: 921324492 -> 919819398 (-0.16%)
cycles in affected programs: 733274162 -> 731769068 (-0.21%)
helped: 11312 / HURT: 31788
total spills in shared programs: 3633 -> 3585 (-1.32%)
spills in affected programs: 48 -> 0
helped: 5 / HURT: 0
total fills in shared programs: 2277 -> 2198 (-3.47%)
fills in affected programs: 79 -> 0
helped: 5 / HURT: 0
LOST: 123
GAINED: 377
Meteor Lake, DG2, and Tiger Lake had similar results. (Meteor Lake shown)
total instructions in shared programs: 19703458 -> 19699173 (-0.02%)
instructions in affected programs: 5885251 -> 5880966 (-0.07%)
helped: 4545 / HURT: 14971
total cycles in shared programs: 903497253 -> 902054570 (-0.16%)
cycles in affected programs: 691762248 -> 690319565 (-0.21%)
helped: 16412 / HURT: 28080
total spills in shared programs: 4894 -> 4646 (-5.07%)
spills in affected programs: 248 -> 0
helped: 7 / HURT: 0
total fills in shared programs: 6638 -> 5581 (-15.92%)
fills in affected programs: 1057 -> 0
helped: 7 / HURT: 0
LOST: 427
GAINED: 978
Ice Lake and Skylake had similar results. (Ice Lake shonw)
total instructions in shared programs: 20384200 -> 20384889 (<.01%)
instructions in affected programs: 5295084 -> 5295773 (0.01%)
helped: 5309 / HURT: 12564
total cycles in shared programs: 873002832 -> 872515246 (-0.06%)
cycles in affected programs: 463413458 -> 462925872 (-0.11%)
helped: 16079 / HURT: 13339
total spills in shared programs: 4552 -> 4373 (-3.93%)
spills in affected programs: 546 -> 367 (-32.78%)
helped: 11 / HURT: 0
total fills in shared programs: 5298 -> 4657 (-12.10%)
fills in affected programs: 1798 -> 1157 (-35.65%)
helped: 10 / HURT: 0
LOST: 380
GAINED: 925
fossil-db:
All Intel platforms had similar results. (Lunar Lake shown)
Totals:
Instrs: 141528822 -> 141728392 (+0.14%); split: -0.21%, +0.35%
Subgroup size: 10968048 -> 10968144 (+0.00%)
Send messages: 6567930 -> 6567909 (-0.00%)
Cycle count: 22165780202 -> 21624534624 (-2.44%); split: -3.09%, +0.65%
Spill count: 69890 -> 66665 (-4.61%); split: -5.06%, +0.44%
Fill count: 128331 -> 120189 (-6.34%); split: -7.44%, +1.09%
Scratch Memory Size: 5829632 -> 5664768 (-2.83%); split: -2.86%, +0.04%
Max live registers: 47928290 -> 47611371 (-0.66%); split: -0.71%, +0.05%
Totals from 364369 (66.18% of 550563) affected shaders:
Instrs: 113448842 -> 113648412 (+0.18%); split: -0.26%, +0.44%
Subgroup size: 7694080 -> 7694176 (+0.00%)
Send messages: 5308287 -> 5308266 (-0.00%)
Cycle count: 21885237842 -> 21343992264 (-2.47%); split: -3.13%, +0.65%
Spill count: 65152 -> 61927 (-4.95%); split: -5.42%, +0.47%
Fill count: 122811 -> 114669 (-6.63%); split: -7.77%, +1.14%
Scratch Memory Size: 5438464 -> 5273600 (-3.03%); split: -3.07%, +0.04%
Max live registers: 34355310 -> 34038391 (-0.92%); split: -1.00%, +0.07%
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29884>
No shader-db changes on any Intel platform.
fossil-db:
Lunar Lake, Meteor Lake, and DG2 had similar results. (Lunar Lake shown)
Totals:
Instrs: 141808595 -> 141808815 (+0.00%); split: -0.00%, +0.00%
Cycle count: 22181300418 -> 22185066952 (+0.02%); split: -0.01%, +0.03%
Max live registers: 48052077 -> 48052083 (+0.00%)
Totals from 720 (0.13% of 551446) affected shaders:
Instrs: 116778 -> 116998 (+0.19%); split: -0.01%, +0.20%
Cycle count: 1197931082 -> 1201697616 (+0.31%); split: -0.21%, +0.53%
Max live registers: 56552 -> 56558 (+0.01%)
No fossil-db changes on any other Intel platform.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29884>
No shader-db changes on any Intel platform.
v2: Fix for Xe2.
v3: Rework the way that we determine that an intrinsic can actually be
convergent. This will now depend on whether or not the important
sources have previously be determined to be convergent. Fixes
intermitent failures in some test cases (including
dEQP-VK.spirv_assembly.instruction.graphics.16bit_storage.push_constant_float_16_to_32.scalar_frag).
v4: s/the it/it/ in a comment. Noticed by Ken.
fossil-db:
No fossil-db changes on Lunar Lake.
Meteor Lake and DG2 had similar results. (Meteor Lake shown)
Totals:
Instrs: 152743449 -> 152743161 (-0.00%)
Cycle count: 17399179660 -> 17399193488 (+0.00%)
Totals from 144 (0.02% of 633314) affected shaders:
Instrs: 5936 -> 5648 (-4.85%)
Cycle count: 51616 -> 65444 (+26.79%)
Tiger Lake, Ice Lake, and Skylake had similar results. (Tiger Lake shown)
Totals:
Instrs: 150646195 -> 150645907 (-0.00%)
Cycle count: 15618427818 -> 15618428942 (+0.00%)
Totals from 144 (0.02% of 632567) affected shaders:
Instrs: 6218 -> 5930 (-4.63%)
Cycle count: 39968 -> 41092 (+2.81%)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29884>
This commit used to be "brw/emit: Allow scalar sources to 64-bit
3-source instructions". These instructions were fixed up in
brw_eu_emit. There seems to be some conflict with the <0,1,0> stride an
post-RA scheduling. The only difference between the passing code
generated by this commit and the failing code generated by the older
commit is some post-RA scheduling.
v2: Change the stride of a MAD even if the instruction isn't
lowered. MAD instructions that are already SIMD8 have to follow the same
rules. 🤦
v3: Pull the lowering out to its own pass. Update the comment in
brw_fs_validate. Suggested by Ken.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29884>
Sources that are scalars (almost all source) and convergent generally
want <0,1,0> source stride. Sources that are vectors (e.g., texture
coordinates, SSBO write data, etc.) and convergent want no extra strides
applied. In nearly all cases LOAD_PAYLOAD lowering will do the right
thing.
v2: Use VEC in emit_pixel_interpolater_send. Suggested by Ken.
v3: With the elimination of offset_to_component(), offset() may not
convert an is_scalar source to have a zero stride. Explicitly do this
in get_nir_src and prepare_alu_destination_and_sources.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29884>
In SIMD16 and SIMD32, storing convergent values in full 16- or
32-channel registers is wasteful. It wastes register space, and in most
cases on SIMD32, it wastes instructions. Our register allocator is not
clever enough to handle scalar allocations. It's fundamental unit of
allocation is SIMD8. Start treating convergent values as SIMD8.
Add a tracking bit in brw_reg to specify that a register represents a
convergent, scalar value. This has two implications:
1. All channels of the SIMD8 register must contain the same value. In
general, this means that writes to the register must be
force_writemask_all and exec_size = 8;
2. Reads of this register can (and should) use <0,1,0> stride. SIMD8
instructions that have restrictions on source stride can us <8,8,1>.
Values that are vectors (e.g., results of load_uniform or texture
operations) will be stored as multiple SIMD8 hardware registers.
v2: brw_fs_opt_copy_propagation_defs fix from Ken. Fix for Xe2.
v3: Eliminte offset_to_scalar(). Remove mention of vec4 backend in
brw_reg.h. Both suggested by Caio. The offset_to_scalar() change
necessitates some trickery in the fs_builder offset() function, but I
think this is an improvement overall. There is also some rework in
find_value_for_offset to account for the possibility that is_scalar
sources in LOAD_PAYLOAD might be <8;8,1> or <0;1,0>.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29884>
We only set buf_filled_size for the first target, but draws from non-zero
streams use buf_filled_size from other targets, so share the same
buf_filled_size buffer among all streamout targets because it contains
all 4 offsets.
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32713>
alpha-to-coverage must be applied before alpha-to-one. The only way to do
that is to export alpha for alpha-to-coverage via mrtz, and export 1 via
mrt0.a.
ACO and monolithic shader support is already in place thanks to RADV,
so we only need to change the LLVM PS epilog and the shader key.
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32713>
This adds kill_z and kill_stencil flags to the shader PS epilog key, which
removes those outputs if depth or stencil are disabled.
It must be implemented in:
* ACO PS epilog
* LLVM PS epilog
* ac_nir_lower_ps for monolithic shaders
Some of the samplemask code wasn't completely correct, but probably harmless.
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32713>
This will take effect after nir_opt_varyings is enabled by another MR, and
will fix existing shader compiler crashes thanks to better optimizations.
For example, one GLSL program that failed to compile and had 226 VS
instructions and 356 FS instructions in NIR will be reduced to 2 or 3
instructions per shader.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31942>
Regression on test:
dEQP-GLES31.functional.geometry_shading.basic.output_256
voffset is missing if buffer store base >=4096, we need to
re-calculate offen after resolve_excess_vmem_const_offset().
Fixes: cdaf269924 ("aco: inline store_vmem_mubuf/emit_single_mubuf_store")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32767>
CI tests are carried out in debian/x86_64_pyutils container which is using
python version 3.11 so use this version also for local testing.
This makes local testing more accurate. For example repeated double
quotes in f-formatted strings will raise an error in python 3.11 but not
in python 3.12.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32602>
Since run-pytest.sh uses the debian/x86_64_pyutils container, it's not
necessary to add an additional layer of isolation by creating a virtual
environment for run-pytest.sh.
So stop creating a venv when run-pytest is run in a container, but keep
the option of using a venv to run-pytest.sh locally.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32602>
Currently the update_traces_checksum script prints a label verification
request with a line that is 167 characters long.
Split the long line to make it more readable. Update the flake8
configuration to enforce a maximum line length of 159 characters to ensure
consistency.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32602>
Currently the ci scripts and tests don't have any linting checks. Add
.flake8 linting to start adding some consistency to the scripts. Ignore
most of the existing errors until they can be addressed on an individual
basis.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32602>
Currently, run-pytest.sh won't run locally outside of a pipeline
because it can't find the `setup-test-env.sh` which provides necessary
functions.
Add a default value for the SCRIPTS_DIR so that run-pytest can find and
run the setup-test-env.sh and be run locally outside of a pipeline.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32602>
Without this the game crashes during the loading screen.
The game uses vkUpdateDescriptorSetWithTemplate and, in certain cases,
passes VkDescriptorBufferInfo structures where the offset + range
exceeds the size of the buffer. This triggers an assertion when
vk_buffer_range() is called, causing the game to crash.
When the nvidia vendor id is used the range is consistently set to 65536.
Without it the range varies and is much smaller - never exceeding 1000.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12349
Cc: stable
Reviewed-by: Faith Ekstrand <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32764>
This can happen in decode context when application send no slice
buffers or in processing context with no processing buffers.
We need to avoid calling driver end_frame as no begin_frame will be
called in this case.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32677>
It's not valid to call RenderPicture and EndPicture without calling
BeginPicture or when BeginPicture fails. FFmpeg will however call
EndPicture when BeginPicture fails, so we need to handle this.
Use target_id, which is assigned in BeginPicture, as an indication
whether we are inside the Begin - End picture sequence.
Cc: mesa-stable
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32677>
the previous logic was busted with the sequence Dolphin emits:
BeginRender
BindIndex
Draw
EndRender
BeginRender
Draw without restart
Draw with restart
EndRender
the second control stream would not have any restart index emitted, since the
dirty flag is set only on Begin and Bind, and cleared on draw.
this was probably also broken in the similar case
BeginRender
BindIndex
Draw without restart
Draw with restart
EndRender
fixes Zelda: Wind Waker, Xeno Blade, etc.
thank you to pokechu22 for debug help!
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32759>
We were inconsistent over the usage of PAN_BIND_DEPTH_STENCIL, putting
it on some stencil only formats but not others. Apply it to all
stencil formats. However, we also need to change is_format_supported
to ignore S8_UINT (at least for GLES), because the hardware is a little
weird with that format and the gallium driver gets confused by it.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32462>
This is not supported by VCN.
We indicate this limitation by not reporting YUV420_12 RT format
supported for VP9, and not reporting YUV422 and YUV444 for AV1.
Most applications however simply ignore this, and will pick some other
format that is supported, which obviously won't work.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32663>
Draws were validated against an XFB primitive type from the last
glBeginTransformFeedback call, ignoring glResumeTransformFeedback that
may have been after it that may have resumed for a different primitive
type.
The spec doesn't state this explicitly, but it's logical.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32685>
The HW can do it, however if the state tracker sees support for ATI2N,
it will assume we also don't need a fallback for ATI1N. So if something
actually tries to use ATI1N format later, we will crash.
This could be fixed at the st level, but I honestly don't think the added
complexity is worth it, especially as this is highly r300 specific and
only affects single generation. So just disable it.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32639>
The running container jobs scripts S3_JWT_FILE needs to be removed on
exit because the resulting image is committed and we don't want the auth
token to leak permanently in the fs.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31093>
In order to build the mesa llvmpipe driver for Android, LLVM libraries
for Android are needed, but building them each time a new upstream mesa
is built would be too much overhead.
So add a script to build LLVM libraries for Android and call it from the
debian/android_build job. The actual build will be performed only when
necessary and the resulting artifact will be uploaded to the S3 bucket
to be re-used when building mesa for Android.
The build process follows what has been documented in
docs/drivers/llvmpipe.rst
Reviewed-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31093>
Unset the compiler env vars in debian/android_build.sh used to
cross-build libelf for Android, to prevents those env vars to
inadvertently affect subsequent commands that might want to build for
the native host after the cross-builds.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31093>
Set up "${S3_JWT_FILE}" also for container jobs, this can be useful in
case some jobs want to save something to S3.
Note that for container jobs setting the file /s3_swt in the
`default:before_script` section would not work: this wold be "too early"
because, when using ci-templates, the cbuild invocation switches the
root filesystem before executing FDO_DISTRIBUTION_EXEC, resulting in the
file becoming unavailable after the switch.
So set up the file exactly in FDO_DISTRIBUTION_EXEC, before launching
the actual container script.
Do this using a new trampoline script
.gitlab-ci/container/container_job_trampoline.sh so that in the future
other tasks common to all container jobs can be added there.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31093>
When the gantt chart service was first implemented, the read_token()
function would attempt to read from the default token file if the token
argument was missing.
Now it's necessary to call a separate function to look in the default
token file, so if the token argument is not provided, expressly call
get_token_from_default_dir().
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32637>
The gantt charts have a vertical line indicating the time when marge-bot
stops waiting for CI to finish. Currently the ci-timeout is hard-coded at
60 minutes. But marge-bot's timeout is configurable, so allow this value
to be configured as well.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32637>
If a job is still running when the gantt chart is generated, the job's
phases won't be represented as a bar on the chart.
To show these jobs on the gantt chart, introduce a new phase "In-Progress"
to capture the current status of these jobs. Rename the "Running" phase
as "Time spent running" to emphasize that the running phase is complete.
This provides a more complete picture of the pipeline jobs when CI times
out.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32637>
The gantt chart script currently expect the pipeline url to be the last
line of marge-bot's comment on a failed pipeline. The pipeline summary
hook now adds additional information that was preventing the gantt chart
script from finding the pipeline url.
Change the regex for finding the pipeline url to account for pipeline
summary comments.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32637>
Add a pipeline-id to the gantt filename so that the filename is unique.
Reduce the additional info provided in the gantt comments since the tool
is now more familiar to developers.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32637>
Currently the gantt chart script will post a comment to any project that
uses the default marge bot user id. Although the gantt chart is flexible
enough to work for any project, restrict it to mesa/mesa by default. Add
the --project-id option to add a custom project or list of projects to
analyze.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32637>
The gantt chart currently hard-codes the marge user id, but since the
script can be used for any marge-bot user, add an option to specify the
marge-bot user id. If no option is specified, the default marge-bot user
id is still used.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32637>
The SIMD splitting pass does not handle wide force_writemask_all
instructions correctly at the moment. For example, a SIMD32 TXF
on pre-Xe2 would get split to a pair of SIMD16. But it will set
the groups to operate on channels 15:0 and 31:16. That's not what
we want for a NoMask instruction - both should be 15:0, i.e.
bld.group(inst->exec_size, 0).
We could (and perhaps should) fix the SIMD splitting pass to handle
this, but the pass already has subtle complexity in which builders
are used. Or we could alter fs_builder::group(), but that has broader
implications. As a stop-gap, just make opt_combine_covergent_txfs stop
relying on SIMD splitting. It's trivial to do and fixes the issue
without risking other breakage.
Fixes: 6341b3cd87 ("brw: Combine convergent texture buffer fetches into fewer loads")
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32714>
The Wayland protocol defines INVALID as a special marker indicating
that implicit modifiers are supported. If the driver doesn't support
explicit modifiers and the compositor advertises support for implicit
modifiers, fallback to these.
This effectively restores logic removed in 4c06515892, but only
for the specific case of Wayland instead of affecting all APIs.
(Wayland is one of the few APIs defining a special meaning for
INVALID.)
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: 4c06515892 ("dri: revert INVALID modifier special-casing")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32535>
If we supply modifiers to dri_create_image_with_modifiers() and
the driver doesn't support them, the function will fail. We pass
__DRI_IMAGE_USE_LINEAR anyways so stripping the modifier is fine.
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: 4c06515892 ("dri: revert INVALID modifier special-casing")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32535>
If we supply modifiers to dri_create_image_with_modifiers() and
the driver doesn't support them, the function will fail. The X11
server always supports implicit modifiers so we can always fall
back to that.
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: 4c06515892 ("dri: revert INVALID modifier special-casing")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32535>
When updating an AFBC-packed resource, the size of the resulting
texture data can change while the BO and modifier stay the same. We
still need to update the texture descriptor in that situation so
that the size is properly reported. Having a smaller size than the
real one might cause artifacts as the GPU doesn't want to read past
the reported size.
A future (more foolproof) fix might involve having a hash key to
track the size of all slices independently, but this patch still
improves the situation and make sure we don't hit a relatively
common issue when using `PAN_MESA_DEBUG=forcepack`.
Fixes: bc55d150a9 ("panfrost: Add support for AFBC packing")
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32598>
Unigine Heaven crash on GFX8/9 when use aco:
heaven_x64: ../../amd/mesa/src/gallium/drivers/radeonsi/si_nir_lower_abi.c:813: lower_tex: Assertion `samp_index >= 0 && comp_index >= 0' failed.
GFX8/9 will clamp texture comparison value in si_nir_lower_abi,
but it has to be done after si_nir_lower_resource.
Fixes: ae933169 ("radeonsi: lower NIR resource srcs to descriptors last")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32694>
While we're here, refactor the logic to split out the mutable and
pre-mutable cases since they are now very different.
The special case for NV12 is now necessary to avoid test failures, but
it was always necessary and we didn't notice it before because tests
didn't specify a format list.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32615>
Right now the image layout depends on the format for the R8G8 special
case, but this is clearly wrong if we set the mutable bit because it
could be reinterpreted. Refactor how it's set to make it part of the
layout struct, rather than specified in the view.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32615>
We can get into a situation where the layer size for a given mip isn't
large enough to hold the pitch times the aligned height, i.e. the height
isn't aligned. This can happen even if the size is 4K aligned. The
hardware seems not to align the height for us, so we have to use the
MINLAYERSZ hammer.
This was found with a Vulkan test when enabling tiling for mutable
textures on a750, but it's also reproducable via
"bin/texelFetch fs sampler3D 76x76" using piglit.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32615>
Due to the slow startup time of deqp-vk, the previous default of
500 tests per group caused the jobs to run up to twice as slowly
compared to using a higher number of tests per group.
Increase the number of tests per group in the deqp-runner suite,
which allows decreasing the fraction.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32704>
A next patch will emit more instructions in video and copy queues
for Gfx 200 and newer but the current code only creates anv_async_submit
if device has aux_map.
Instead we can always create anv_async_submit and only submit it to
hardware if any instruction was emited.
Fixes: 86813c60a4 ("mi-builder: add read/write memory fencing support on Gfx20+")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32680>
This effectively reverts a70b197741 ("turnip: Force linear mode for
non-ubwc R8G8 formats"), except that in the meantime we added HIC
support without supporting R8G8 so we still have to force linear tiling
in that case. The previous commit is a better fix.
Tiled uncompressed images will be used for sparse residency support,
it's not valid to arbitarily not support sparse texturing on R8G8,
the blob does use a tiled uncompressed image in that case, and we will
have to also.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32619>
Stop relying on the submit BO list, which won't exist with the new
"VM_BIND" uAPI. Instead, create a separate list in generic code, only
when dumping is enabled. As a bonus this means that it should work on
virtio and kgsl too, and more code is removed from the kernel backend.
We need to use the generic fence wait introduced in the previous commit.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32165>
Contrary to what the comment said, kgsl and drm actually have very
similar semantics for fences. Add a common function to wait on a fence,
and embed the queue + fence directly instead of a syncobj abstraction
that doesn't actually gain us much. This common fence wait function will
also be helpful for making more code generic.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32165>
Each driver implemented the Vulkan runtime submit callback itself, which
resulted in a lot of duplicated code to iterate through the command
buffers and gather the list of IBs to execute, deal with autotune and
command buffers with suspending/resuming dynamic renderpasses, etc. This
has been getting steadliy worse and was only going to get worse with
sparse, since to implement sparse bind submissions we have to similarly
traverse and flatten an array of bind structures.
Borrow an idea from nvk, and add an abstraction of a "submit" object
which holds a (dynamically growing) list of pending commands to submit.
We add kernel-specific functions to create a submit, add commands to it,
and finally submit it. For sparse, we will add additional an additional
function that adds a sparse bind and then we will parse the Vulkan
structures in common code. For now, we move various misc.
driver-independent parts of the submission path into a common
tu_queue_submit() that calls into the new abstractions.
In the future, if we need to add driver-internal syncobjs to the
user-provided ones, we could use the same approach with waits and
signals. For now we provide them as part of the submit function.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32165>
Because most pool-allocations happens during rendering, we have the same
issue as in the previous commit; we don't have a good way to report
the out-of-memory error here. So we do one of two things; we either
return a NULL-ish pointer, or we print an error and ignore the call.
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32428>
When allocations fail, we can end up with NULL-batches. This means we
can't really do much, so let's bail what we're trying to do here.
Unfortunately, we can't always report this up to the call-site easily,
because some pipe_context functions don't allows us to return a
pipe_error value. So in those cases, make let's just return log an error
and return as if nothing happened. It's not great, but there's nothing
super obvious to do here.
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32428>
There's more than one error-path out of cs_alloc_ins_block(), but only
one of them got the discar_instr_slot treatment. Instead of plugging
this in one more time, let's move this handling up to cs_alloc_ins(),
where we can easily whack two birds with one stone. This makes us
consistently return NULL on error here.
At the same time, we need to patch up cs_flush_block_instrs() here,
because we don't actually set the buffer invalid here. So let's
check for NULL here instead, which is the new contract.
Fixes: 0e6aaab00a ("pan/cs: add block to handle registers backup in exception handler")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Tested-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32428>
Cross-invocation TCS input access doesn't prevent same-invocation access.
This improves shaders that use both for the same inputs.
Also, if some components of a vec4 slot only use same-invocation access and
other components only use cross-invocation access (it's possible after
compaction), this takes the VGPR path for the components with
same-invocation access, which didn't happen previously because all masks
only describe whole vec4s.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31673>
Both can be used. Cross-invocation access can read it from LDS, while
same-invocation access can read it from VGPRs.
The entrypoints of the passes don't allow that flexibility yet,
but the logic inside the pass allows it.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31673>
We're parsing the descriptors here to read the size of the resource, but
what the HW wants and imageSize() wants is not the same. So let's fix up
the result for imageSize(), by dividing the result by 6.
If we change the descriptor instead, we end up failing shader-image
reads and writes instead.
I also looked for some unused bits in the descriptor that I could use
instead, but unfortunately there's only a few bits free here - not
enough for our needs.
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32612>
Previous code was assuming that load_sample_id loaded the hardware
sample ID register, which is 32 when sample shading is disabled. The
expectation was that we would read (0.5,0.5) from sample_positions[32].
Because the top 3 bits of the sample ID register are masked out in
bi_load_sample_id_to, we were instead reading the position of the first
sample.
This doesn't affect OpenGL, because opengl never uses
nir_load_sample_pos when sample shading is disabled.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Fixes: 60146cc57c ("panvk: implement sampleRateShading")
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32601>
The CI_JOB_TIMEOUT variable is the GitLab-defined job timeout in
seconds.
Use this variable in LAVA instead of the separate JOB_TIMEOUT,
which was intended to represent the test phase timeout (job timeout
minus 5 minutes), but was often overlooked.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32609>
At the moment, we're not initializing the base_{instance,vertex} sysvals
which we'll need to do if we want to support shader draw parameters. It
turns out even without shader draw parameters enabled, some shaders need
a valid base_instance value, so this alone should fix a few tests.
On CSF hardware, we have a way to pass a non-zero base instance that's
propagated to the instance ID, but this messes with instance divisors,
so instead of using the native base instance feature, we force it to
zero, pass the base instance through an FAU sysval, and let
panvk_lower_load_vs_input() do the lowering for vertex attribute loads.
Reviewed-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/32039>
load_attribute_pan is a panfrost-specific intrinsic for loading
vertex attributes. Takes explicit vertex and instance IDs which
we need in order to implement vertex attribute divisor with
non-zero base instance on v9+.
Passes which are used by panvk are modified to be aware of
load_attribute_pan.
Reviewed-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/32039>
Due to the slow startup time of deqp-vk, the previous default of
500 tests per group caused the jobs to run up to twice as slowly
compared to using a higher number of tests per group.
Increase the number of tests per group for all subsets of the
deqp-runner suites, which allows decreasing the fractions.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32681>
Due to the slow startup time of deqp-vk, the previous default of
500 tests per group caused the jobs to run up to twice as slowly
compared to using a higher number of tests per group.
Increase the number of tests per group for all subsets of the
deqp-runner suites, which allows decreasing the fractions.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32681>
Due to the slow startup time of deqp-vk, the previous default of
500 tests per group caused the jobs to run up to twice as slowly
compared to using a higher number of tests per group.
Increase the number of tests per group for all subsets of the
deqp-runner suites, which allows decreasing the fractions.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32681>
Flush and process trace events on queue submit when tracing is enabled
and timestamp_frequency is valid. Tracing can be enabled with, for
example, MESA_GPU_TRACES=print.
panvk_utrace_flush_data is allocated on queue submit and is freed after
all trace events associated with the queue submit are processed. It is
used for synchronize gpu timestamp writes and trace event processing.
It also specifies the subqueue the trace events belong to.
For the moment, cmdbufs without
VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT are silently ignored.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32360>
There is one u_trace per subqueue to record trace events. When tracing
is enabled, trace_begin_cmdbuf and trace_end_cmdbuf will emit trace
events to u_trace and emit timestamp writes to the command streams.
The trace events are buffered in u_trace and are not flushed for
processing yet.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32360>
Improve the documentation about building the llvmpipe driver for Android
by providing more ready-to-use scripts to build llvm and create the
needed meson wrap file.
Note: in the meson wrap file, remove 'libLLVMTableGenGlobalISel' from
the built dependencies, as apparently is not available anymore for
Android on recent LLVM versions.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32251>
The build of libgallium has been simplified for Android where the
versioned library is not used since it's not really needed.
Update the documentation and the proposed Android.bp files to only refer
to libgallium_dri.so
While at it also fix the proposed SELinux rules to use the correct path
for libglapi which is not under /vendor/lib(64)?/egl/
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32251>
Last VGT stages (VS, TES or GS) can always be used with a null FS when
nextStage is non-zero. Like if a VS is created with nextStage=TCS, it's
also allowed to draw without binding a CTS (ie. nextStage=None is always
a valid case).
Because we don't want to compile two variants for NONE and FRAGMENT,
let's compile only the FRAGMENT one when necessary.
Fixes new CTS coverage, see https://gerrit.khronos.org/c/vk-gl-cts/+/15976.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32665>
Modified the BVH dumping mechanism to synchronously wait for the command
buffer to complete before saving BVH data to files. This approach is
more robust compared to the previous method of dumping during
acceleration strucutre destruction.
Note: if DEBUG_BVH_ANY is enabled but intel-rt is disabled, we will wait
for nothing.
Signed-off-by: Kevin Chuang <kaiwenjon23@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32585>
Supporting Vulkan 1.1 was premature, as we don't support subgroup
operations, which are actually required (even if it's not listed in
section "46.1. Feature Requirements"):
Here's the relevant phrasing from the Vulkan 1.1 spec:
> subgroupSupportedOperations will have the VK_SUBGROUP_FEATURE_BASIC_BIT
> bit set if any of the physical device’s queues support
> VK_QUEUE_GRAPHICS_BIT or VK_QUEUE_COMPUTE_BIT.
So, it seems we have to support at least the basic feature set before we
can expose Vulkan 1.1. So let's back out of that for now.
Fixes: a6e03ce428 ("panvk: advertise version 1.1 support")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32654>
We are conditionally updating the push-sets, so we need to also
conditionally clear the dirty-flags here instead of clearing them
wholesale. Otherwise, we end up not updating the descriptors that are
used in subsequent draws, but not in the first one.
Fixes: 79e5146378 ("panvk: Sanitize the driver-internal dirty state tracking")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32630>
\[WHY\]
The reason for making these changes is to address the defects identified
by the Coverity scan. By fixing these defects, we can ensure that any
future defects generated by our own code changes can be easily
identified and resolved.
\[HOW\]
To implement the changes/fixes, the following steps were taken:
1. CHECKED_RETURN: All cases were aligned to check the return value.
2. DC.WEAK_CRYPTO: The use of rand() to generate random numbers was
replaced with a more secure method using platofrm API.
3. DEADCODE: Useless code that always returned true was removed.
4. DIVIDE_BY_ZERO: A check was added to ensure that the divisor is not
zero before performing division.
5. HFA: An unused header was removed.
6. MISSING_BREAK: A break statement was added in switch cases where it
was missing.
7. PASS_BY_VALUE: Parameters that were being passed by value and were
too big were changed to pass by reference.
\[TESTING\]
What testings have been done (test IDs and json file):
Reviewed-by: Tomson Chang <Tomson.Chang@amd.com>
Signed-off-by: Min-Hsuan You <Min-Hsuan.You@amd.com>
Acked-by: Chenyu Chen <Chen-Yu.Chen@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32646>
\[WHY\]
System event logs are different than string logging. They are meant to
generate light weight events with ID and variable args and can be
coalesced with events generated by other IP components.
\[HOW\]
Add a callback function, which is implemented by the client (Like PAL)
VPELIB adds defines for a list of possible event IDs
The client is expected to handle the callback
And translate and emit the event through
native system infrastructure like ETW logging.
\[TESTING\]
Tested on system that triggers sys event, and viewed the event through
ETW viewer
Signed-off-by : Anthony Koo <anthony.koo@amd.com>
Reviewed-by: Roy Chan <Roy.Chan@amd.com>
Acked-by: Chenyu Chen <Chen-Yu.Chen@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32646>
ACO is still not perfect:
* It generates s_wait_loadcnt 0x0-0x3 when the only required wait instruction
is s_wait_loadcnt 0x5.
* It generates a lot of unnecessary jumps and blocks for uniform loop breaks.
Only scc1 jumps are necessary to break the loop. This is 10x better than
LLVM, but even ACO might consider using nir_intrinsic_ordered_add_loop_gfx12_amd
for the best performance.
How to print the streamout asm on any GPU:
PIGLIT_PLATFORM=gbm AMD_FORCE_FAMILY=gfx12_16pipe AMD_DEBUG=vs,mono,asm,useaco ../piglit/bin/shader-io-rate vs_out_xfb
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32570>
With the introduction of the slab allocator, most of our small
allocations now hit that rather than directly hitting the bucket
cache. Those now show up as 2MB slab allocations from the cache's
perspective. So, we don't need quite as many buckets. (Note that
only allocations in IRIS_MEMZONE_OTHER are suballocated today.)
Previously, we had 55 buckets, going from 4KB to 112MB, with sizes
N, N+1/4, N+1/2, N+3/4 for a series of power-of-two N's.
This patch prunes it down to 25 buckets:
- 4K-4MB => power-of-two sizes only
- 6MB => a one-off bucket to reduce waste between 4MB and 8MB
- 8MB+ => the usual N, N+1/4, N+1/2, N+3/4 system
- 64MB => the largest bucket size
In particular, this eliminates the 1.75MB, 2.5MB, 3MB, 3.5MB, and 7MB
buckets in favor of multiples of 2MB. Allocating multiples of 2MB is
preferable because it allows the kernel to allocate 64KB pages rather
than being stuck using inefficient 4K pages. And, the amount of waste
from bumping to the next multiple of 2MB isn't huge in that range of
sizes. We also eliminate buckets larger than 64MB because they're
rarely used, and also the amount of waste from rounding up to the
80/96/112MB buckets can get pretty large.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Fixes: 0b6693a3a1 ("iris: Align fresh BO allocations to 2MB in size")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10219
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32635>
Currently the python-test job runs pytest and then creates python
related artifacts for use by other jobs. But the python-test job isn't
triggered by changes to the python scripts and libraries. Instead, changes
to python scripts and libraries can currently be merged without running
pytest and, if they do generate errors, they will only appear in ci
later when trying to generate the python artifacts.
Add pytest to the existing linting jobs and expand the rules so that it
will be triggered by changes to python scripts and libraries. Remove
pytest from the job that creates artifacts. This will ensure that the
artifacts are still valid while catching script/library errors before they
are merged.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32340>
Currently the yaml-toml-shell-test extends the python-test job to make
use of the python packages available there. But the python-test also
generates artifacts which yaml-toml-shell-test does not need to do.
Instead of extending the python-test job, avoid extra work by just using
the pyutils container directly.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32340>
The current python-test job creates and compresses python related
artifacts for use by future jobs. The artifacts are currently named
`mesa-python-test` which is somewhat misleading because they are not
needed for testing python scripts or libraries.
Rename the artifacts generated by the python-test job to be more
descriptive of their purpose.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32340>
The debian/x86_64_pyutils job incorporates references to rules from the
python-test and .container jobs, but currently these jobs don't have any
express rules. The .container job does extend jobs that have rules, but
these same rules are already included in debian/x86_64 because it
extends the .debian-container job.
Remove these empty rule references to make debian/x86_64_pyutils more
readable.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32340>
This should not do any conversions and instead return error when image
and surface formats don't match.
There was also special case for I420 fourcc which would swap the order
of U/V planes and because of this the plane order of IYUV format was
incorrectly set to YVU in vl_video_buffer.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32605>
Due to the slow startup time of deqp-vk, the previous default of
500 tests per group caused the jobs to run up to twice as slowly
compared to using a higher number of tests per group.
Increase the number of tests per group for all subsets of the
deqp-runner suites, which allows decreasing the fractions.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32588>
Due to the slow startup time of deqp-vk, the previous default of
500 tests per group caused the jobs to run up to twice as slowly
compared to using a higher number of tests per group.
Increase the number of tests per group for all subsets of the
deqp-runner suites, which allows decreasing the fractions.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32588>
Due to the slow startup time of deqp-vk, the previous default of
500 tests per group caused the jobs to run up to twice as slowly
compared to using a higher number of tests per group.
Increase the number of tests per group for all subsets of the
deqp-runner suites, which allows decreasing the fractions.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32588>
When I last updated this, some of the jobs had too many tests that took
over 30 seconds to show them all in the output. So I only added the
longest ones. Here's the rest, and with this the skip-list seems correct
for now.
Note that there's a few tests that takes close to 30 seconds, so they
might end up getting pushed across the limit from time to time as well.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32603>
While these timeout when I run them locally,
MESA_VK_ABORT_ON_DEVICE_LOSS ends up turning them into crashes on the
CI. Correct this, so we don't accidentally fail the full job here.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32603>
According to HSD 14016252163 if compute shader uses the sample
operation, morton walk order and set the thread group batch size to 4 is
expected to increase sampler cache hit rates by increasing sample
address locality within a subslice.
Rework:
* Caio: "||" => "&&" for type checking in instr_uses_sampler()
* Jordan: Use nir's foreach macros rather than
nir_shader_lower_instructions()
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32430>
SEND instructions of gather variant will use the upcoming ARF scalar
register. They use only Src0 and reuse the bits of Src1.Length (part of
ex_desc). Src1.Length is (implicitly) defined as 0.
Adapt the helper functions to take the new variant into account when
manipulating ex_desc.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32236>
It's allowed to place OpExecuteCallableKHR in a SPIR-V, even if the RT
pipeline doesn't contain any callable shaders. Unreal hits this case and
crashes. We can assume the intrinsic never gets executed, so we can
simply remove it.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32613>
There are a lot of restrictions for bfloat16. The one that prevents this
very useful optimization from being possible is, "Broadcast of bfloat16
scalar is not supported."
Part of the reason this MR exists is to build up to implementing BF
support, and there are a couple more commits that implement
this. However, it fails on both real hardware and simulation:
Instruction is: mad (8|M0) r6.0<1>:f 0xBF80:bf r2.0<8;1>:f r64.0<0>:f
In bfloat/float mixed mode, bfloat src must be packed.
Alas.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
These can't mix with F values, but if the non-constant sources are
already HF, this is allowed in src0.
No shader-db changes on any Intel platform.
fossil-db:
Ice Lake
Totals:
Instrs: 236027458 -> 236027442 (-0.00%)
Cycle count: 24515944704 -> 24515945379 (+0.00%)
Totals from 8 (0.00% of 798454) affected shaders:
Instrs: 10226 -> 10210 (-0.16%)
Cycle count: 58567 -> 59242 (+1.15%)
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
Nothing can generate this currently, but a future commit will.
The Bspec and experimentation support the following limitations:
- Gfx11: Either src0 or src2 can be W or UW.
- Gfx12: Either src0 or src2 can be W or UW.
- Gfx12.5: Both src0 and src2 can be W or UW.
- Gfx20: Both src0 and src2 can be W or UW.
v2: Add missing break statement.
v3: Leave the MAD handling in the case with the other 3 source
instructions. Suggested by Caio.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
v2: Move the full constant folding part to
brw_constant_fold_instruction. Suggested by Caio. I did this by
extracting the core part of the folding to a helper function.
v3: Delete stale comment. Noticed by Caio.
shader-db:
All Intel platforms had similar results. (Lunar Lake shown)
total instructions in shared programs: 18090847 -> 18090843 (<.01%)
instructions in affected programs: 150 -> 146 (-2.67%)
helped: 1 / HURT: 0
total cycles in shared programs: 919664648 -> 919663210 (<.01%)
cycles in affected programs: 3426 -> 1988 (-41.97%)
helped: 1 / HURT: 0
LOST: 1
GAINED: 0
fossil-db:
All Intel platforms had similar results. (Lunar Lake shown)
Totals:
Instrs: 220496486 -> 220496403 (-0.00%)
Cycle count: 31610880908 -> 31610879044 (-0.00%); split: -0.00%, +0.00%
Totals from 70 (0.01% of 702439) affected shaders:
Instrs: 47018 -> 46935 (-0.18%)
Cycle count: 6335504 -> 6333640 (-0.03%); split: -0.11%, +0.09%
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
This enables constant combining to do its job.
v2: Restore accidentally deleted line from a comment. Noticed by Caio.
shader-db:
All Intel platforms had similar results. (Lunar Lake shown)
total cycles in shared programs: 919668392 -> 919669310 (<.01%)
cycles in affected programs: 10125264 -> 10126182 (<.01%)
helped: 348 / HURT: 194
fossil-db:
All Intel platforms had similar results. (Lunar Lake shown)
Totals:
Cycle count: 31610720660 -> 31610692748 (-0.00%); split: -0.00%, +0.00%
Totals from 9066 (1.29% of 702433) affected shaders:
Cycle count: 810411934 -> 810384022 (-0.00%); split: -0.01%, +0.00%
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
No shader-db changes on any Intel platform.
fossil-db:
Meteor Lake, DG2, Tiger Lake, and Ice Lake had similar results. (Meteor Lake shown)
Totals:
Cycle count: 25096109024 -> 25096108722 (-0.00%); split: -0.00%, +0.00%
Totals from 4106 (0.51% of 797610) affected shaders:
Cycle count: 63266176 -> 63265874 (-0.00%); split: -0.01%, +0.01%
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
Always propagate into any source. Let commute_immedates and constant
combining sort out the mess. It's literally their job.
No shader-db changes on any Intel platform. The fossil-db changes just
appear to be subtle changes in register allocation if the immediate
source changes from src0 to src2.
v2: Update the comment in commute_immediates. Suggested by Caio.
fossil-db:
Lunar Lake, Meteor Lake, and DG2 had similar results. (Lunar Lake shown)
Totals:
Cycle count: 31610720510 -> 31610720660 (+0.00%); split: -0.00%, +0.00%
Totals from 8 (0.00% of 702433) affected shaders:
Cycle count: 5522382 -> 5522532 (+0.00%); split: -0.00%, +0.00%
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
No shader-db or fossil-db changes on any Intel platform. This commit
just prevents issues with a later commit, "brw/copy: Don't try to be
clever about ADD3 constant propagation."
v2: Use 'can_promote = true; break;' instead of 'return
true;'. Suggested by Caio.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
Fold the cases where one of the sources is zero or two of the sources
are constants. Both case will result in a regular ADD.
No shader-db or fossil-db changes on any Intel platform. This commit
just prevents issues with a later commit, "brw/copy: Don't try to be
clever about ADD3 constant propagation."
v2: Move the full constant folding part to
brw_constant_fold_instruction. Suggested by Caio.
v3: Eliminate the impossible src.file == BAD_FILE case in
brw_fs_opt_algebraic. Suggested by Caio.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
The current assertion fails as soon as a MAD with src0 and src2 being
immediate is detected.
The assertion was supposted to catch, "If it's ADD3, only one of src0
and src2 can be immediate." The detect this, the opcode test should have
been !=.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Fixes: c1c09e3c4a ("brw/emit: Add correct 3-source instruction assertions for each platform")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
Some callers of brw_constant_fold_instruction depend on the result being
a MOV of immediate when progress is made. Previously `MUL dst:D src0:D
1:D` would be converted to `MOV dst:D src0:D`. There was also no
handling for `MUL dst:D imm0:D imm1:D`.
This could cause problems if one of the immedate values was -1. The
existing code would convert this to a `MOV dst:D imm0:D` and set the
negate flag on src0. That is not correct.
v2: Fix the is_negative_one case handling of the non-negative-one
source. Add a comment explaining the assertion. Both suggested by Caio.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Fixes: 2cc1575a31 ("brw/algebraic: Refactor constant folding out of brw_fs_opt_algebraic")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
Some callers of brw_constant_fold_instruction depend on the result being
a MOV of immediate when progress is made. Previously `ADD dst:D src0:D
0:D` would be converted to `MOV dst:D src0:D`. There was also no
handling for `ADD dst:D imm0:D imm1:D`.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Fixes: 2cc1575a31 ("brw/algebraic: Refactor constant folding out of brw_fs_opt_algebraic")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
so we can use designated initializers and other fun features.
all affected shaders are in gfxbench:
total instructions in shared programs: 2750549 -> 2750497 (<.01%)
instructions in affected programs: 10832 -> 10780 (-0.48%)
helped: 4
HURT: 2
Inconclusive result (value mean confidence interval includes 0).
total alu in shared programs: 2278478 -> 2278760 (0.01%)
alu in affected programs: 7040 -> 7322 (4.01%)
helped: 2
HURT: 4
Alu are HURT.
total fscib in shared programs: 2276985 -> 2277267 (0.01%)
fscib in affected programs: 7040 -> 7322 (4.01%)
helped: 2
HURT: 4
Fscib are HURT.
total bytes in shared programs: 19922466 -> 19922734 (<.01%)
bytes in affected programs: 71412 -> 71680 (0.38%)
helped: 4
HURT: 2
Inconclusive result (value mean confidence interval includes 0).
total regs in shared programs: 865070 -> 865086 (<.01%)
regs in affected programs: 142 -> 158 (11.27%)
helped: 0
HURT: 2
total uniforms in shared programs: 2120930 -> 2121034 (<.01%)
uniforms in affected programs: 244 -> 348 (42.62%)
helped: 0
HURT: 2
total scratch in shared programs: 11576 -> 11600 (0.21%)
scratch in affected programs: 2744 -> 2768 (0.87%)
helped: 0
HURT: 2
total spills in shared programs: 958 -> 868 (-9.39%)
spills in affected programs: 958 -> 868 (-9.39%)
helped: 6
HURT: 0
total fills in shared programs: 732 -> 626 (-14.48%)
fills in affected programs: 732 -> 626 (-14.48%)
helped: 4
HURT: 2
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32529>
In this case, num_sources is bigger than this->sources, so if we loop
up to num_sources (instead of this->sources) we'll end up reading past
the end of old_src[]. Only copy up to what we originally had.
This was found by code inspection, I'm not aware of any applications
failing due to the lack of this patch.
Fixes: d9e737212d ("intel/brw: Add a src array for the common case in fs_inst")
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32600>
We already have and use vk_warn_non_conformant_implementation(), so
we're already being clear that PanVK is not yet conformant. Let's not
repeat that information here, and instead focus on it not being
well-tested.
This brings the wording more or less in-line with NVK.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32561>
This is beneficial to applications that rely on
the implicit primitive ID from VS.
- We don't have to disable provoking vertex reuse,
which results in more efficient vertex processing.
- There is no LDS access needed to export the primitive ID,
because it is already available to GS threads.
- As a consequence of not needing LDS, we can use this
together with NGG passthrough mode.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32270>
This configuration will be enabled in RADV in a subsequent commit.
On GFX10.3:
Do this together with the primitive export, to avoid adding extra
CF, and to ensure optimal access of the export space.
On GFX11:
It's not an export but a memory store instruction, so always do
it earlier and ensure the optimal attribute ring access pattern.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32270>
It doesn't do anything useful for other stages.
In VS, we use this when the implicit primitive ID is needed,
so that we can export that as a per-vertex attribute of the
provoking vertex.
In TES, the patch ID (which is used as the primitive ID) is
already a per-vertex input VGPR, so it doesn't make sense to
configure this.
In GS, the primitive ID is explicitly written by the shader,
so it makes no sense to disable provoking vertex reuse in the
input.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32270>
Borderlands 3 (both DX11 and DX12 renderers) have a common pattern
across many shaders:
con 32x4 %510 = (uint32)txf %2 (handle), %1191 (0x10) (coord), %1 (0x0) (lod), 0 (texture)
con 32x4 %512 = (uint32)txf %2 (handle), %1511 (0x11) (coord), %1 (0x0) (lod), 0 (texture)
...
con 32x4 %550 = (uint32)txf %2 (handle), %1549 (0x25) (coord), %1 (0x0) (lod), 0 (texture)
con 32x4 %552 = (uint32)txf %2 (handle), %1551 (0x26) (coord), %1 (0x0) (lod), 0 (texture)
A single basic block contains piles of texelFetches from a 1D buffer
texture, with constant coordinates. In most cases, only the .x channel
of the result is read. So we have something on the order of 28 sampler
messages, each asking for...a single uint32_t scalar value. Because our
sampler doesn't have any support for convergent block loads (like the
untyped LSC transpose messages for SSBOs)...this means we were emitting
SIMD8/16 (or SIMD16/32 on Xe2) sampler messages for every single scalar,
replicating what's effectively a SIMD1 value to the entire register.
This is hugely wasteful, both in terms of register pressure, and also in
back-and-forth sending and receiving memory messages.
The good news is we can take advantage of our explicit SIMD model to
handle this more efficiently. This patch adds a new optimization pass
that detects a series of SHADER_OPCODE_TXF_LOGICAL, in the same basic
block, with constant offsets, from the same texture. It constructs a
new divergent coordinate where each channel is one of the constants
(i.e <10, 11, 12, ..., 26> in the above example). It issues a new
NoMask divergent texel fetch which loads N useful channels in one go,
and replaces the rest with expansion MOVs that splat the SIMD1 result
back to the full SIMD width. (These get copy propagated away.)
We can pick the SIMD size of the load independently of the native shader
width as well. On Xe2, those 28 convergent loads become a single SIMD32
ld message. On earlier hardware, we use 2 SIMD16 messages. Or we can
use a smaller size when there aren't many to combine.
In fossil-db, this cuts 27% of send messages in affected shaders, 3-6%
of cycles, 2-3% of instructions, and 8-12% of live registers. On A770,
this improves performance of Borderlands 3 by roughly 2.5-3.5%.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32573>
On a single runner, this job currently times out due to taking over 5
hours. The estimate from dEQP runner itself suggests a full run might
take over 8 hours with the current configuration. We can't really work
with that long runs, even if they are manual.
We currently have 7 vim3 runners, so we can actually afford to
parallelize the run a bit, to make this a bit more manageable. If we
choose 4, we take up a bit more than half of the runners, but we leave
two runners (plus a spare) for the pre-merge CI.
With this, a each job takes about 2.5 hours. We leave the timeout at 3
hours for now, to have some headroom for new tests being enabled.
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32591>
We know we have a broken Vulkan driver, so it's debatable whether it's
a broken Vulkan 1.0 or broken 1.1. Advertising 1.1 lets us run more
tests, and this patch does this. We also bump the instance version id
to 1.4, which seems appropriate since the overall Vulkan infrastructure
within Mesa is at that level.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32464>
In preparation for supporting sad (which like mad may benefit from
swapping some of it srcs), extract the swapping from
try_swap_mad_two_srcs so that it can be reused for sad. This is
necessary since, unlike mad, sad might also benefit from swapping srcs
1->2 (instead of only 2->1) or 3->2.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32501>
We would mark mad srcs as swapped once we tried swapping them, even if
it would not succeed. However, it might happen (especially after running
ir3_shared_folding) that a new opportunity for swapping comes up later.
Therefore, we should only mark the srcs as swapped when it actually
succeeded.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32501>
Turns out that sad is just iadd3. I assume it's an acronym for "Sum of
Absolute Differences" which may make sense since its 2nd src supports
(neg) which would allow SAD to be implemented using this instruction.
NIR already supports algebraic patterns for selecting iadd3 so adding
codegen support in ir3 is trivial. However, sad seems to have the same
hardware limitation as mad and doesn't support the scalar ALU so we have
to make sure to disable it when emitting iadd3.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32501>
The override used for the immed encoding in #cat3-src-const-or-immed
used a pattern which isn't supported in overrides by isaspec. The
pattern in the base bitset (10) was too strict for immediates since it
didn't allow the most significant bit to be 1.
Fix this by making the base pattern 1 and adding an assert for the next
bit to be 0 in the non-immed case.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: 1c6c200c0d ("ir3: add newly found shlg.b16 instruction")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32549>
When a timestamped present is not used (MAILBOX or the very first present),
it's possible that the very last queued present ID won't complete in finite time.
Similar to frame callback based workaround, apply a timeout to present
waits when they target the very last submitted presentID.
Only apply the workaround when we're not guaranteed forward progress.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Cc: mesa-stable
Reviewed-by: Autumn Ashton <misyl@froggi.es>
Reviewed-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32556>
When commit-timing was not supported, but FIFO was we would end
up in a situation with throttling on FIFO barrier and legacy fence.
At that point, the entire point of FIFO falls flat.
There are some caveats with this approach, but it's not expected
that compositors will only support FIFO, and not commit-timing long
term.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Fixes: c26ab1aee1 ("vulkan/wsi/wayland: Pace frames with commit-timing-v1")
Reviewed-by: Autumn Ashton <misyl@froggi.es>
Reviewed-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32556>
On AMD hardware, it's possible to export a separate alpha channel for
applying alpha-to-one after alpha-to-coverage and not before.
On GFX11+, it's already mostly supported but alpha needs to be exported
to MRTZ.a and one to MRT0.a. The hw always uses alpha for
alpha-to-coverage from MRTZ.a.
On older generations, the driver needs the same separate alpha export
but it also needs to configure the hardware with COVERAGE_TO_MASK_ENABLE
which selects alpha from MRTZ.a.
This should fix alpha-to-coverage with alpha-to-one when either
depth, stencil or samplemask are exported but it still needs a slightly
different solution without MRTZ. I will fix that later.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32523>
It's just completely broken if alpha-to-coverage is also used. Given
this is a requirement for Zink and no known GL apps are affected, let's
disable for everything except Zink. This is going to be fixed but the
fixes aren't small enough for backporting.
This fixes a rendering issue with XPlane 12.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32576>
llvmpipe_resource_map() may fail, e.g. when the DMA-BUF cannot be
mmap'ed. Handle the error, either by returning NULL or by asserting.
Asserting is done in places where there is no good way to bubble up
the error (and is done in other places already, e.g. in
init_scene_texture).
Signed-off-by: Simon Ser <contact@emersion.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32537>
Seems like the multiview feature unlocked some tests that triggers a
previously unknown bug. This results in an assert triggering, but that
reveals a real, underlying issue.
A few of these doesn't trigger the assert, but still fails due to a GPU
hang.
Let's mark all of these as failures, to avoid holding back other MRs in
the mean time.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32574>
Rather than checking hwconfig items when using them, wait until after
devinfo has been fully initialized. This includes having workarounds
implemented.
We can then check if the hwconfig data and final Mesa initialization
agree. If the match fails, we need to investigate if Mesa or the
hwconfig data is wrong.
This code becomes a no-op when not on a release build.
Fixes: a4c5bfd34c ("intel/dev: Use hwconfig for urb min/max entry values")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12141
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32359>
We already have all the bits wired up to support both
VK_FORMAT_A4R4G4B4_UNORM_PACK16 and VK_FORMAT_A4B4G4R4_UNORM_PACK16_EXT
from VK_EXT_4444_formats, and were already setting the feature-flags for
them.
Let's also expose the extension, which should just work.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32083>
We were missing a couple of 4-bit formats, let's add them.
Vulkan 1.0 already requires VK_FORMAT_B4G4R4A4_UNORM_PACK16, which mapes
to PIPE_FORMAT_A4R4G4B4_UNORM, which we're currently missing support for.
But we can also support VK_FORMAT_R4G4B4A4_UNORM_PACK16, which maps to
PIPE_FORMAT_A4B4G4R4_UNORM. This format is optional, but there's no
reason we shouldn't expose support for it.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32083>
Without multiview, a shader that doesn't write to the any of the
extended FIFO attributes (pointsize and layer) can be used with either
FIFO format. This allows us to switch to the basic FIFO format when
using the no_psiz variant. In multiview vertex shaders, output offsets
depend on the FIFO format. Instead of trying to patch these in the
no_psiz variant, just don't do the optimization for now.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31704>
Two components to this: first we only issue fragment jobs for enabled
views. This prevents disabled layers from being cleared implicitly with
`LOAD_OP_CLEAR`, and also reduces overhead (these layers have no
primitives so the fragment job is wasted work). Second is hooking up the
view mask to vk_meta_clear.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31704>
In Valhall multiview, position/varying shaders are invoked once per
draw. Each invocation write separate outputs for all views. Fragment
processing is handled by the existing multilayer support. Note that
because the hardware only supports up to 8 views, we don't have to care
about the case where there are too many layers to fit in one tiler when
multiview is enabled.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31704>
In panvk we pass absolute view indices to the hardware, so we need to do
the conversion from compacted to absolute at some point. Emitting
absolute indices from nir_lower_multiview initially looks like the
simplest option, but nir_lower_io_to_temporaries will emit a write for
every element of array varyings. This results in unnecessary writes to
disabled views.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31704>
This is needed for implementing multiview in panvk, where the address
calculation for multiview outputs is not well-represented by lowering to
nir_intrinsic_store_output with a single offset.
The case where a variable is both per-view and per-{vertex,primitive} is
now unsupported. This would come up with drivers implementing
NV_mesh_shader or using nir_lower_multiview on geometry, tessellation,
or mesh shaders. No drivers currently do either of these. There was some
code that attempted to handle the nested per-view case by unwrapping
per-view/arrayed types twice, but it's unclear to what extent this
actually worked.
ANV and Turnip both rely on per-view outputs being assigned a unique
driver location for each view, so I've added on option to configure that
behavior rather than removing it.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31704>
Black Myth Wukong is generating more than 2Gb of shaders in
pre-compiling stage after VK_EXT_shader_image_atomic_int64 extension
enabled. Driver will crash in create shader stages due to dereference
null pointer of kernel map.
Signed-off-by: Mi, Yanfeng <yanfeng.mi@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32548>
The last argument seems to be used as brw_shader_reloc::delta (from
brw_add_reloc), and we're unconditionally setting it to 0 here, while
the other place where we handle nir_intrinsic_load_reloc_const_intel
seems to be setting the base appropriately.
I found this by inspection while debugging a bug related to this code,
so I'm not aware of any workloads that get improved by this patch.
Related patches:
- ecbec25e84 ("intel/nir: add reloc delta to load_reloc_const_intel intrinsic")
- 99047451c9 ("intel/fs: add plumbing for embedded samplers")
Fixes: ecbec25e84 ("intel/nir: add reloc delta to load_reloc_const_intel intrinsic")
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/32531>
The slips-file should use the plural form of skip, otherwise it doesn't
end up being used.
We also had some tests that were supposed to be skipped in the expected
failures. Let's remove them, and add a new failure that should have been
turned into a skip to the list as well.
Fixes: eff8a3517d ("panvk: Enable CI on G610")
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32460>
The texture/sampler reswizzle is implemented to allow AFBC for non
canonical component order formats, but it's enabled regardless of
whether the format supports AFBC.
Limit the reswizzling to only apply to formats that support AFBC.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32515>
The AFBC texture/sample reswizzle will not work for formats with
component orders that are not canonical or RB-swapped, as moving the
alpha channel breaks opaque black border-colors.
Disable AFBC for formats with other component orders than RGB and BGR on
v7.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32515>
There should be no limitation on component order support for AFRC, so
the reswizzling of texture/sampler should not be necessary in this case.
For PanVK, only the texture reswizzling was implemented (with the
equivalent sampler reswizzling missing), so removing it allows us to
pass various border-color tests.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32515>
The spec says:
"
When an image view of a depth/stencil image is used as a
depth/stencil framebuffer attachment, the aspectMask is
ignored and both depth and stencil image subresources are used.
"
Make sure we do that when initializing depth/stencil attachments.
Fixes the
dEQP-VK.renderpass.suballocation.subpass_dependencies.late_fragment_tests.*.subpass_count_*.d24_unorm_s8_uint
dEQP-VK.renderpass.suballocation.subpass_dependencies.late_fragment_tests.*.subpass_count_*.d32_sfloat_s8_uint
failures.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32379>
Unscissored glClearColor is using i915_fill_blit().
Clearing can be done with the 1 byte formats
GL_ALPHA, GL_LUMINANCE or GL_INTENSITY.
Routine i915_fill_blit() is called with a rgba-mask containing
1 byte, but it is handling this as a 2-byte color.
This fix adds the needed 1 byte setup to both
i915_fill_blit() and i915_copy_blit().
It solves 1 piglit-test concerning arb_clear_texture-base-formats
and 15 tests concerning fbo-clear-formats.
No regression is shown at other piglit-tests.
Cc: mesa-stable
Signed-off-by: GKraats <vd.kraats@hccnet.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32178>
"constant" is a special keyword in OpenCL C, and we'd like to #define it
suitably in host C23 to facilitate compatiblity between host/device headers.
That means we can't have any identifiers named "global" or "constant".
Fortunately, this is the only 'constant' in any file I'm hitting.
To avoid the clash, don't abbreviate "constant factor", use "constant_factor"
instead. For consistency, "slope factor" then becomes "slope_factor".
The new names are longer but match the Vulkan API exactly.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> [Intel]
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com> [NVK and panvk]
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> [V3DV]
Reviewed-by: Simon Perretta <simon.perretta@imgtec.com> [IMG]
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32505>
Source 2 games segfault if certain buffers are not able to use the same
memory types as images. CS2 specifically expects this to be the case for
vertex and index buffers (VK_BUFFER_USAGE_2_INDEX_BUFFER_BIT,
VK_BUFFER_USAGE_2_VERTEX_BUFFER_BIT). I have not tested other Source 2
games to see how much the requirement differs for the usage (if at all).
Up until now, we've disabled CCS for the Source 2 engine with the
anv_disable_xe2_ccs driconf option. However, this option is not great
for performance. So, replace this with a new option to allow the same
memory types we use for images on buffers - anv_enable_buffer_comp.
Compression of buffers is generally not good for performance. I
collected the result of unconditionally enabling the feature in the
performance CI on BMG. I used the default configuration to average the
result of two runs of each trace.
The CI reports that 4 game traces would regress between 0.44-1.01% FPS
with buffer compression. However, the CI actually shows it to be
beneficial in three of our game traces:
* Cyberpunk-trace-dx12-1080p-high 106.51%
* Hitman3-trace-dx12-1080p-med 101.59%
* Blackops3-trace-dx11-1080p-high 100.44%
So, enable the option for the two games we already have driconf entries
for, Cyberpunk and Hitman3.
Of course, also enable the option for Source 2 games. Casey Bowman
reports that on BMG, some frame times drop from ~15ms to ~7ms in CS2.
This is in large part due to the removal of HiZ resolves, which is a
consequence of the game now using of HIZ_CCS_WT instead of plain HIZ.
Ref: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11520
Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32519>
* drop FDO_CI_CONCURRENT to 1; eliminate intermittent piglit concurrecy issues
* bump PIGLIT_FRACTION to 2; lowering concurrency increases exec time, so
for now compensate with job fraction set to 50%
* triage piglit failures
Signed-off-by: Martin Krastev <martin.krastev@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32526>
As regular branch instructions cannot jump further than
32768 dwords, previously we used long jumps as fallback
solution. The disadvantage of that is that an extra SGPR
pair must be provided in order to temporarily store the PC.
This patch changes that to chained branch instructions by
inserting an artificial extra block into the code to be
targeted by the original branch. This block contains a
single branch instruction jumping to the original target.
Before the block, if necessary, we insert a <branch 1>
instruction for the existing code in order to jump over
the newly inserted block.
Only a few RT shaders are affected.
Totals from 29 (0.04% of 79395) affected shaders: (Navi31)
CodeSize: 17281176 -> 17276332 (-0.03%)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32037>
We are about to add new blocks during assembly which makes
pointers into a vector unreliable.
Also, only set it if the loop has no back-edge.
Totals from 126 (0.16% of 79206) affected shaders: (Navi31)
CodeSize: 1486152 -> 1488152 (+0.13%)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32037>
In IR3 `sel.b32` works based on the 0 so add `icsel_eqz` to fuse the
cmp and sel that we'd otherwise need.
total Instruction Count in shared programs: 1112814 -> 1110473 (-0.21%)
Instruction Count in affected programs: 162701 -> 160360 (-1.44%)
helped: 81
HURT: 29
Instruction count are helped.
total MOV Count in shared programs: 86777 -> 88671 (2.18%)
MOV Count in affected programs: 28119 -> 30013 (6.74%)
helped: 1
HURT: 292
Mov count are HURT.
total COV Count in shared programs: 15070 -> 14962 (-0.72%)
COV Count in affected programs: 5770 -> 5662 (-1.87%)
helped: 76
HURT: 2
Cov count are helped.
total Last helper instruction in shared programs: 592729 -> 590638 (-0.35%)
Last helper instruction in affected programs: 91331 -> 89240 (-2.29%)
helped: 30
HURT: 1
Last helper instruction are helped.
total Instructions with SS sync bit in shared programs: 29336 -> 29546 (0.72%)
Instructions with SS sync bit in affected programs: 4702 -> 4912 (4.47%)
helped: 8
HURT: 43
Instructions with ss sync bit are HURT.
total Estimated cycles stalled on SS in shared programs: 111590 -> 112401 (0.73%)
Estimated cycles stalled on SS in affected programs: 27708 -> 28519 (2.93%)
helped: 21
HURT: 61
Estimated cycles stalled on ss are HURT.
total cat1 instructions in shared programs: 101933 -> 103695 (1.73%)
cat1 instructions in affected programs: 35804 -> 37566 (4.92%)
helped: 18
HURT: 290
Cat1 instructions are HURT.
total cat2 instructions in shared programs: 380299 -> 377499 (-0.74%)
cat2 instructions in affected programs: 128609 -> 125809 (-2.18%)
helped: 322
HURT: 0
Cat2 instructions are helped.
Signed-off-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32189>
The pass that lowers PS outputs has been rewritten since 45d8cd037a
("ac/nir: rewrite ac_nir_lower_ps epilog to fix dual src blending
with mono PS") to handle invalid uses of dual-source blending.
This drirc used to workaround game bugs on GFX11 only should no longer
be necessary.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32514>
DRM_XE_TOPO_EU_PER_DSS and DRM_XE_TOPO_SIMD16_EU_PER_DSS can be any
number of bytes long but it was assuming it was always 4 bytes long.
That was not a issue because Xe KMD return 4 bytes even if only needs
1 or 2 bytes but that is a problem with our HW simulator that was
returning 2 bytes.
Fixes: a24d93aa89 ("intel/dev: Query and compute hardware topology for Xe")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32307>
If the state tracker chooses to implement one format with a more
general one (e.g. GL_ALPHA implemented with GL_RGBA) we end up
in a situation where some components should be ignored. Readpix
handles this correctly, but blit does not, which means that if
we blit between different formats we can end up writing garbage
into some components. Work around this by adding an explicit
swizzle to the pipe_blit_info struct, which can re-arrange elements
and/or put 0 or 1 into appropriate channels, and use this to
set the appropriate values into unused channels via the sampler
view.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31378>
We create NIR shaders here, and we need to free them when we're done with
them as well.
These shaders are created using nir_builder_init_simple_shader(), which
allocates using a NULL ralloc-parent, so ralloc_free should be the right
function to free them with.
Fixes: 514c10344e ("vulkan/meta: Add a concept of rect pipelines")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32486>
In panfrost_query_compression_modifiers we need to ignore AFBC
modifiers if the device does not support AFBC. In order to avoid
duplicating code, we do this by calling panfrost_walk_dmabuf_modifiers
with a flag that indicates we do not want AFRC modifiers.
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32406>
We need to start treating flakes as fails and they are likely different
between chips.
I removed the gfx9 flakes file and renamed the original flakes file
to gfx6-tahiti-flakes.csv, but it would be better to add a new flakes
file for each generation we test.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32288>
The culling code always computes the determinant for culling zero-area
triangles, so passing the state via user SGPRs doesn't really add much
shader code to justify having shader variants for front/back face
culling that uses the same determinant.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32288>
for AGX, we preserve amul all the way until fusing address modes in order to be
able to fuse effectively. so the load/store vectorizer wouldn't vectorize before
fusing.
however, after fusing we get fused intrinsics which are tricky to teach the
vectorizer about as their semantics are pretty subtle. so we can't vectorize
after, either.
the easiest solution is to teach the vectorize about amul, which can always be
replaced by imul for our pattern matches.
this fixes certain cases of vectorization in OpenCL kernels on asahi.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32398>
This is the selector, and it must always be a uniform UD, so there's no
reason to not propagate into it.
No shader-db change on any Intel platform.
fossil-db:
All Intel platforms had similar results. (Lunar Lake shown)
Totals:
Instrs: 220507131 -> 220507127 (-0.00%)
Cycle count: 31607052398 -> 31607053364 (+0.00%); split: -0.00%, +0.00%
Totals from 5 (0.00% of 702410) affected shaders:
Instrs: 995 -> 991 (-0.40%)
Cycle count: 86392 -> 87358 (+1.12%); split: -0.07%, +1.19%
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32097>
The next two commits modify the destination regioning in a way that,
which still correct, trigger assertion failures if we try to fix the
regioning here.
Broadcast gets lowered in brw_eu_emit. For the purposes of region
restrictions, let's assume that the final code emission will do the
right thing. Doing a bunch of shuffling here is only going to make a
mess of things.
No shader-db or fossil-db changes on any Intel platform.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32097>
The spec mandates that if the program object isn't created from IL, it
should not touch the buffer. Passing an empty slice would achieve that,
but it's better to be explicit here.
Reviewed-by: @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32268>
The old way was quite annoying as it required to create a Vec to even get
the size of the result causing needless computations.
This also meant that copying into the result buffer always required to go
through a byte Vec even though we could just do the copy directly.
The main idea here is that instead of returning the result, we simply call
into a write function giving us more flexibility here.
Potentially this will also allow us to add overloads for Iterators or to
even use closures in case the size calculation is cheaper than creating
the value just to get the size.
Reviewed-by: @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32268>
If input_value, index, index1 or index2 is an input, here are examples of
code that this commit moves from consumers to producers:
* input_value * uniform_array[index]
* uniform_array[index]
* ubo[0].array[index]
* ubo[index].var
* ubo[index1].array[index2]
If the array index is computed from an input, it must be flat or convergent
within a primitive to be moved. If the array index is not an input, it must
be a uniform expression.
dEQP-GLES31.functional.shaders.opaque_type_indexing.ubo.dynamically_uniform_fragment
has UBO indexing that is moved to the producer by this.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32424>
They are a maintainenance burden since they would need changes to
support more instruction types that nir_opt_varyings will be able to
move between shaders, and they are almost identical to
default_varying_estimate_instr_cost, so just use that.
The cost threshold is adjusted for AMD because
default_varying_estimate_instr_cost is slightly different.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32424>
Without this, compaction can put inputs into vec4 slots already occupied
by indirectly-accessed inputs while ignoring their interpolation qualifier,
which is incorrect.
All input components sharing the same vec4 slot must use interpolation
qualifiers that are compatible with each other.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32424>
Even the most flexible interpolation that we have in NIR options
(nir_io_has_flexible_input_interpolation_except_flat) doesn't allow
mixing flat and non-flat in the same vec4. This (legacy) optimization
can't promote interpolated inputs to flat if it doesn't consider
the interpolation mode of the whole vec4 slot.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32424>
The fast implementation can be off by a lot for small values.
Fixes:
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.compute.lod_op.query.linear.16_1_1.mip_0
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.compute.lod_op.query.linear.16_1_1.mip_1
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.compute.lod_op.query.linear.4_4_1.mip_0
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.compute.lod_op.query.linear.4_4_1.mip_1
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.mesh.lod_op.query.linear.16_1_1.mip_0
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.mesh.lod_op.query.linear.16_1_1.mip_1
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.mesh.lod_op.query.linear.4_4_1.mip_0
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.mesh.lod_op.query.linear.4_4_1.mip_1
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.task.lod_op.query.linear.16_1_1.mip_0
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.task.lod_op.query.linear.16_1_1.mip_1
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.task.lod_op.query.linear.4_4_1.mip_0
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.task.lod_op.query.linear.4_4_1.mip_1
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31056>
This commit allows you to dump different regions of memory related to
bvh building. An additional script to decode the memory dump is also
added, and you're able to view the built bvh in 3D view in html. See the
included README.md for usage.
Rework:
- you can now view the actual child_coord in internalNode in html
- change exponent to be int8_t in the interpreter
- fix the actual coordinates using an updated formula
- now you can have 3D view of the bvh
- blockIncr could be 2 and vk_aabb should be first
- Now, if any bvh dump is enabled, we will zero out tlas, to prevent gpu
hang caused by incorrect tlas traversal
- rootNodeOffset is back to the beginning
- Add INTEL_DEBUG=bvh_no_build.
- Fix type of dump_size
- add assertion for a 4B alignment
- when clearing out bvh, only clear out everything after
(header+bvh_offset)
- TODO: instead of dumping on destory, track in the command buffer
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31588>
Rework: (Kevin)
- Properly setup bvh_layout
Our bvh resides in contiguous memory and can be divided into two sections:
1. anv_accel_struct_header, tightly followed by
2. actual bvh, which starts with root node, followed by interleaving
leaves or internal nodes.
- Update comments for some fields for BVH and nodes.
- Properly populate the UUIDs in serialization header
- separate header func into completely two paths based on compaction bit
- Encode rt_uuid at second VK_UUID_SIZE.
- Write query result at correct slot
- add assertion for a 4B alignment
- move bvh_layout to anv_bvh
- Use meson option to decide which files to compile
- The alignment of serialization size is not needed
- Change static_assert to STATIC_ASSERT and move them inside functions
Rework (Sagar)
- Use anv_cmd_buffer_update_buffer instead of MI to copy data
Rework (Lionel)
- Remove flush after builds, and add flush in copy before dispatch
- Handle the flushes in CmdWriteAccelerationStructuresPropertiesKHR properly
Co-authored-by: Kevin Chuang <kaiwenjon23@gmail.com>
Co-authored-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31588>
This shader gets called and will construct ANV BVH from IR BVH. More
specifically, each invocation will take care of one internal node. The
internal nodes get processed starting from root node all the way to the
bottom leaves.
During processing, we keep track of the destination of
where the internal node should be encoded (tracked in
vk_ir_box.bvh_offset), and where its leaves should be encoded (tracked
in vk_ir_header.dst_node_offset).
The processed bvh is in contiguous memory, which starts with header,
followed by interleaving internal nodes and leaves. The nodes
information are also populated.
Rework: (Sagar)
- Return out of bounds threads early
- Mimic GRL internal node encoding
- Handle node mask
- Fix block_incr_and_start_prim
- Fix shader_index_and_geom_mask for instance node
- Fix instance flag
- Fix block_incr and instance_contribution_and_geom_flags initialized to be zero
- Fix lower_x and upper_x to be properly flipped for invalid child
- For invalid node, clear blockIncr and set startPrim to INVALID
- Calculated things upfront and assign, cutting down more than ~200
instructions
Co-authored-by: Kevin Chuang <kaiwenjon23@gmail.com>
Co-authored-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31588>
This commit adds build interface and helper header for ANV BVH.
Rework: (Kevin)
- Use block_size macro to represent bvh node/leaf size
- Rename BVH-related node/leaf size macros for clarity
- Updated comments for some fields for bvh and nodes.
- move bvh_layout to anv_bvh.h
- Draw anv_bvh layout
- rename child_offset to child_block_offset
Co-authored-by: Kevin Chuang <kaiwenjon23@gmail.com>
Co-authored-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31588>
We were wanting to check if the destination region spanned multiple
registers. But we were checking against REG_SIZE, when the register
size is actually REG_SIZE * reg_unit(devinfo) now.
This meant that SIMD32 LOAD_PAYLOAD was always getting SIMD-split
on Xe2 platforms, generating a lot of unnecessary mess for compute
shaders.
fossil-db results on Lunar Lake:
Totals:
Instrs: 146178614 -> 143291988 (-1.97%); split: -1.98%, +0.00%
Subgroup size: 11089632 -> 11089376 (-0.00%); split: +0.00%, -0.00%
Cycle count: 22528892444 -> 22507551650 (-0.09%); split: -0.12%, +0.03%
Max live registers: 48834202 -> 48886685 (+0.11%); split: -0.09%, +0.20%
Totals from 134306 (24.10% of 557327) affected shaders:
Instrs: 28806335 -> 25919709 (-10.02%); split: -10.02%, +0.00%
Subgroup size: 4297680 -> 4297424 (-0.01%); split: +0.00%, -0.01%
Cycle count: 956867650 -> 935526856 (-2.23%); split: -2.84%, +0.61%
Max live registers: 13085711 -> 13138194 (+0.40%); split: -0.33%, +0.73%
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32471>
* In the ACM PRMs, the programming notes under
RENDER_SURFACE_STATE::MemoryCompressionEnable state that the
DecompressInL3 bit must be set for media compression.
* Unlike TGL, ACM seems to handle format reinterpretation just fine
without using the bit.
Update the assignment accordingly.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32192>
The bitstreamStartOffset from the VK_QUERY_TYPE_VIDEO_ENCODE_FEEDBACK_KHR query in RADV is currently relative to the dstBuffer, and not dstBuffer + dstBufferOffset like the spec states.
To fix this, let's append the offset to the VA directly and not tell the encoder about the offset relative to the VA at all.
The Vulkan spec states:
"VK_VIDEO_ENCODE_FEEDBACK_BITSTREAM_BUFFER_OFFSET_BIT_KHR specifies that queries managed by the pool will capture the byte offset of the bitstream data written by the video encode operation to the bitstream buffer specified in VkVideoEncodeInfoKHR::dstBuffer relative to the offset specified in VkVideoEncodeInfoKHR::dstBufferOffset."
The relevant part being that is is relative to dstBufferOffset and not the start of the VkBuffer.
Signed-off-by: Autumn Ashton <misyl@froggi.es>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32452>
We also need to report minmax as part of the format-features.
This fixes the following CTS tests for me:
- dEQP-VK.api.info.format_properties.r8_unorm
- dEQP-VK.api.info.format_properties.r8_snorm
- dEQP-VK.api.info.format_properties.r16_sfloat
- dEQP-VK.api.info.format_properties.r32_sfloat
- dEQP-VK.api.info.format_properties.d16_unorm
Fixes: 1fc454673a ("panvk: Implement VK_EXT_sampler_filter_minmax for v10")
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32445>
This is a prerequisite for enabling nir_opt_varyings for all gallium
drivers.
nir_lower_io_passes (called by the GLSL linker) only uses NIR options
to lower indirect IO access before lowering IO and calling
nir_opt_varyings.
Most drivers report full support for indirect IO and lower it themselves,
which prevents compaction of lowered indirectly accessed varyings because
nir_opt_varyings doesn't touch indirect varyings.
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> (Rb for asahi)
Reviewed-by: Pavel Ondračka <pavel.ondracka@gmail.com> (for r300)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32423>
In case of userqueue, kernel bo kms_handle will not hold fences for non
shared bo. Non shared bo fences are taken care within mesa. Hence need
to copy the data to another shared buffer for export.
Keeping has_local_buffers true for userq will make non shared bo to
be copied to shared bo for export in si_texture_get_handle().
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29010>
This patch adds the job submission code for userq. An indirect buffer, in
short ib, can be considered a job. The job is submitted directly to the
userq ring buffer and the doorbell is rung to notify the firmware to
execute the job.
The packets that are submitted to execute the job is below,
1) fence wait multi packet for any dependency fence
2) hdp flush packs to flush host data path
3) indirect buffer packet
4) protected signal packet
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29010>
In case of userq when destroying bo, fences are gathered and passed to kernel.
Fences are gathered using bo_fence_lock, In do_winsys_deinit() currently
bo_cache is destroyed after destroying bo_fence_lock. This leads to crash.
Fix this by moving destroying bo_fence_lock late in do_winsys_deinit().
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29010>
In case of kernel queues method of job submission, buffer list for the job
is passed to amdgpu_cs ioctl. Kernel can ensure that VM mapping is
completed before submitting the job.
With user queues amdgpu_cs ioctl is not called, so the kernel can't determine
automatically when BO should be prepared for submissions. To achieve this, a
timeline syncobj is attach to the gem_va ioctls, which can then be used as a
dependency for future jobs.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29010>
RS and BLT operations can exhibit issues in some cases. To help in debugging
such issues stall after RS and BLT operations when ETNA_MESA_DEBUG=draw_stall
is enabled. In that case the FE will point right at the faulty RS/BLT
operation, instead of the next stall which may be many state loads later.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32444>
This moves the tlb job load/store logic to the new helper
v3d_update_job_tlb_load_store. Then an early return is included
so if the rasterizer discard is enabled, no load/stores are
emitted because of the draw call.
This helps in situations where transform feedback is used
and there is only interest in the geometry results. We identified
that some jobs were not rendering at all, but they were having the
performance cost of doing several loads and stores.
This generates a huge performance improvement on manhattan benchmarks.
fps_avg helped: gl_gfxbench_manhattan.trace: 8.37 -> 11.54 (37.85%)
fps_avg helped: gl_gfxbench_manhattan31.trace: 6.02 -> 7.51 (24.62%)
total fps_avg in affected (through threshold) runs: 14.39 -> 19.04 (32.32%)
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32351>
Move the tool to summarize a failed pipeline to a generic .marge/hooks
directory. This will allow the fdo-bots repo to handle all marge hooks in
a consistent way across repositories that use this service.
Add a symlink to the bin/ci directory so that the pipeline summary tool
can still be run locally as well.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32413>
Notably, our convergent block loads were already overfetching - we
rounded up to block sizes of 8, 16, 32, or 64(LSC-only). But we did
so in the backend, rather than NIR.
With recent changes, nir_opt_load_store_vectorizer allows holes of up
to 28 bytes (7 components at 4 bytes each). This allows us to detect
cases where we did a convergent block load for 1 component (but loaded
a whole vec8), then another load for the next vec8, and combine them
into a single V16 load. Single component loads aren't the most common,
but convergent loads of a vec2 in one group and a vec3 in another are
quite common, and it makes no sense to do V8+V8 loads instead of V16.
For non-block loads, we allow a max hole of 4 bytes. This allows the
common case of XYZ_ + XYZ_ loads (where the last component is unread)
to combine into a single larger load.
fossil-db results on Lunarlake:
Totals:
Instrs: 146692608 -> 146246432 (-0.30%); split: -0.33%, +0.02%
Subgroup size: 11100528 -> 11100512 (-0.00%)
Send messages: 7003425 -> 6862529 (-2.01%); split: -2.01%, +0.00%
Cycle count: 22396273274 -> 22523048654 (+0.57%); split: -1.08%, +1.64%
Spill count: 67671 -> 67594 (-0.11%); split: -1.59%, +1.48%
Fill count: 128999 -> 130223 (+0.95%); split: -1.73%, +2.68%
Scratch Memory Size: 5986304 -> 6042624 (+0.94%); split: -1.40%, +2.34%
Max live registers: 48898858 -> 48881655 (-0.04%); split: -0.05%, +0.01%
Non SSA regs after NIR: 172397792 -> 167577380 (-2.80%); split: -2.80%, +0.00%
Totals from 451003 (80.87% of 557667) affected shaders:
Instrs: 134111754 -> 133665578 (-0.33%); split: -0.36%, +0.03%
Subgroup size: 9039104 -> 9039088 (-0.00%)
Send messages: 6127775 -> 5986879 (-2.30%); split: -2.30%, +0.00%
Cycle count: 20306336726 -> 20433112106 (+0.62%); split: -1.19%, +1.81%
Spill count: 56230 -> 56153 (-0.14%); split: -1.92%, +1.78%
Fill count: 112920 -> 114144 (+1.08%); split: -1.97%, +3.06%
Scratch Memory Size: 3769344 -> 3825664 (+1.49%); split: -2.23%, +3.72%
Max live registers: 43750259 -> 43733056 (-0.04%); split: -0.05%, +0.01%
Non SSA regs after NIR: 158449343 -> 153628931 (-3.04%); split: -3.04%, +0.00%
In particular, sends get cut by 20.85% for Borderlands 3 DX12, 13.82%
on Cyberpunk 2077, 10.75% on Strange Brigade, and 10.20% on Red Dead
Redemption 2. Yet, spill/fills remain about the same.
fossil-db results on Alchemist are similar though not quite as good.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32315>
nir_opt_load_store_vectorize checks for potential address wrapping
when vectorizing two loads ("low" and "high"). It looks for cases where
"low" might have a large address, and "high" has a positive offset
which, when added together, could trigger integer wraparound. The issue
here is that if the large address of "low" was considered out-of-bounds,
adding offset could wrap around to a small address, which might actually
be in-bounds. Thus, when loaded separately, "low" will fail and trigger
robustness out-of-bound-read behavior, but "high" would read correctly.
When vectorized, the entire load would fail. This is explicitly tested
for with 32-bit SSBO addresses in the Vulkan CTS.
However, anv's 64-bit global addresses and VMA handling effectively
prevent this case. Addresses 0-4095 are a reserved page so that if
people try to use 0 as a NULL pointer, it never maps to a valid BO.
That alone guarantees that the above case where "high" gets a small
address would never be in-bounds, so we don't need to check for it.
In fact, we allocate most user allocations out of high addresses,
and have specialized allocation heaps for certain types of GPU data
structures in the lower GB of memory. For a load to wrap around and
successfully land in the right heap, it would have to load gigabytes.
Disabling this allows load vectorization and overfetching in more cases.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32315>
The load_*_uniform_block_intel intrinsics always load either 8x or 16x
32-bit components worth of data (so 32 byte increments). This leads to
cases where we load a few components from one vec8, followed by a few
components of an adjacent vec8. We want to combine those into a vec16
load, as that loads a whole cacheline at a time, and requires less hoops
to calculate addresses and request memory loads.
So, we allow 7 * 4 = 28 bytes of holes, which handles vec8+vec8 where
only the .x component is read.
Most drivers and intrinsics will not want such large holes. I thought
about adding a per-intrinsic max_hole to the core code, but decided that
since we already have driver callbacks, we can just rely on them to
reject what makes sense to them.
No driver callbacks currently allow holes, so this should not currently
affect any drivers. But any work in progress branches may need to be
updated to reject larger holes.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32315>
This will matter more with overfetching, where we may suggest loading
additional data that we don't actually need for vectorization purposes.
We want to make sure that push ranges have the data we actually need;
any extra padding is irrelevant.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32315>
i965 used to upload its own regular GL uniforms and push those in
addition to UBO ranges. st/mesa instead uploads regular uniforms
and presents those to use as UBO 0. So this really isn't a thing
anymore.
nir_intrinsic_load_uniform is still used today but it represents
Vulkan push constants. anv_nir_compute_push_layout already takes
care of ensuring too many ranges aren't present, so it doesn't need
the pass to do so. iris doesn't use this intrinsic at all.
We can also drop the compute shader check, because neither iris nor
anv use UBO push analysis for compute shaders - except for anv's
internal kernels, which already have well specified push layouts.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32315>
DXIL requires that each I/O variable has a unique semantic name, but when
dealing with semantics that take up multiple slots, that variable implicitly
takes up multiple names. So when assigning driver_location, we need to do
the same.
That means also updating outputs and patch constants to have a mapping from
driver_location to a compacted index, since the metadata arrays *can't* have
holes.
This would be simpler if we could hang it off the nir_variable but there's
not really any free fields to be able to do that. We only need this compacted
mapping inside the DXIL backend anyway so we can just store the array in the
module.
Tested-by: Benjamin Otte <otte@gnome.org>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12128
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32047>
Vulkan 1.4 can only be exposed on a7xx devices due to a number of bumps
in the required limits, including bumping maxDescriptorSets to 7. a7xx
bumped the number of bindless bases from 5 to 8, with one reserved for
the driver.
I've followed what we've already done and exposed a conformanceVersion
of 1.4.0.0 for all a7xx devices, even though I've only submitted
conformance for X1-85. I'm not sure if we want to change this, but at
least for now a618 on Chromebooks and X1-85 on laptops are the only
cases where turnip is being "shipped" to users in some official
capacity, so it shouldn't be a huge deal.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32437>
Vulkan runtime doesn't layer vkGetImageMemoryRequirements2
on top of vkGetDeviceImageMemoryRequirements, as that would
require initializing a full image, which is expensive on
certain drivers such as NVK, so it's up to us to implement
both functions.
In our implementation of vkGetDeviceImageMemoryRequirements,
we initialize a slimmed down image and then forward everything
to vkGetImageMemoryRequirements2.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32361>
pan_resource_modifier_convert can use a blit to convert images
from AFBC. If we call this from panfrost_set_shader_images then
we end up crashing due to using an inconsistent set of images.
Fix this by doing the AFBC/AFRC conversion before the image
bindings.
This fixes a crash in piglit oes_egl_image_external_essl3 tests.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30243>
agx_gpu_time_to_ns() was broken since it was overflowing the u64
timestamp after just ~10 minutes. Fix that by automatically computing a
reduced conversion fraction, and add support for DRM_ASAHI_GET_TIME
where supported (replacing the CPU timer hack).
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32434>
Commit 361f362258 ("dri: Unify createImage and createImageWithModifiers")
has introduced new behavior for drivers which don't support explicit
format modifiers. Before this commit, INVALID was not special-cased
and any call to dri_create_image() with one or more modifiers returned
NULL. After this commit, INVALID gained a special meaning: it indicates
that the implicit modifier is accepted by the caller. This is surprising
and is an API break.
This causes further API breaks: for instance, before this commit a BO
created via gbm_bo_create_with_modifiers() was guaranteed to always
return a non-INVALID modifier in gbm_bo_get_modifier().
This is inconsistent with gbm_dri_surface_create(): that function
treats INVALID as a bad entry in the modifier list, and fails if
it's the only acceptable modifier.
Additionally, drivers don't special-case INVALID and just ignore it
if they see it in a modifier list. This causes more inconsistencies.
For instance, let's say that a library user passes the modifier list
{ INVALID, FOO } to GBM. If a driver supports explicit modifiers and
doesn't support FOO for scanout, it'll return NULL. If a driver
doesn't support explicit modifiers, the current logic would return
a non-NULL BO with an INVALID modifier. This discrepency makes it
harder to reason about the system: half of the API ignores INVALID,
while the other half assumes INVALID indicates an implicit modifier.
To fix these issues, revert to the behavior before the commit, and
require use of the dedicated API without supplying any modifier for
implicit modifiers.
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: 361f362258 ("dri: Unify createImage and createImageWithModifiers")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32396>
We never split live ranges, so we don't need to store the location of
each live value when recording live outs, but the physreg assigned to a
register will still be clobbered when we reload it so we have to record
the original physreg and then make sure to use it when reloading the
live out.
We probably never encountered a case where we needed to reload live outs
in a loop before, but after enabling clustered subgroup reductions
dEQP-VK.subgroups.clustered.compute.subgroupclusteredmin_{i,u}64vec4_requiredsubgroupsize
hits this case and fails in RA validation without this fix.
Fixes: fa22b0901a ("ir3/ra: Add specialized shared register RA/spilling")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32435>
If the caller passed in the same DRM file description, use it for sws->fd
as well. This is simpler than the previously reverted commit and also
fixes https://gitlab.freedesktop.org/mesa/mesa/-/issues/12208.
v2:
* Move fallback sws->fd assignment to proper scope, fixes CI failures.
* Remove close(sws->fd) from amdgpu_winsys_create failure path, it can
never be a valid file descriptor != aws->fd there.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32377>
If the condition of the loop terminator is based on an unsigned value we
can in some cases find the max number of possible loop trips. With the
max loop trips know a complex unroll can unroll the loop.
For example:
uniform uint x;
uint i = x;
while (true) {
if (i >= 4)
break;
i += 6;
}
The above loop can be unrolled even though we don't know the initial
value of the induction variable because it can have at most 1 iteration.
There were no changes with my shader-db collection. Change was inspired
by MR #31312 where builtin shader code failed to unroll.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31701>
This is mostly adapted from radv's BVH building. This defines a common
"IR" for BVH trees, two algorithms for constructing it, and a callback
that the driver implements for encoding. The framework takes care of
parallelizing the different passes, so the driver just has to split the
encoding process into "stages" and implement just one part for each
stage.
The runtime changes are:
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
The radv changes are;
Reviewed-by: Friedrich Vock <friedrich.vock@gmx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31433>
This is mostly adapted from radv's BVH building. This defines a common
"IR" for BVH trees, two algorithms for constructing it, and a callback
that the driver implements for encoding. The framework takes care of
parallelizing the different passes, so the driver just has to split the
encoding process into "stages" and implement just one part for each
stage.
The runtime changes are:
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
The radv changes are;
Reviewed-by: Friedrich Vock <friedrich.vock@gmx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31433>
All of these are functions that could reasonably be incorporated into a
Vulkan extension, but are currently missing. While we could in theory do
BVH building without them, using them simplifies the code significantly
and both radv and turnip can reasonably implement them.
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31433>
All functions that used to take an ir3_block as argument to append
instructions to now take an ir3_builder as argument.
Add an ir3_builder field to ir3_context and replace all uses of
ir3_context::block for creating instructions with ir3_context::build.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32088>
During instruction selection, instructions are sometimes emitted to
blocks other than the current one. For example, to predecessor blocks
for phi sources or to the first block for inputs. For those cases, a new
builder is created to emit at the end of the target block. However, if
the target block happens to be the same as the current block, the main
builder would not be updated to point past the new instructions.
Therefore, don't update the cursor when it points to the end of a block
to ensure that new instructions will always be added at the end.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32088>
Use box with largest ray interval for shadow rays (terminate on first
hit) as it maximizes the probability of finding some object in that box;
for reflection (closest hit) rays, use midpoint instead, which defers
processing of larger boxes the ray origin is in in favor of smaller
boxes closer to origin.
Since the sorting mode must be uniform, when terminate_on_first_hit flag
is divergent, we leave it as closest.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32416>
This allows `gbm_bo_get_offset()` to return the correct offset for e.g.
the second plane of a resource with the NV12 format. Crucially this
fixes direct scanout / hardware plane usage in Mutter and possibly other
clients.
While on it also add support for stride, modifier and n_planes queries.
The later two should not change in behavior and just safe a few CPU
cycles. The stride query support in theory fixes queries for multi-plane
formats, however in practice most/all currently used formats such as NV12,
P010 and YUV420 use the same stride for all planes.
Cc: mesa-stable
Acked-by: Rob Clark <robclark@freedesktop.org>
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32282>
This is implemented differently depending on the cluster size:
- At most 8: in this case, executing brcst.active will leave the
reduction in the last invocation of each cluster. Simply iterate the
clusters and broadcast the last invocation to the rest.
- Otherwise, also iterate the clusters but execute the usual
reduce_clusters_ir3 loop for each of them.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31731>
Now that we use shfl for lowering shuffle operations, the generic
lowering of scan/reduce to shuffles results in faster code than our
custom loop for 64b operations.
Note that this was measured using a micro benchmark on full subgroups.
The generic lowering might be slower when not all invocations are active
but this should be a rare case.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31731>
Basic vertex/fragment shader I/O and sysval allocation rewritten to use
the new compiler/driver interface, with allocation moved entirely into
the driver.
RHW coeffs now only emitted when required.
Boilerplate support for converting formats for vs inputs/fs outputs.
Signed-off-by: Simon Perretta <simon.perretta@imgtec.com>
Acked-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32258>
Fix addition where one summand was already used as input to an earlier
operation, for example in the last operation of MobileNet V2 residual
blocks.
Fixes an assertion when trying to run MobileNet V2:
.../src/gallium/drivers/etnaviv/etnaviv_ml.c:58: etna_ml_create_tensor: Assertion `size == pipe_buffer_size(res)' failed.
Reviewed-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31987>
The hardware only supports unsigned 8-bit tensors, but with the
configurable zero point we can map signed 8-bit integers to unsigned
8-bit integers by adding a constant offset of 128 to all values and to
the zero point setting.
This requires adding 128 to all input tensors and subtracting 128
from all output tensors during inference.
Reviewed-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31979>
Prior to VCN4, the encode queue is separate from the decode queue. For
encode, the WRITE_MEMORY command can be executed with similar framing as
for VCN4, but notably there is no signature support, so it must be
skipped.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32400>
Use the new event-based tracing system to capture IDVS/COMPUTE/FRAGMENT
jobs and their context.
When tracing is enabled, the descriptor ring buffer is replaced by
a bigger linear buffer such that descriptors are not recycled before
we get a change to decode the trace.
If the decode buffer is too small and a OOB is detected, the driver will
suggest the user to allocate a bigger buffer with the
PANVK_{DESC,CS}_TRACEBUF_SIZE env vars.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32284>
Interpreting the command buffer only really works if everything is
static, but panvk started to make extensive use of loops, and
conditionals which depends on memory values that get updated by the
command stream itself. This makes it impossible to walk back to the
original state in order to replay the CS actions.
Move away from this approach in favor of an event-based tracing
mechanism recording particular CS commands and their context at
execution time. Of course, that means the auxiliary descriptors
shouldn't be recycled until the traces are decoded, but that's more
tractable. We just need to turn the descriptor ring buffers into
linear buffers with a guard page, and crash on OOB, with a message
suggesting the user to tweak the maximum trace buffer sizes.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32284>
The previous code not only left them undefined, but also
didn't increment the array index, so subsequent PS inputs
would be broken after the undefined one.
Note that this doesn't affect any valid Vulkan apps, but it makes
the code a bit simpler and it makes undefined inputs a little more
forgiving, at no expense for valid PS.
This code actually uncovers a bug in Zink, so I'm also documenting
the failing Zink test case.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32220>
There are some FS built-ins that can be per-vertex or
per-primitive depending on whether a mesh shader is used:
primitive ID (implicit in VS), layer and viewport.
However, the HW requires per-primitive FS inputs to be ordered last.
This causes bugs when the same unlinked FS is used together
with VS/TES/GS and MS (with unlinked ESO or fast-linked GPL).
To solve this problem, we reorder the FS inputs so that these
potentially per-primitive inputs go after per-vertex inputs but
before per-primitive inputs.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32220>
switch libagx to the precompilation pipeline. see the big comment in the
previous commit for why we're doing this.
while doing so, we move some dispatch stuff. there was so much churn from
precompile that this avoids doing the churn twice. that new header will be used
for DGC down the road.
there's also a small vtn/bindgen patch in here to skip bindgen'ing entrypoints,
as that conflicts with the new dispatch macros. this is the sane behaviour, we
just need to do the full precomp switch across the tree at once.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32339>
This seems to be a little faster.
insert_NOPs (navi31):
Difference at 95.0% confidence
-11.484 +/- 6.13377
-1.62767% +/- 0.860593%
(Student's t, pooled s = 5.71913)
insert_NOPs (gfx1200):
Difference at 95.0% confidence
-35.6745 +/- 4.97972
-8.1236% +/- 1.10453%
(Student's t, pooled s = 4.6431)
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32374>
After the breaking commit, gbm_bo_create_with_modifiers({LINEAR}) returns
a BO with gbm_bo_get_modifier() = INVALID. This restores the functionality
and fixes most notably, hardware cursors for cards without modifiers.
Fixes#12039.
Fixes: 361f362258 ("dri: Unify createImage and createImageWithModifiers")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31725>
This is currently needed to fix d3d12 for st_unlower_io_to_vars.
The idea is to track the current value of ClipVertex in a temporary
variable, and for every emit_vertex, we load the ClipVertex value from
the temporary (which matches the stored value) and insert new CLIP_DIST
stores before emit_vertex.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32363>
The code for IO variables was interleaved with code for IO intrinsics,
which was difficult to follow.
lower_clip_outputs is split and replaced by more accurate names:
lower_clip_vertex_var and lower_clip_vertex_intrin
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32363>
Predication instructions sometimes need extra nops to workaround what
seems to be a hardware bug: prede needs 6 nops and the second
predt/predf of a predt/predf pair needs 4 nops.
The prede workaround is enabled starting from a6xx gen3 and the
predf/predt workaround from a6xx gen4, following the blob.
Fixes rendering corruption in God of War (2018).
Signed-off-by: Job Noorman <job@noorman.info>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32366>
ir3 has a number of bitwise triops (e.g., shrm == (src0 >> src1) & src2)
that don't have NIR-equivalents. Doing instruction selection for them is
a lot more convenient using algebraic patterns than to have to manually
match for them. This patch add NIR opcodes for these instructions.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Reviewed-by: Rob Clark <robclark@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32181>
This reverts commit c49a71c03c.
It broke radeonsi.
GBM can't set __DRI_IMAGE_USE_BACKBUFFER if gbm itself doesn't use it as
a back buffer by rendering to it and calling SwapBuffers. If another
library uses it as a back buffer, that library should set
__DRI_IMAGE_USE_BACKBUFFER, not GBM. A different flag could be added
to indicate the behavior that the original commit expected.
Fixes: c49a71c03c - gbm: mark surface buffers as explicit flushed
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11996
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32345>
In commit a34982063 (Support standalone executable builds on Android,
2024-09-12) upstream VK-GL-CTS added support for building deqp as an
executable command for Android, this change is included in the vulkan
branch used by build-deqp.sh so the custom patches can be dropped for
the Vulkan CTS build.
After that and by passing -DDEQP_ANDROID_EXE=ON deqp can now be built
with DEQP_API=tools.
[Eric]
Note that the upstream solution seems to be broken on EGL, so GL & GLES
continue to use the local android patches; for more details, see:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28168#note_2676128
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28168>
GFX10.3 and earlier were configured to count the number of dwords written,
and VGT_STRMOUT_DRAW_OPAQUE_VERTEX_STRIDE was also configured in dw units.
GFX11+ on the other hand used nir code that would use bytes.
This commit aligns radeonsi's logic on the radv's one, and use STRMOUT_DATA_TYPE
to configure older chips to use bytes as well.
This fixes GTF-GL46.gtf40.GL3Tests.transform_feedback2.transform_feedback2_two_buffers.
It also seems to have an effect on:
- dEQP-GLES3.functional.transform_feedback.random.separate.*
- dEQP-GLES3.functional.transform_feedback.random_full_array_capture.separate.*
but the results seem flaky so need further investigation.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32281>
The specification doesn't say which error should be reported, but
piglit expects BadMatch:
/* The GLX_ARB_create_context_robustness spec does not say what error
* code should be generated. However, similar cases (e.g., valid GL
* versions) specify BadMatch. This is also the behavior of NVIDIA's
* closed-source driver.
*/
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32281>
Front rendering and (display) DCC are causing artifacts on screen.
si_texture_get_handle deals with this problem by disabling dcc, but
we can make it simpler by not allocating DCC at all when this flag
is set.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32281>
a7xx hardware has 8x MSAA capabilities we can expose. The 8-bit sample
count flag is included in the supported sample counts when computing image
format properties for MSAA-capable image creation conditions, with the
exception of 128-bit formats that don't support 8x MSAA.
UBWC blocksize logic is updated to cover cases of 16-bit and 32-bit formats
that support 8x MSAA. The per-cpp blocksize array is adjusted to also cover
128-byte values for which UBWC has to be disabled anyway.
VK_EXT_sample_locations implementation is adjusted to support sampling in
up to 8 locations, achieved by writing into additional sample location
registers.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32180>
When debugging a game that compiles a ton of shaders at beginning, it
can be very very slow because shaders cache was disabled by default
with RADV_DEBUG=hang.
To make debugging such a game faster, let's cache shaders with
RADV_DEBUG=hang. Note that only the backend IR (ACO or LLVM) and the
disassembly are stored in the cache. To get SPIR-V and NIR, you might
need RADV_DEBUG=hang,nocache.
This also handles the trap handler.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32246>
With Linux kernel 6.12-rc2, crosvm crashes in drm-ci
with the following error,
[ERROR crosvm::sys::linux::panic_hook] thread 'crosvm_vcpu0' panicked at devices/src/virtio/gpu/mod.rs:1761:14:
[ERROR crosvm::sys::linux::panic_hook] failed to send activation resources to worker thread: SendError { .. }
Uprev crosvm to fix this issue.
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31900>
ANB implementation aims to rely as much as possible on 'ANB common' code in vulkan/runtime
and vk_common_* entry points automatically handled by mesa at build time.
(v1) Initial Vulkan HAL skeleton with vk_android_{init,destroy}_ugralloc() in nvk_open_hal()
Changelog:
nvk_android.{c,h}: skeleton nvk_open_hal()/nvk_close_hal() and meson.build changes
nvk_instance.h: nvk_*() functions declaration required by nvk_android.c
nvk_device.c: add ANB support
nvk_image.c: add ANB code paths
nvk_physical_device.c: enable ANB extension support
NOTE: Avoid including any AHB code/headers <vndk/hardware_buffer.h>
use only <vulkan/vk_android_native_buffer.h>
Achievements:
Vulkan HAL is detected by Android build, but no Vulkan application is rendering
Android libvulkan.so loader performs dlopen() of /vendor/lib64/hw/vulkan.nouveau.so
Sascha Willems vulkanCapsViewer App detects the Vulkan HAL in Android builds on RTX2060
Android CTS 11 dEQP-VK can be run and completed, but com.drawelements.deqp app shows black surface
dEQP Test Results:
Module Passed Failed Total
dEQP-VK 568738 161 568899
(v2) Further replication of other using 'ANB common' implementation
Changelog:
Move vk_android_{init,destroy}_ugralloc() from nvk_open_hal() to nvk_CreateInstance()
Remove nvk_GetPhysicalDeviceProperties2() and rely on vk_common_GetPhysicalDeviceProperties2()
Achievements:
Improvements in dEQP-VK test results, but many dEQP.wsi.android.* tests are still failing
dEQP Test Results:
Module Passed Failed Total
dEQP-VK 568783 115 568899
(v3) Get inspiration from lavapipe recent llvmpipe ANB implementation and cleanups
nvk_physical_device.c: brace nvk_init_wsi,nvk_finish_wsi with #ifdef NVK_USE_WSI_PLATFORM/#endif
nvk_image.c: if (!mem) return VK_SUCCESS in DETECT_OS_ANDROID path
nvk_android.h: remove nvk_ahb_format_for_vk_format() and add vk_format_from_android()
Achievements:
Improvement in dEQP.wsi.android.* test results, only dEQP.wsi.android.swapchain.simulae_oom.* are failing.
Most of Vulkan Apps generate these errors in logcat:
... E BufferQueueConsumer: [tech.incr.vulkanandroid/tech.incr.vulkanandroid.MinimalNativeActivity#0](id:85900000010,api:1,p:5060,c:2137) acquireBuffer: max acquired buffer count reached: 2 (max 1)
... E BufferLayerConsumer: [tech.incr.vulkanandroid/tech.incr.vulkanandroid.MinimalNativeActivity#0] updateTexImage: acquire failed: Function not implemented (-38)
while some other apps (vkCube and GearsVK) generate these errors:
... E RenderEngine: failed to wait on fence fd
... E Layer : [Surface(name=Task=136)/@0x832783c - animation-leash#0] No local sync point found
... E Layer : [Surface(name=Task=1)/@0xd82067 - animation-leash#0] No local sync point found
dEQP Test Results:
Module Passed Failed Total
dEQP-VK 568820 79 568899
(v4) Vulkan HAL implement nvk specific ANB gralloc and synchronization, inspired by llvmpipe ANB
Changelog:
nvk_android.c: nvk_GetSwapchainGrallocUsageANDROID, nvk_AcquireImageANDROID, nvk_QueueSignalReleaseImageANDROID
implemented as porting of llvmpipe commit 0dce939e with 's/lvp_/nvk_/g' for functions rename
NOTE: at this stage nvk_GetSwapchainGrallocUsageANDROID is only setting gralloc SW usage flags
nvk_image.h: NVK_MAX_PLANE_COUNT 1 - NOTE: I don' know how many max planes are supported by NVK
Achievements:
GearsVK working
dEQP-VK tests produce colored output on screen
3DMARK API Overhead, Slingshot Extreme: running but meshes are not rendered
Other Vulkan API enabled Android Apps (Sascha Willems vulkanTriangle) are showing black surface,
which is due to basic gralloc SW usage flags implemented in nvk_GetSwapchainGrallocUsageANDROID()
dEQP Test Results:
Module Passed Failed Total
dEQP-VK 568820 79 568899
The failed tests are in the following modules/test:
dEQP-VK.api.driver_properties#driver_id_match 1
dEQP-VK.pipeline.multisample.min_sample_shading_enabled.* 9
dEQP-VK.pipeline.multisample.min_sample_shading.* 56
dEQP-VK.sparse_resources.image_sparse_binding.cube_array.rgba32i#256_256_6 1
dEQP-VK.sparse_resources.image_sparse_binding.cube_array.rgba32ui#256_256_6 1
dEQP-VK.ssbo.layout.random.all_shared_buffer#5 1
dEQP-VK.wsi.android.swapchain.simulate_oom 10
(v5) use ANB common code for GetSwapchainGrallocUsage*ANDROID
Changelog:
Replace the "SW usage only" nvk_GetSwapchainGrallocUsage{,2}ANDROID
and rely on vk_common_GetSwapchainGrallocUsage{,2}ANDROID
Achievements:
Vulkan Apps are rendering on screen
Tested on Android 11 with Vulkan 1.1 API
Android apps working:
Khronos Vulkan-Samples
Sacha Willems Vulkan Examples
Vulkan Android Test
vkCube
GearsVK
PPSSPP
3DMARK API Overhead, Slingshot Extreme - Still with meshes issue
dEQP Test Results:
Module Passed Failed Total
dEQP-VK 568820 79 568899
The failed tests are in the following modules/test (same as per previous iteration):
dEQP-VK.api.driver_properties#driver_id_match 1
dEQP-VK.pipeline.multisample.min_sample_shading_enabled.* 9
dEQP-VK.pipeline.multisample.min_sample_shading.* 56
dEQP-VK.sparse_resources.image_sparse_binding.cube_array.rgba32i#256_256_6 1
dEQP-VK.sparse_resources.image_sparse_binding.cube_array.rgba32ui#256_256_6 1
dEQP-VK.ssbo.layout.random.all_shared_buffer#5 1
dEQP-VK.wsi.android.swapchain.simulate_oom# 10
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30833>
Required to compile nvk for android
Fixes the following building error:
FAILED: src/nouveau/compiler/nak_bindings.rs
...
/usr/include/xf86drm.h:40:10: fatal error: 'drm.h' file not found
panicked at 'Unable to generate bindings: ClangDiagnostic("/usr/include/xf86drm.h:40:10:
fatal error: 'drm.h' file not found\n")', main.rs:52:36
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30833>
On A7XX reading fragment shading rate correctly requires declare
SAMPLEMASK input. It doesn't need to be used anywhere, just declared.
This workaround was seen in the prop driver v512.762.12
Fixes a lot of tests in:
dEQP-VK.fragment_shading_rate.*
Fixes: 2ab8eff511
("tu/a7xx: Implement VK_KHR_fragment_shading_rate")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32335>
FSR with VK_EXT_post_depth_coverage enabled has wrong values of
gl_SampleMaskIn[0]. Prop driver has fragmentShadingRateWithShaderSampleMask
enabled, but it doesn't support VK_EXT_post_depth_coverage.
Sample mask is supplied by HW and there is no flag in sight to fix it.
The failing tests were:
dEQP-VK.pipeline.fast_linked_library.multisample_with_fragment_shading_rate.sample_mask_with_depth_test.samples_2_post_depth_coverage
dEQP-VK.pipeline.fast_linked_library.multisample_with_fragment_shading_rate.sample_mask_with_depth_test.samples_4_post_depth_coverage
dEQP-VK.pipeline.monolithic.multisample_with_fragment_shading_rate.sample_mask_with_depth_test.samples_2_post_depth_coverage
dEQP-VK.pipeline.monolithic.multisample_with_fragment_shading_rate.sample_mask_with_depth_test.samples_4_post_depth_coverage
dEQP-VK.pipeline.pipeline_library.multisample_with_fragment_shading_rate.sample_mask_with_depth_test.samples_2_post_depth_coverage
dEQP-VK.pipeline.pipeline_library.multisample_with_fragment_shading_rate.sample_mask_with_depth_test.samples_4_post_depth_coverage
Fixes: 2ab8eff511
("tu/a7xx: Implement VK_KHR_fragment_shading_rate")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32335>
The Mesa log infrastructure is really useful as it allows us to get
debug and error information in Android systems. Apart from that, it also
allows us to forward diagnostics into the right logs and files.
Therefore, instead of using stderr for all messages, use Mesa log and
separate the messages into debugging and error messages.
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32304>
This commit adds support for incremental rendering on V10+ in PanVK by
setting a tiler out-of-memory exception handler in the fragment subqueue
when waiting for the tiler work to complete.
In case the tiler is unable to finish its work due to lack of memory,
the handler is invoked which will render out the fragment work available
so far, recycle the tiler heap memory and trigger a preload for the
remaining fragment work.
Once the fragment subqueue is made aware that the tiler work has
completed, it will disable the exception handler until the state for the
next renderpass has been set up correctly, as we could otherwise get the
handler invoked based on state from a previous renderpass.
The implementation based on the similar implementation in Panfrost [1],
but works slightly differently due to PanVK utilizing multiple subqueues
and supporting layered rendering.
[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31174
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31941>
Start explicitly passing the pan_fb_info-pointer to use for building
preloads rather than implicitly fetching it from the passed
command_buffer.
This allows building preloads for different fb_infos, which is required
for incremental rendering.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31941>
The pass converts:
...
%.. = load_deref(input)
to:
temp = copy_deref(input) // beginning of the shader
...
%.. = load_deref(temp)
If interp_deref_at_* occurs between copy_deref and load_deref,
the interp_deref_at_* lowering overwrites temp, so all future
load_deref(temp) return the result of interp_deref_at_* instead of
copy_deref, which is incorrect.
The issue manifests when the same input is used by both load_deref
and interp_deref_at_* in the same shader and when interp_deref_at_*
happens to be before load_deref.
This fixes it by using a completely new temporary for each instance
of interp_deref_at_*.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32344>
This imports 35 libdrm_amdgpu functions into Mesa.
The following 15 functions are still in use:
amdgpu_bo_alloc
amdgpu_bo_cpu_map
amdgpu_bo_cpu_unmap
amdgpu_bo_export
amdgpu_bo_free
amdgpu_bo_import
amdgpu_create_bo_from_user_mem
amdgpu_device_deinitialize
amdgpu_device_get_fd
amdgpu_device_initialize
amdgpu_get_marketing_name
amdgpu_query_sw_info
amdgpu_va_get_start_addr
amdgpu_va_range_alloc
amdgpu_va_range_free
We can't import them because they make sure that we only use 1 VMID
per process shared by all APIs. (except the marketing name)
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32067>
Builtin functions do no make use of gl_shader at all other than to store
a symbol table. So lets just create and use the symbol table directly
instead. This will allow us to drop the symbol table member from
gl_shader in the following patch.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32293>
The DETECT_OS_LINUX constant defined in util/detect_os.h allows
replacing the ocurrences of defined(__linux__) and __linux__. They
are equivalent in functionality but the util's one is easier to read and
write. Also it does not require the define() syntax.
The change involve replacing every ocurrence of defined(__linux__) with
DETECT_OS_LINUX. Then replacing every ocurrence of #ifdef __linux__
with #if DETECT_OS_LINUX.
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32286>
The DETECT_OS_FUCHSIA constant defined in util/detect_os.h allows
replacing the ocurrences of defined(__Fushsia__) and __Fuschsia__. They
are equivalent in functionality but the util's one is easier to read and
write. Also it does not require the define() syntax.
The change involve replacing every ocurrence of defined(__Fuchsia__) with
DETECT_OS_FUCHSIA. Then replacing every ocurrence of #ifdef __Fuchsia__
with #if DETECT_OS_FUCHSIA.
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32286>
The DETECT_OS_ANDROID constant defined in util/detect_os.h allows
replacing the ocurrences of defined(__ANDROID__) and __ANDROID__. They are
equivalent in functionality but the util's one is easier to read and
write. Also it does not require the define() syntax.
The change involve replacing every ocurrence of defined(__ANDROID__) with
DETECT_OS_ANDROID. Then replacing every ocurrence of #ifdef __ANDROID__
with #if DETECT_OS_ANDROID.
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32286>
We've supported GL_ARB_transform_feedback3 since 2019,
GL_ARB_draw_indirect and GL_ARB_texture_cube_map_array since 2021.
...you get the picture. There's more, and they've all been around for a
good while. But it seems we forgot to tell features.txt about them.
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32300>
Both of GL_OES_sample_shading and GL_OES_shader_multisample_interpolation
are enabled on panfrost when GL_OES_gpu_shader5 is enabled. And that's
the case on Bifrost and later, but not Midgard.
Let's fix up features.txt to match reality here.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32300>
We always support the extension. Wether we support any formats or not
depends on one of two conditions:
1. If Mesa is built with shader-cache support or not, which is not a
driver decision.
2. If GL_ARB_gl_spirv is supported or not, which is covered elsewhere.
So there's no reason to list individual drivers here, as that doesn't
really change anything.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32300>
When simul_use=true, the tiler descriptors are allocated from
the descriptor ringbuf. We set state.gfx.render.tiler to a
non-NULL value to satisfy the is_tiler_desc_allocated() tests,
but we want it to point to a faulty address so we can easily
detect if it's used in the command stream/framebuffer
descriptors.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32213>
Fix cross command buffer render pass suspend/resume by
emitting a render context (tiler+framebuffer descriptors)
on suspend that we can re-use on resume.
This involves splitting the issue_fragment_jobs() logic to
decouple the framebuffer descriptor initialization and the
run_fragment emission. This also requires patching a few
places where we were testing the tiler/fbd values to
determine if we are in a render pass, which no longer works
when a render pass is resumed.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32213>
We don't need to check anymore if this was already applied and it turned
out the check was not working properly in the first place.
The check for vs is kept in place, because that one still detects that
few wine shaders already have the sin/cos input in correct range.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32160>
finalize_nir requires that calling it multiple times on the same shader
doesn't break it.
RV530 shader-db:
total instructions in shared programs: 132915 -> 132851 (-0.05%)
instructions in affected programs: 2016 -> 1952 (-3.17%)
helped: 16
HURT: 0
total temps in shared programs: 18238 -> 18232 (-0.03%)
temps in affected programs: 42 -> 36 (-14.29%)
helped: 6
HURT: 0
total cycles in shared programs: 197510 -> 197446 (-0.03%)
cycles in affected programs: 2102 -> 2038 (-3.04%)
helped: 16
HURT: 0
Reviewed-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32160>
When dealing with AFBC render targets using wide blocks, the GPU needs to
keep rendering tiles that are a multiple of 16x16. This is described
as AFBC render block size, and adds extra constraints:
- render target buffers need to be aligned on 16 pixels in the vertical
direction, even if the AFBC super block size is 4 or 8 pixels.
- if the effective tile size is smaller than the render block size, we
should force a clean write and discard+ignore the CRC
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31948>
This allows using the tile size to make decisions not related to the
framebuffer descriptor. Mainly, for the near future, to decide
whether some tiling hierarchy levels should be disabled.
The color buffer allocation size is also calculated at the same time
as it's using common data underneath.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31948>
In certain cases, the hardware fails to properly process a mipmap level
of these special stencil and depth formats. This happens at width=16.
This change adds a software workaround.
Modifying the corresponding mipmap nblk_x, and the other related
values, could make the tests below to work. Anyway, this method
generates regressions.
This change was tested on palm and cayman and fixes the following tests:
spec/arb_framebuffer_object/framebuffer-blit-levels read stencil: fail pass
spec/arb_depth_buffer_float/fbo-clear-formats stencil/gl_depth32f_stencil8: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31957>
This situation is happening, for instance, when the hardware is
using the type FMT_8_8_8_8 (4 bytes) while the software was
requesting a 3 bytes type. The width should be adjusted to the
expected hardware size; otherwise, the last vertex is lost.
Note: The rv770 didn't behave like this. This is definitely
a hardware change between these gpus.
This change was tested on palm and cayman. Here are the tests fixed:
spec/!opengl 2.0/gl-2.0-vertexattribpointer-size-3: fail pass
deqp-gles2/functional/draw/random/62: fail pass
deqp-gles2/functional/vertex_arrays/single_attribute/strides/buffer_0_32_byte3_vec4_dynamic_draw_quads_1: fail pass
deqp-gles2/functional/vertex_arrays/single_attribute/strides/buffer_0_32_short3_vec4_dynamic_draw_quads_1: fail pass
deqp-gles2/functional/vertex_arrays/single_attribute/strides/buffer_0_32_short3_vec4_dynamic_draw_quads_256: fail pass
deqp-gles3/functional/draw/random/117: fail pass
deqp-gles3/functional/vertex_arrays/single_attribute/strides/byte/buffer_stride32_components3_quads1: fail pass
deqp-gles3/functional/vertex_arrays/single_attribute/strides/short/buffer_stride32_components3_quads1: fail pass
deqp-gles3/functional/vertex_arrays/single_attribute/strides/short/buffer_stride32_components3_quads256: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32184>
This change fixes the evergreen nonconformity issue on non-mipmap
textures when the minification and the magnification are not in
the same state.
This modification disables 5278436d67 when the minification and
the magnification are different. This fixes the nonconformity
without new regressions. Anyway, I was unable to reproduce
the issue described by 5278436d67 on palm and cayman.
This change was tested on cayman and palm. It fixes 84 deqp-gles2
tests and 128 deqp-gles3 tests:
deqp-gles2/functional/texture/filtering/2d/linear_nearest_*
deqp-gles2/functional/texture/filtering/2d/nearest_linear_*
deqp-gles2/functional/texture/filtering/cube/linear_nearest_*
deqp-gles2/functional/texture/filtering/cube/nearest_linear_*
deqp-gles2/functional/texture/vertex/2d/filtering/linear_nearest_*
deqp-gles2/functional/texture/vertex/2d/filtering/nearest_linear_*
deqp-gles2/functional/texture/vertex/cube/filtering/linear_nearest_*
deqp-gles2/functional/texture/vertex/cube/filtering/nearest_linear_*
deqp-gles3/functional/texture/filtering/2d/combinations/linear_nearest_*
deqp-gles3/functional/texture/filtering/2d/combinations/nearest_linear_*
deqp-gles3/functional/texture/filtering/2d_array/combinations/linear_nearest_*
deqp-gles3/functional/texture/filtering/2d_array/combinations/nearest_linear_*
deqp-gles3/functional/texture/filtering/3d/combinations/linear_nearest_*
deqp-gles3/functional/texture/filtering/3d/combinations/nearest_linear_*
deqp-gles3/functional/texture/filtering/cube/combinations/linear_nearest_*
deqp-gles3/functional/texture/filtering/cube/combinations/nearest_linear_*
deqp-gles3/functional/texture/vertex/2d/filtering/linear_nearest_*
deqp-gles3/functional/texture/vertex/2d/filtering/nearest_linear_*
deqp-gles3/functional/texture/vertex/2d_array/filtering/linear_nearest_*
deqp-gles3/functional/texture/vertex/2d_array/filtering/nearest_linear_*
deqp-gles3/functional/texture/vertex/3d/filtering/linear_nearest_*
deqp-gles3/functional/texture/vertex/3d/filtering/nearest_linear_*
deqp-gles3/functional/texture/vertex/cube/filtering/linear_nearest_*
deqp-gles3/functional/texture/vertex/cube/filtering/nearest_linear_*
Fixes: 5278436d67 ("r600: force LOD range to be only one value when mip.min filter is NONE")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32185>
On evergreen depth-stencil textures are allocated as two objects, and
when using the eg_surface_init_1d_miptrees code path the size evaluation
uses the generalized surf_minify function. Here when allocating the
depth texture the alignment takes the depth bpe value into account, and
uses bpe=1 for the stencil texture. As a result the texture pair may
consist of textures with two different nblk_x sizes and this seems to
be a problem with some textures, namely npot and small (width < 32), but
not for mipmapped textures. In the problematic cases, if the so allocated
depth texture is larger than the stencil texture, then the kernel may reject
sent data with an error message like:
evergreen_cs_track_validate_stencil:622 stencil read bo too
small (layer size 131072, offset 524288, max layer 1, bo size 606208)
- because apparently the expected layer size is evaluated from the depth
texture size, but the actual bo size is evaluated based on the true texture
size values. If, on the other hand, the stencil texture is larger than the
depth texture, then the data is send with a wrong alignment, and certain
dEQP-GLES31 tests fail.
In order to obtain equal texture sizes in the problematic cases magnify
the depth texture alignment requirement by its bpe, so that the relative
alignment is the same for depth and stencil texture.
Fixes:
dEQP-GLES31.functional.stencil_texturing.format
.depth32f_stencil8_2d
.depth32f_stencil8_2d_array
.depth24_stencil8_2d
.depth24_stencil8_2d_array
.stencil_index8_2d
.stencil_index8_2d_array
.depth32f_stencil8_draw
.depth24_stencil8_draw
dEQP-GLES31.functional.texture.border_clamp.formats
.stencil_index8.nearest_size_npot
.depth24_stencil8_sample_stencil.nearest_size_npot
.depth32f_stencil8_sample_stencil.nearest_size_npot
dEQP-GLES31.functional.texture.border_clamp.per_axis_wrap_mode.texture_2d
.uint_stencil.nearest.s_clamp_to_edge_t_clamp_to_border_npot
.uint_stencil.nearest.s_repeat_t_clamp_to_border_npot
.uint_stencil.nearest.s_mirrored_repeat_t_clamp_to_border_npot
piglits:
arb_framebuffer_object-depth-stencil-blit *stencil*
framebuffer-blit-levels draw stencil
arb_texture_stencil8/
texwrap formats offset/gl_stencil_index8, npot
texwrap formats/gl_stencil_index8, npot
ext_framebuffer_multisample
accuracy all_samples stencil_resolve small depthstencil
unaligned-blit * stencil downsample
ext_texture_array/fbo-depth-array *stencil
egl_khr_gl_renderbuffer_image-clear-shared-image gl_depth_component24
v2: use util_is_power_of_two_or_zero (Marek)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32169>
I don't know of any case of Apple's driver using this, but it seems to work. The
stream link bit is identical to VDM so that was easy, the tricky part was the
return but I bruteforced the encoding space and this is the (only) thing that
worked. So add the XML.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32320>
can help a lot for scratchy shaders. affected shader is a compute shader in
graphics bench.
total instructions in shared programs: 2751334 -> 2750950 (-0.01%)
instructions in affected programs: 4308 -> 3924 (-8.91%)
helped: 2
HURT: 0
total bytes in shared programs: 21482512 -> 21480592 (<.01%)
bytes in affected programs: 27448 -> 25528 (-7.00%)
helped: 2
HURT: 0
total fills in shared programs: 732 -> 540 (-26.23%)
fills in affected programs: 396 -> 204 (-48.48%)
helped: 2
HURT: 0
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32320>
This is a small command line utility to generate NIR bindings for a SPIR-V
library, using vtn's infrastructure for this. This is split out from asahi_clc
in an effort to make clc more modular. Notably, this tool does not depend on:
* LLVM, SPIRV-LLVM, CLC, etc (important for Android, and gets us closer to the
clang spir-v future)
* Driver details other than addressing modes (which are already largely
hardcoded, setting them to anything else doesn't make a ton of sense for CL C)
* The driver itself, or its backend compiler. That means that the backend
compiler can depend on the generated bindings header, even if the compiler is
also used for internal shader precompiling. This breaks the dep loop.
So in short term, this solves the dependency problem for asahi, and in the long
term helps more drivers use clc infrastructure without re-rolling things
themselves.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32226>
These fields are only valid in certain formats, so set them accordingly.
Note the check if !is_send is used because FORMAT_BASIC is reused for
SEND/SENDS in some platforms. If we start to see more cases like that,
we can create a new FORMAT for it.
The cond_modifier is trickier because on top of that, it is not valid
for 64-bit immediates in some platforms. Found when EU validation
complained about moving 64-bit immediates with higher bits.
Fixes: e4440df2d8 ("intel/brw: Add pred/cmod/sat to brw_hw_decoded_inst")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32287>
When we create a new swapchain to replace the one currently presenting on
a surface, we need to reset all these timing variables. Otherwise we can
lose track of corrections that were made for the old swapchain when we
delete undelivered presentation feedback results.
Also, we use these variables when queuing a presentation, but we also use
them in the dispatch code that can be called by WaitForPresent from another
thread. We need to protect these variables against concurrent usage.
This is all much easier to do when they're stored as part of the swapchain
instead of the surface, so just move them there and adjust the locking.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Fixes: c26ab1aee1 ("vulkan/wsi/wayland: Pace frames with commit-timing-v1")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32121>
When we start using timestamps, the current code will generate an event
stream like:
feedback
set barrier
wait barrier
commit
feedback
set timestamp
set barrier
commit
wait barrier
commit
The second content update can cause the feedback request from the first to
send a discarded event if the timestamp is in the past.
Be less clever and just put waits in both our content updates.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Fixes: c26ab1aee1 ("vulkan/wsi/wayland: Pace frames with commit-timing-v1")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32121>
When occluded, the current math always rounds down to 0 cycles and leads
to improperly throttled frame delivery.
Improve the comment, and use a formula that leads to generating future
times even when occluded.
Also remove some dead code, as we can never get here with a period of 0.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Fixes: c26ab1aee1 ("vulkan/wsi/wayland: Pace frames with commit-timing-v1")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32121>
Update just enough of the fail list to have a green CI. I'm sure a
no-fraction run would uncover other improvements/failures/flakes, but
the goal here is to detect improvements/regressions introduced by new
MRs, not to make the list accurate. This will be tackled in a follow-up
MR.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32302>
We assume everywhere that RGB is not planar, so sampling
and color space conversions will not work correctly with RGBP.
Drivers can still support RGBP, but processing entrypoint with
shaders doesn't support it.
Fixes: bdb7f36aa8 ("frontends/va: add support for RGBP rt_format")
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32252>
This matches the supported formats we query for in config attributes.
Also prefer YUY2 over YUYV (identical formats), as YUY2 has a VA_FOURCC_YUY2
definition and some applications will only try to use this fourcc code.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32252>
I did half the job in that commit: I split the two apis into two
invocations, but I didn't fix the binary used for the gles one...
Fixes: 14279087fb ("ci/deqp-runner: split gl & gles groups to use the correct binary")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32250>
Currently if you try to probe the virtio ICD on a non-virtio system
it will fail in CreateInstance which causes the loader to spit on the
screen.
However instance creation shouldn't fail, the driver should just
not enumerate any devices in this case. It's a bit tricky to ensure
this, but return instance and then handle instance destruction
and fail device enumeration.
Cc: mesa-stable
Reviewed-by: Ryan Neph
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32266>
Create a CS which contains just a cache flush,
that can be used as a postamble in command submissions.
According to RadeonSI code, the kernel flushes L2
before shaders are finished on GFX6.
Previously, RADV always added a flush at the end of
each command buffer. The flush postamble should be
a less wasteful alternative to that.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31695>
- A650+ - should be able to support pipelineFragmentShadingRate
but in some other way than A7XX. Not implemented here.
- A7XX - support pipelineFragmentShadingRate and attachmentFragmentShadingRate
- A740+ - support primitiveFragmentShadingRate
layeredShadingRateAttachments is unsupported at the moment due to tests
failure, but prop driver supports it.
Passes:
dEQP-VK.fragment_shading_rate.*
On A750/A740
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30905>
Raspberry Pi 5 has different drivers for different types of connectors.
For example, HDMI connections are handled through vc4, but DSI
connections are handled through drm-rp1-dsi.
Currently, we only allow vc4 as display driver, which means that, when
we use VK_KHR_display with a DSI display, we won't get any available
displays.
In order to make sure we have available displays when using DSI/DPI/VEC
displays, enumerate all DRM primary nodes and use the first fd that has
a connected output. For example, in the case we have only a DSI display
connected to the RPi 5, it will pick the drm-rp1-dsi as the device. In
the case we have both DSI and HDMI displays connected, it will pick the
first fd that it checks.
Ideally, we would like to see all displays available in the return of
`vkGetPhysicalDeviceDisplayProperties2KHR`, but `wsi->fd` is a variable,
not an array. Therefore, it only supports one fd.
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32123>
Protocol version 3 used host side resource IDs that may be reused.
Because with older host versions index-buffer binding may go wrong
in this case, we have to check whether the host vrend version is
actually ready for protocol version 3, and if not we re-negotiate
the protocol version only allowing up to version 2.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31624>
There's no reason to calculate this more closely; the Vulkan spec
explicitly allows for it to be conservative. And there's no other Vulkan
driver in Mesa that currently does anything else.
But, we have another reason to limit to this specific value (which also
happens to be the minimum value allowed by the spec); we'll overflow the
32-bits of slice_stride for resources where the product of width, height
and texel-size is over UINT32_MAX. But with this limit in place, we
avoid this.
This limit will go away in v11, beacuse there's an additional five bits
of slice_stride there. But let's leave that for later.
Anyway, let's document why this is the correct limit, insted of having
the FINISHME-comment.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: John Anthony <john.anthony@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32265>
Panvk currently enables VK_EXT_vertex_attribute_divisor, but Mali HW
does not support a non-zero firstInstance when a divisor is used.
supportsNonZeroFirstInstance is correctly set to false to advertise
this, however this property was only added when the extension was
promoted. Thus we need to remove support for
VK_EXT_vertex_attribute_divisor and enable
VK_KHR_vertex_attribute_divisor instead.
Also fixes an issue with non-zero divisor for v10.
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32137>
Sets the default exit code to 1 to ensure the GitLab job fails when the
LAVA job fails or is interrupted. Adds tests to verify the exit code is
correctly set based on the logs or the lack of them (unexpected
finishing: timeouts and canceling).
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32163>
This reverts commit 46bf687882.
We wont be removing this lowering file and having this workaround in
glsl_to_nir() creates a dependency on the const values that we could
otherwise avoid, so lets just move this back. Dropping the consts
will be useful in a follow up series that aims to drop all the glsl
ir function inlining code by converting builtin functions to nir.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32239>
Instead of using unreliable polling to wait for foz db updater to parse
and load from the dynamic list, also use inotify to wait for foz db
updater close the list file after its done updating.
Fixes: 4dfd306454 ("disk_cache: Disable the "List" test for RO disk cache.")
Signed-off-by: Juston Li <justonli@google.com>
Reviewed-by: David Heidelberg <david@ixit.cz>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32237>
It doesn't enable back face culling and small line culling. Those can only
be enabled for monolithic shaders. It only enables view culling and small
triangle culling.
Doing this has these minor advantages:
1. We can enable at least some culling immediately instead of when the first
monolithic shader finishes compilation.
2. If back face culling and clip planes are disabled, we no longer compile
monolithic TES and GS shader variants to get only view culling and small
triangle culling.
3. shader-db will show culling code changes for TES and GS.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32257>
For a TU_PIPELINE_GRAPHICS_LIB we were taking a ref to the descriptor
set layout but never releasing on VK_PIPELINE_COMPILE_REQUIRED.
Since VK_PIPELINE_COMPILE_REQUIRED is technically an error, the user
doesn't call vkDestroyPipeline() for it so the descriptor sets
referenced were never getting freed.
Addresses:
```
Direct leak of 304 byte(s) in 1 object(s) allocated from:
#0 0x7fa5a93ee0 in __interceptor_malloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fa44bac84 in vk_default_alloc ../src/vulkan/util/vk_alloc.c:26
#2 0x7fa32ea5d8 in vk_alloc ../src/vulkan/util/vk_alloc.h:48
#3 0x7fa32ea60c in vk_zalloc ../src/vulkan/util/vk_alloc.h:56
#4 0x7fa32ea750 in vk_descriptor_set_layout_zalloc
../src/vulkan/runtime/vk_descriptor_set_layout.c:49
#5 0x7fa306fc98 in tu_CreateDescriptorSetLayout(VkDevice_T*,
VkDescriptorSetLayoutCreateInfo const*, VkAllocationCallbacks
const*, VkDescriptorSetLayout_T**)
../src/freedreno/vulkan/tu_descriptor_set.cc:161
```
and
```
Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0x7f9b4b3ee0 in __interceptor_malloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7f9925e900 in ralloc_size ../src/util/ralloc.c:118
#2 0x7f9925e8d4 in ralloc_context ../src/util/ralloc.c:105
#3 0x7f98b4b214 in tu_pipeline_builder_build<(chip)7>
../src/freedreno/vulkan/tu_pipeline.cc:3898
#4 0x7f98b46bd8 in tu_graphics_pipeline_create<(chip)7>
../src/freedreno/vulkan/tu_pipeline.cc:4203
#5 0x7f98b22588 in VkResult
tu_CreateGraphicsPipelines<(chip)7>(VkDevice_T*,
VkPipelineCache_T*, unsigned int, VkGraphicsPipelineCreateInfo const*,
VkAllocationCallbacks const*, VkPipeline_T**)
../src/freedreno/vulkan/tu_pipeline.cc:4234
```
seen in:
dEQP-VK.pipeline.pipeline_library.shader_module_identifier.pipeline_from_id.graphics.4_variants.no_spec_constants.no_pipeline_cache.all_zeros_id.no_exec_properties.vert_tesc_tese_frag
Cc: mesa-stable
Signed-off-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32188>
Combination of concurrent resolve groups and generic clear support on a750
exposed a problem around color and depth/stencil clears. With all resolves
now non-blocking in nature, we need a guarantee that clears issued through
commands will complete before any future resolves.
To achieve that, in case of generic clears being used, a cache flush is
done in order to generate the CCU_RESOLVE_CLEAN event that will ensure any
future resolve will block until the just-emitted clears are completed.
Fixes following flaky CTS tests on a750:
dEQP-VK.pipeline.monolithic.framebuffer_attachment.2d_array_32x32_48x48_4_ms
dEQP-VK.pipeline.pipeline_library.framebuffer_attachment.2d_array_32x32_48x48_4_ms
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Fixes: 25b73dff5a ("tu/a7xx: use concurrent resolve groups")
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32242>
rip the pan_tristate enum from panfrost and move it to common.
I've often wanted some sort of "yes/no/maybe" or "true/false/unknown" or
"always/never/sometimes" data structure. This adds a common one that is
hopefully neutral enough to cover all of the above.
Asahi will use this.
The Intel drivers could be ported to this (brw_sometimes/elk_sometimes), it
should be straightforward but I don't want to do that without being able to
easily test those changes.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32224>
It doesn't feel great that we need to compile multiple identical shaders
just because we're going to toggle a bit in the command-stream, but this
seems to be the current state-of-art in mesa, so hmpf...
It makes state-validation trivial, so there's that.
This is loosely based on what NVK does.
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32004>
Use TfLiteDepthwiseConvParams for kTfLiteBuiltinDepthwiseConv2d.
The layout of stride_width, stride_height, and padding struct members
happens to be the same, but we shouldn't depend on that.
This prepares for using the activation, dilation_width_factor, and
dilation_height_factor members, which are at different offsets.
Reviewed-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31981>
The BO list member isn't the head/entrypoint for a list, but is only
to be used to link the BO in various lists, so it should not be
initialized as a list head.
Now that the member is properly NULL initialized, we can use the
proper list_is_linked() function to check if the BO is on any
cache bucket or the zombie list.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32233>
Also ensure that 'needs_scratch_reg' is always true if SCC might be overwritten.
Few changes, because some p_split_vector get SCC as scratch reg assigned,
and thus, can inhibit some postRA optimizations.
Totals from 3 (0.00% of 79395) affected shaders: (Navi31)
Instrs: 10501 -> 10500 (-0.01%); split: -0.02%, +0.01%
CodeSize: 51580 -> 51520 (-0.12%); split: -0.12%, +0.01%
Latency: 84166 -> 84174 (+0.01%)
InvThroughput: 13109 -> 13111 (+0.02%)
SALU: 859 -> 860 (+0.12%)
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32217>
This was just broken because individual shaders were still stored
on-disk in many situations:
- for shader object, all compute/graphics shaders were stored
- for fast-GPL, graphics shaders were stored
- for pipeline binaries, when the create flag was used
- for rt capture/replay and ray history
This should stop storing unused binaries on-disk and save space.
Found this by inspection.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32227>
We updated maxImageDimension2D etc to report the actual max size, but we
forgot to update GetPhysicalDeviceImageFormatProperties in the same way.
Let's do that to make things consistent.
This fixes the following CTS test-case:
dEQP-VK.wsi.wayland.swapchain.create.image_extent
Fixes: d5ed77800e ("panvk: Fix GetPhysicalDeviceProperties2() to report accurate info")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32221>
On modern Mali GPUs, we can have 16 bits for the X and Y sizes, already
overflowing 32-bit barrier even with a single layer of byte-sized
formats.
So let's make sure we have enough bits to avoid overflows here.
Fixes: d5ed77800e ("panvk: Fix GetPhysicalDeviceProperties2() to report accurate info")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32221>
There is no good reason to use interlaced surfaces when progressive
is supported and it only creates issues when exporting the surface
or trying to do transcoding.
This allows to remove all workarounds that handled reallocating
from interlaced to progressive because a given operation would not
work for interlaced.
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32095>
No functional change, just move i915 specific data to a struct
and check for kmd_type where appropriate. This will make the
next patch (which adds Xe KMD support here) cleaner.
This patch had to make intel_kmd.h header C++ friendly so it
can use its symbols.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32194>
deqp-runner version is 0.20.2 already. But we would like to keep
MESA_VK_ABORT_ON_DEVICE_LOSS globally because, without it, after the
first VK_ERROR_DEVICE_LOST in a test group, the error is sticky and the
remaining tests will be considered failed as well.
deqp-vk gained --deqp-terminate-on-device-lost since 1.3.8.0 and enabled
it by default since 1.3.10.0. But let's prefer our own mechanism.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32228>
The meaning is negated.
This NIR option is deprecated and shouldn't be used. It means any IO
optimizations can be disabled and it's a currently a workaround for zink,
which is the only driver that asks for it by default. The original option
is replaced by an environment variable for the GLSL linker.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32173>
If we have NIR such as:
32x4 %48 = @load_vulkan_descriptor (%47) (desc_type=SSBO)
32x4 %76 = deref_cast (tint_symbol_11 *)%48 (ssbo tint_symbol_11) (ptr_stride=0, align_mul=4, align_offset=0)
32x4 %77 = deref_struct &%76->tint_symbol_10 (ssbo int) // &((tint_symbol_11 *)%48)->tint_symbol_10
A single nir_rematerialize_deref_in_use_blocks() will rematerialize the
deref_struct and then it's deref_cast. However,
nir_foreach_instr_reverse_safe is not safe if the next iteration's
instruction is removed. This can result in the instruction loop exiting
and the load_vulkan_descriptor never having an LCSSA phi.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Fixes: 439e8c42cc ("nir/lcssa: Fix rematerializing derefs")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11770
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32225>
This was needed because of the issue with using NV12 regardless
of RT format that was fixed in previous commit.
There was a special case for AV1, because AV1 Profile 0 supports
both 8 and 10 bit, but this is also not needed anymore.
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32089>
If applications doesn't send any attributes to describe the format,
we would always use driver preferred format (NV12). This is wrong
for any RT format other than the driver preferred (YUV420).
Driver doesn't have a choice here, we must use the matching format.
Cc: mesa-stable
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32089>
The code wants the number of components used by the variable in the
current attribute slot, not the total number of components.
For e.g. a 4x3 matrix, glsl_get_components() returns 12, leading to the
following error reported by AddressSanitizer:
```
Test case 'dEQP-VK.tessellation.shader_input_output.cross_invocation_per_patch_mat4x3'..
../src/compiler/nir/nir_lower_io_to_vector.c:265:16: runtime error: index 4 out of bounds for type 'nir_variable *[4]'
```
Fixes: 5ef2b8f1f2 ("nir: Add a pass for lowering IO back to vector when possible")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32193>
assert(!shader->key.ps.part.prolog.force_persp_center_interp ||
(!G_0286CC_PERSP_SAMPLE_ENA(input_ena) && !G_0286CC_PERSP_CENTROID_ENA(input_ena)));
failed when all FS inputs have been eliminated by optimizations, which
causes LLVM to set PERSP_SAMPLE_ENA because at least 1 of those must be
enabled, which this code didn't expect.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32186>
The semantics of this newly introduced system value match
Vulkan's InstanceIndex exactly, and are equivalent to
instance_id + base_instance.
Some hardware, such as Mali Valhall or later, only provides
instance id offset by base_instance. Introducing a new system
value to represent this, rather than handling the mismatch
when lowering to BIR lets us use NIR to eliminate redundant
arithmetic that would follow from mismatched semantics, e.g.
instance_id could be lowered to instance_index - base_instance,
so expressions such as instance_id + base_instance would be
optimized to a simple instance_index.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32158>
The game aliases two images. It binds a memory object to two different
images, the first one being an image with 4 mips and the second with
only one mip but the bind offset is incorrect. It's like it queried
the first image size with different usage flags, so that DCC was
disabled.
Force disabling DCC for mips fixes the incorrect rendering and doesn't
hurt performance.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10200
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32190>
There are new combinations of ordered and unordered dependencies
available for the instructions to use, which among others include:
- combining FLOAT and INT pipe deps in SENDs;
- combining SRC mode deps in regular instructions for the inferred type.
This patch enables a couple of tests checking for the first case.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31375>
A recent algebraic opt made a function that used to inline
with llvmpipe CL not inline anymore. However that function
has a barrier in it.
Handling barriers from inside a callstack is hard for llvmpipe
coroutines, so just force functions with barriers to be inlined.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32204>
The spec says that the user-specified srcStageMask/srcAccessMask should
be ignored for the acquire operation and the user-specified
dstStageMask/dstAccessMask should be ignored for the release operation.
Since we don't need any special handling for VK_QUEUE_FAMILY_EXTERNAL,
override them to NONE.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32164>
In two functions implementing resource discard rebind_resource is called
on resource before its track record is reset. This prevents update of
dirty_resource or dirty_shader_resource because of conditions in
needs_dirty_resource. With rsc->track reset and dirty_resource bits
missing further calls to transfer_map will not try to reallocate
resource storage when needed.
A way to reproduce the issue in both functions is by executing at least
3 draws modifying bound texture or VBO each time. This patch fixes those
cases and some related piglit tests on a5xx and should fix it on other
GPUs. Also it fixes rendering in Firefox and vsraytrace (except vertical
line at right edge).
Fixes: 0a62a874fc ("freedreno: Re-work dirty-resource tracking")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10374
Reviewed-by: Rob Clark <robclark@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32167>
Many debug flags influence shader codegen but are currently not included
in the hash key. This causes surprising effects as cache lookups may
return shaders compiled with different debug flags than currently in
effect. This patch fixes this by including all debug flags in the
shader hash key.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: c323848b0b ("ir3, tu: Plumb through support for per-shader robustness")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32052>
This is mostly a developer preference issue. Some Android
devs like to commit auto-generated files for ${reasons},
though the style of Mesa is not to do so.
I personally like the Mesa style, since otherwise a 25 million
LoC project would be 40 million, but whatever.
An easy solution to just to check them in AOSP Mesa, but not
in upstream. There are various mechanisms, particularly
auto-rollers, that enable this. For example, there is no plan to
check in Blueprint files upstream, but they will be checked-in
and committed by the auto-roller.
For the scheme to work, we'll need slightly different meson
rules when the build target is Android versus otherwise.
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32148>
Removed a function that creates anonymous file descriptors when called.
Additionally replaced a call of said function with the one from the "util"
directory. The intention is to avoid repeated functionality
util: Allow code to be compatible in c++ compilers
Added an extern "C" statement and preprocessor directives to make the
“os_create_anonymous_file” function compatible with c++ compilers
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32096>
Prevents the next patch from failing CTS tests such as:
dEQP-VK.api.image_clearing.core.clear_color_image.*.b4g4r4a4*
Brings back the feature that was introduced in commit 46187bb54f
("anv: Swizzle fast-clear values"), but went unused in commit
721d0c3e77 ("anv,hasvk: Always use BLORP_BATCH_NO_UPDATE_CLEAR_COLOR").
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32187>
We're going to drop a generic restriction on clear color conversions in
anv_can_fast_clear_color(). Without preparing for it, the following
tests would fail:
* piglit.spec.arb_framebuffer_srgb.blit texture srgb msaa disabled clear.gen9_zinkm64
* piglit.spec.arb_framebuffer_srgb.blit renderbuffer srgb msaa disabled clear.gen9_zinkm64
* piglit.spec.arb_framebuffer_srgb.blit texture srgb downsample enabled clear.gen9_zinkm64
* piglit.spec.arb_framebuffer_srgb.blit renderbuffer srgb downsample enabled clear.gen9_zinkm64
* piglit.spec.arb_framebuffer_srgb.blit renderbuffer srgb msaa enabled clear.gen9_zinkm64
* piglit.spec.arb_framebuffer_srgb.blit texture srgb msaa enabled clear.gen9_zinkm64
So, add support for sRGB sampling via BLORP transfer operations and drop
the gfx9-specific restriction on sRGB fast-clears.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32187>
We have to honor drivers when they say that different interpolation
qualifiers can't be mixed in the same vec4, indicated by
nir_io_has_flexible_input_interpolation_except_flat not being set.
This is a prerequisite for enabling nir_opt_varyings for all drivers.
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32174>
The main difference between load_global and load_global_constant is that
the latter can be reordered arbitrarily. If the access being lowered is
already tagged as being reorderable, then we can preserve that by using
the load_global_constant intrinsics instead of load_global. This gives
us more flexibility.
On Intel, this lets us use the load_global_constant_uniform_block_intel
intrinsic for doing convergent block loads in more cases. This nets us
significant reductions in spill/fills: Borderlands 3 on Lunarlake sees
spills/fills reduced by 53%. Alchemist sees a 13% reduction.
Improves performance of Borderlands 3 DX12 on Intel Battlemage by
around 44%. Improves Hogwarts Legacy by around 14%.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31995>
We were accidentally doing a signed integer comparison here for ult32,
or a sign-extending shift for ushr.
One notable bit of fallout was that load_global_uniform_block_intel
address calculations broke on platforms that don't have native 64-bit
integer support, as the iadd64 lowering for "do I need to carry?" was
using ult32...and performing the wrong comparison. We spotted this in
Borderlands 3 on Alchemist once we turned on other optimizations.
Thanks to Lionel Landwerlin for helping spot the problem!
Fixes: c7b312ad45 ("brw: factor out source extraction for rematerialization")
Fixes: 339630ab05 ("brw: enable A64 loads source rematerialization")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31995>
This was triggering an assertion in the fs_builder::MOV helper that
the destination stride can't be 0 when dispatch_width > 1. What we
want to do is copy the single 64-bit channel of data from the UNIFORM
file to a VGRF. We can use a SIMD1 builder for that.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31995>
Previously, double-buffer mode would apply to all jobs except msaa,
but this is not smart, since not all jobs can benefit from this. In
particular, if jobs load the tile buffer and don't store tiles
double buffer mode won't be effective and we would instead pay the
cost of the smaller tile size so we only want to enable in jobs
that meet these requirements.
In order to achieve this we need to postpone the decision about
double buffering until we know the loads and stores of the job,
which means we need to do this late after we have recorded draws.
This means that by default, we assume no double-buffer mode is
used and if we find we want to enable after emitting the draws
we need to re-compute tile sizes and rewrite the
TILE_BINNING_MODE_CFG packet accordingly.
Making the decison about double-buffer late will also enable us to
add heuristics to decide about double-buffer based on the draw calls
emitted in the job, but we will do this in a separate patch.
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32111>
We want to make the decision about double-buffer enablement much later
when we have enough information to make it. That means we might need
to rewrite this packet, so we need to save a pointer to its location
in the CL.
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32111>
By restricting these limitations up to GFX 12, CCS support
can be present on these cases that we think Xe2+ platform
should support compression.
Noticeably, CCS is allowed on depth resources without HiZ,
multi-sampled resources without CCS, and multi-sampled
stencil resources.
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31496>
Two aux functions are updated to fix piglit test once CCS is enabled on
multi-sampled stencil resources in a following change. As reviewers
suggested, we don't see much value of the assertion.
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31496#note_2601233
Piglit test:
fbo-depthstencil blit default_fb -samples=16 -auto
iris_resolve.c:972: iris_resource_get_aux_state: Assertion
`res->surf.samples == 1 || res->surf.msaa_layout == ISL_MSAA_LAYOUT_ARRAY' failed.
iris_resolve.c:996: iris_resource_set_aux_state: Assertion
`res->surf.samples == 1 || res->surf.msaa_layout == ISL_MSAA_LAYOUT_ARRAY' failed.
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31496>
Using intel_needs_workaround() within a block of GFX version
checker requires extra carefulness on the road because both
of them specify a range of applicable platforms. The WA block
can be unexpectedly skipped once the GFX version checker gets
updated later.
Moving the WA implementation out of the GFX block to decouple
them for more clarity and less chance of messing up next time.
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31496>
If nir_tcs_info::all_invocations_define_tess_levels is true, the pass
doesn't have to insert a barrier and use output loads to get tess level
output values. It can just use the SSA defs that are being stored (or phis
thereof) to get the tess level output values.
The remaining tcs_info fields will be used by the HS shader message.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32171>
Separate KIL counts to the indirection limit, so try to schedule it
within the TEX block on R300/R400, except for small shaders, where we
already know we are fine.
42 gained shaders on R400 (40 Trine and 2 This war of mine) at the
expense of some increase in register pressure.
shader-db:
total temps in shared programs: 18107 -> 18129 (0.12%)
temps in affected programs: 262 -> 284 (8.40%)
helped: 0
HURT: 22
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32023>
It is an easy way to check that the installation works and is in a
useful state.
The Python script is based on a example in the TensorFlow repository at:
tensorflow/lite/examples/python/label_image.py
The labels file is distributed by Google along the MobileNetV1 model
that we already have. These files are released under the Apache
license.
Reported-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Tested-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Acked-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31860>
Operations other than tensor addition will also need to be able to
handle multiple inputs, and a variable number of them.
And for testing individual operations, we also need to support models
with multiple inputs.
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32105>
When IDVS+malloc is used, there's no linking involved (getting the
VS and FS shaders to agree on the varyings attributes), so we can
purely and simply skip this phase.
If we ever have to support the non-malloc or non-IDVS case, we'll need
to revisit the linking logic anyway, so let's kill the linking on v10
for now.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31911>
We're about to bitset-based driver-internal dirty state tracking, and
we'll need to define new xx_is_dirty() macros, so let's rename the
existing one dyn_gfx_state_dirty() to avoid the confusion, and move it
to panvk_cmd_draw.h, since it's the same for JM and CSF.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31911>
We're going to put the panvk_cmd_graphics_state definition to
panvk_cmd_draw.h, which involves including panvk_cmd_draw.h from
panvk_cmd_buffer.h, which in turn means we can't include
panvk_cmd_buffer.h from panvk_cmd_draw.h.
Kill the circular inclusion by changing the prototype of
panvk_select_tiler_hierarchy_mask() to take a panvk_physical_device
and a panvk_cmd_graphics_state instead of a panvk_cmd_buffer oject.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31911>
The BROADCOM_SAND128 modifier is usually used with an extra parameter
to pass in the stride via a side channel. Quoting from drm_fourcc.h:
> The pitch between the start of each column is set to optimally
> switch between SDRAM banks. This is passed as the number of lines
> of column width in the modifier (we can't use the stride value due
> to various core checks that look at it , so you should set the
> stride to width*cpp).
So apparently this is just a workaround for limitations in some kernel
APIs. DRM modifiers, however, are arguably a bad fit for extra
parameters that aren't known in advance. In the Wayland/KMS ecosystem
many components depend on being able to treat modifiers as opaque, e.g.
for negotiations etc. In practice the current approach requires various
software components to manually use the
`DRM_FORMAT_MOD_BROADCOM_SAND128_COL_HEIGHT()` macro - using the
`DRM_FORMAT_MOD_BROADCOM_SAND128` modifier directly with formats like
`NV12` results in a rejection in the KMS driver and corrupted output
in Mesa (because we'd bail out early in `v3d_sand8_blit()`).
Fortunately the stride check limitations mentioned above don't seem to
apply to Mesa though. Thus we can just add support for the base modifier
and stride (coming from V4L2), allowing various toolkits, Wayland
compositors and V4L2 decoder implementations to support e.g.
`NV12` + `DRM_FORMAT_MOD_BROADCOM_SAND128` (`NC12` in V4L2) in a generic
way.
Notes:
1. Wayland compositors trying to offload composition to KMS will still
fail when doing a test commit.
2. There is another limitation - in the V4L2 MPLANE API - that
requires userspace to know the correct offset of the second plane. That's
a known API limitation though and only affects V4L2 decoder implementations.
Cc: mesa-stable
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32033>
This fixes a corner case of the LNL sub-dword integer restrictions
that wasn't being detected by has_subdword_integer_region_restriction(),
specifically:
> if(Src.Type==Byte && Dst.Type==Byte && Dst.Stride==1 && W!=2) {
> // ...
> if(Src.Stride == 2) && (Src.UniformStride) && (Dst.SubReg%32 == Src.SubReg/2 ) { Allowed }
> // ...
> }
All the other restrictions that require agreement between the SubReg
number of source and destination only affect sources with a stride
greater than a dword, which is why
has_subdword_integer_region_restriction() was returning false except
when "byte_stride(srcs[i]) >= 4" evaluated to true, but as implied by
the pseudocode above, in the particular case of a packed byte
destination, the restriction applies for source strides as narrow as
2B.
The form of the equation that relates the subreg numbers is consistent
with the existing calculations in brw_fs_lower_regioning (see
required_src_byte_offset()), we just need to enable lowering for this
corner case, and change lower_dst_region() to call lower_instruction()
recursively, since some of the cases where we break this restriction
are copy instructions introduced by brw_fs_lower_regioning() itself
trying to lower other instructions with byte destinations.
This fixes some Vulkan CTS test-cases that were hitting these
restrictions with byte data types.
Fixes: 217d412360 ("intel/fs/gfx20+: Implement sub-dword integer regioning restrictions.")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30630>
Since the shader parameters are passed as inline data, push constants
are no longer used and so, not actually set on dispatch. But the
nr_params = 4 was still making the shader emit the code to load them,
causing page faults on simulation, and would also on HW if we didn't
always have a scratch page set.
The uses_inline_data parameter will be set from brw_compile_cs(), called
shortly after this point, so we don't need it here.
The subgroup_size is misleading, as we don't actually require that size
and the code that checks for it isn't even running for this shader.
Fixes: 97b17aa0b1 ("brw/nir: rework inline_data_intel to work with compute")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12152
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32150>
From the perspective of the gpu, host read or host write has the same
implication (gpu cache flush) in the dst access flags. We should
include host write in the dst access flags.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32102>
Fragments are processed in rasterization order within a fragment job.
The fragment subqueue self-wait is nop in most cases. The only
exception is when there is a feedback loop.
When there is a feedback loop, because we lower subpassLoad to
texelFetch, we have to split the render pass.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32074>
src_stages and dst_stages together define an execution dependency. Both
of them should be considered at the same time.
Add a low-level helper, add_execution_dependency, to translate pipeline
stages to subqueue wait masks. The subqueue wait masks only specify
which subqueues should wait for which. The callers will decide how the
waits are performed exactly.
Update collect_cs_deps to call add_execution_dependency and use the
subqueue wait masks to initialize panvk_cs_deps.
The main difference is that barriers such as
.srcStageMask = VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
.dstStageMask = VK_PIPELINE_STAGE_2_NONE,
are ignored.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32074>
src_access defines the availability op and the host-to-device domain op.
dst_access defines the visibility op and the device-to-host domain op.
They should be treated separately.
Add a low-level helper, add_memory_dependency, to translate access flags
to panvk_cache_flush_info.
Update collect_cache_flush_info to use add_memory_dependency. Also
replace the custom subqueue access flag mappings by
vk_filter_{src,dst}_access_flags2.
The main difference is that barriers such as
.srcAccessMask = VK_ACCESS_2_MEMORY_WRITE_BIT,
.dstAccessMask = VK_ACCESS_2_NONE,
or
.srcAccessMask = VK_ACCESS_2_NONE,
.dstAccessMask = VK_ACCESS_2_MEMORY_READ_BIT,
are no longer ignored.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32074>
Adds an optional region selection, based off percentages of the
starting/ending of an image's X & Y values.
This is intended as a performance enhancement tradeoff for smaller
images to be created.
With a smaller image size, the screenshotting layer will change the
region boundaries on the GPU side, which will decrease the amount of
time it takes to copy the image over to CPU-accessible memory.
Using vkcube as an example, the original image size is 500x500:
mesa-screenshot: DEBUG: Screenshot Authorized!
mesa-screenshot: DEBUG: Needs 2 steps
mesa-screenshot: DEBUG: Time to copy: 123530 nanoseconds
Then, by cropping the area to a 100x100 image, we get the following:
mesa-screenshot: DEBUG: Screenshot Authorized!
mesa-screenshot: DEBUG: Using region: startX = 40% (200), startY = 40% (200), endX = 60% (300), endY = 60% (300)
mesa-screenshot: DEBUG: Needs 2 steps
mesa-screenshot: DEBUG: Time to copy: 12679 nanoseconds
For this example, this is a ~90% time reduction improvement!
Overall, this option reduces the copy time to a point where it can
become negligible, relative to the frame time of the application.
Signed-off-by: Casey Bowman <casey.g.bowman@intel.com>
Reviewed-by: Felix DeGrood felix.j.degrood@intel.com
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32016>
Lots of tests are hitting the assert, one in particular :
dEQP-VK.binding_model.mutable_descriptor.single.switches.sampler_combined_image_sampler.update_copy.nonmutable_source.normal_source.pool_same_types.pre_update.no_array.comp
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: b6d11ba5b4 ("anv: Protect memcpy/memset/qsort calls against NULL arguments")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32133>
Avoids sanitizer errors like:
```
../src/intel/vulkan/anv_pipeline_cache.c:409:4: runtime error: null pointer passed as argument 1, which is declared to never be null
../src/intel/vulkan/anv_descriptor_set.c:696:4: runtime error: null pointer passed as argument 1, which is declared to never be null
../src/intel/vulkan/anv_descriptor_set.c:2709:10: runtime error: null pointer passed as argument 1, which is declared to never be null
../src/intel/vulkan/anv_descriptor_set.c:2709:10: runtime error: null pointer passed as argument 2, which is declared to never be null
```
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32098>
Avoids sanitizer errors like:
```
../src/intel/vulkan/anv_pipeline_cache.c:406:4: runtime error: null pointer passed as argument 1, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:406:4: runtime error: null pointer passed as argument 2, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:417:4: runtime error: null pointer passed as argument 2, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:435:4: runtime error: null pointer passed as argument 1, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:435:4: runtime error: null pointer passed as argument 2, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:439:4: runtime error: null pointer passed as argument 1, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:439:4: runtime error: null pointer passed as argument 2, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:443:4: runtime error: null pointer passed as argument 1, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:443:4: runtime error: null pointer passed as argument 2, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:447:4: runtime error: null pointer passed as argument 1, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:447:4: runtime error: null pointer passed as argument 2, which is declared to never be null
```
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32098>
As per the code comment added in this commit the nir produced from
glsl to nir doesn't always keep function declarations before the
code that calls them e.g. calls from within other function
implementations. The change in this commit works around this problem by
first cloning all function declarations in a first pass, then cloning
the implementations in a second pass once we have filled the remap
table.
Fixes: cbfc225e2b ("glsl: switch to a full nir based linker")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12115
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32100>
This means the fork jobs now have clear priority over nightly jobs,
although it might not matter much as nightly jobs are mostly
long-running jobs and pre-merge & forks will have to wait regardless of
priority.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32093>
KernelCI jobs have priority 44 and are very long-running jobs (and
there might be an issue with the KernelCI that makes it create hundreds
of jobs, @sergi is looking into that).
While bumping to 45+ would be enough to allow Mesa release staging
pipelines to run despite the KernelCI, during the CI meeting with @sergi
and @mupuf it was determined that the Mesa releases are an important
enough operation to warrant being a higher priority than user forks
pipelines, so priority 70 was picked (still under the 75 of Marge
pipelines).
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32093>
Have had to tweak the code to stay safe on the i.MX8MP.
Also, we are for now being very conservative with tiling to prevent
underruns.
In the future, we may want to consider testing different possibilities
during compilation and choosing the optimal one. Also maybe detecting
underruns by checking whether the NPU hung with a given combination.
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31842>
Because dyn_start and dyn_end are indices into
nvk_root_descriptor_table->dynamic_buffers, we would need to offset
cbuf->dynamic_idx by
nvk_root_descriptor_table->set_dynamic_buffer_start[cbuf->desc_set]
in order to do those comparisons correctly.
We could do that, but it's simpler and no less precise to sinply
re-use the same comparison that we do in the other cases here.
This fixes a rendering artifact in Baldur's Gate 3 (Vulkan), which
regressed with the commit listed below.
Fixes: 091a945b57 ("nvk: Be much more conservative about rebinding cbufs")
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32086>
- Modifications to directory paths.
- saveStringArray moved to Stream.h/Stream.cpp to avoid
importing StreamSerializing
- C++ include guards
- Namespace changes
find ./ -type f -exec sed -i -e 's/namespace android/namespace gfxstream/g' {} \;
Reviewed-by: Aaron Ruby <aruby@blackberry.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32062>
This imports certain files from libaemu into gfxstream
guest.
Some are quite specific to gfxstream (Stream, ring_buffer) and others
we expect to Mesa-ify with time (AlignedBuf, Allocator) [probably
while keeping some C++ interface].
The main benefit of importing is easier refactoring and packaging.
Reviewed-by: Aaron Ruby <aruby@blackberry.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32062>
According to PAL, L2 should be invalidated only for images with
DCC/HTILE even on GPUs with non-coherent RBs. In practice, most of
the images have either DCC/HTILE but this can reduce the number of L2
flushes for images without any compression.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31921>
The Early-Z optimization is disabled when there is a discard
instruction in the shader used in the draw call.
But if discard is the only reason to disable Early-Z, and at
draw call time the updates in the draw call are disabled we
can enable Early-Z using a shader variant.
If there are occlussion queries active we also need to disable
Early-z optimization.
So this patch enables Early-Z in this scenario.
The performance improvement is significant when running gfxbench
benchmark showing an average improvement of 11.15%
fps_avg helped: gl_gfxbench_aztec_high.trace: 3.13 -> 3.73 (19.13%)
fps_avg helped: gl_gfxbench_aztec.trace: 4.82 -> 5.68 (17.88%)
fps_avg helped: gl_gfxbench_manhattan31.trace: 5.10 -> 6.00 (17.59%)
fps_avg helped: gl_gfxbench_manhattan.trace: 7.24 -> 8.36 (15.52%)
fps_avg helped: gl_gfxbench_trex.trace: 19.25 -> 20.17 ( 4.81%)
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32028>
We can end up calling vk_multialloc_alloc with 0 size when
`attachment_count` is 0 and `clearValueCount` is 0.
Addressed:
```
Direct leak of 1 byte(s) in 1 object(s) allocated from:
#0 0x7faf033ee0 in __interceptor_malloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fada5cc10 in vk_default_alloc ../src/vulkan/util/vk_alloc.c:26
#2 0x7fac50b270 in vk_alloc ../src/vulkan/util/vk_alloc.h:48
#3 0x7fac555040 in vk_multialloc_alloc
../src/vulkan/util/vk_alloc.h:234
#4 0x7fac555040 in void
tu_CmdBeginRenderPass2<(chip)7>(VkCommandBuffer_T*,
VkRenderPassBeginInfo const*, VkSubpassBeginInfo const*)
../src/freedreno/vulkan/tu_cmd_buffer.cc:4634
#5 0x7fac900760 in vk_common_CmdBeginRenderPass
../src/vulkan/runtime/vk_render_pass.c:261
```
seen in:
dEQP-VK.robustness.robustness2.bind.notemplate.r32i.dontunroll.nonvolatile.uniform_texel_buffer.no_fmt_qual.len_252.samples_1.1d.frag
Fixes: 4cfd021e3f ("turnip: Save the renderpass's clear values in the cmdbuf state.")
Signed-off-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32057>
Establish groups of resolve and unresolve operations that the a7xx
hardware can then use to improve efficiency. Creating such groups enables
continuation of command stream processing while these (un)resolves are in
progress, as long as those latter operations don't depend on the grouped
(un)resolves.
To enable concurrent resolves and unresolves, corresponding fields on the
RB_CCU_CNTL register have to be set appropriately.
Resolve groups are tracked through a scoped struct that logs any pending
resolve operation. Once the group is complete, the emit helper function
will write out the CCU_END_RESOLVE_GROUP event to the command stream.
The buffer ID field on the RB_BLIT_INFO register can be used to disperse
different resolve operations across all available slots in the resolve
engine. The 0x8 and 0x9 IDs are reserved for depth and stencil buffers,
while the 0x0-0x7 range is used for color buffers. A simple incremented
counter is used to assign IDs for all color buffers inside any resolve
group. While it can occur for two color or depth/stencil buffers inside
the same resolve group to have identical IDs, hardware doesn't seem to
have a problem with handling that.
Two TU_DEBUG options are provided, 'noconcurrentresolves' and
'noconcurrentunresolves` disable respective operations by adjusting the
mode set through RB_CCU_CNTL.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31190>
Non-trivial collects (i.e., ones that will introduce moves because the
sources don't line-up with the destination) may cause source intervals
to get implicitly moved when they are inserted as children of the
destination interval. Since we don't support moving intervals in shared
RA, this may cause illegal register allocations. Prevent this by
creating a new top-level interval for the destination so that the source
intervals will be left alone.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: fa22b0901a ("ir3/ra: Add specialized shared register RA/spilling")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31978>
Otherwise anv_descriptor_set is accessed through an unaligned pointer,
which is undefined behavior in C.
```
anv_descriptor_set.c:1620:17: runtime error: member access within misaligned address 0x61900002c2b5
for type 'struct anv_descriptor_set', which requires 8 byte alignment 0x61900002c2b5
```
Fixes: 2570a58bcd ("anv: Implement descriptor pools")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32070>
We have to reject DRM_FORMAT_MOD_APPLE_TWIDDLED_COMPRESSED for surfaces
which are too small. Since the modifier is for all planes, that means
that for multiplane images we need to test all planes for compression
support.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32081>
Provide various derived counters that can be reported by the freedreno
perfetto producer on a7xx devices.
Specific to a7xx is the split of counters for some countables between the
rendering and visibility bins. Such counters have to be configured
separately inside the appropriate perfcounter group, which then enables
the derived counter to use the separate counter values in its measured
metrics.
Not all possible derived counters are enabled because the perfcounter
groups cannot handle as many counters as would be necessary. There's also
disabled derived counters that would require counters from the VBIF group
which isn't exposed for now due to its more complex way of enabling the
relevant counters.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Acked-by: Rob Clark <robclark@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29677>
For each countable that's being set up, the specific counter group is now
also required. This way on a7xx it will be possible to differentiate
between countables that have the same name but can be used through counter
groups for rendering bin or for visibility bin (e.g. CP and BV_CP).
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Acked-by: Rob Clark <robclark@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29677>
Since $RESULTS_DIR is now centrally defined in setup-test-env.sh it's no
longer necessary to manually add a hard-coded results directory for the
b2b-test job results.
This keeps the results directory consistent between b2c-test jobs and lava.
Fixes: 9b6d14aed1 ("ci: Always create results dir from init")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32051>
The RESULTS_DIR variable is defined by reference to the present
working directory, but if the pwd is the root directory then the
$RESULTS_DIR begins with two slashes instead of one like this: //results.
This is harmless but not necessary, so remove it.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32051>
Currently a630-vk-asan has separate files for its expected failures and
skips, but by using the deqp-runner prefix option, the job can use the
common a630 expectation files. This simplifies `a630-vk-asan` without any
substantive changes to the ci job.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31970>
AGX load/stores supports a single family of addressing modes:
64-bit base + sign/zero-extend(32-bit) << (format shift + optional shift)
This is a base-index addressing mode, where the index is minimally in elements
(never bytes, unless we're doing 8-bit load/stores). Both base and the resulting
address must be aligned to the format size; the mandatory shift means that
alignment of base is equivalent to alignment of the final address, which is
taken care of by lower_mem_access_bit_size anyhow.
The other key thing to note is that this is a 64-bit shift, after the sign- or
zero-extension of the 32-bit index. That means that AGX does NOT implement
64-bit base + sign/zero-extend(32-bit << shift)
This has sweeping implications.
For addressing math from C-based languages (including OpenCL C), the AGX mode is
more helpful, since we tend to get 64-bit shifts instead of 32-bit shifts.
However, for addressing math coming from GLSL, the AGX mode is rather annoying
since we know UBOs/SSBOs are at most 4GB so nir_lower_io & friends are all
32-bit byte indexing. It's tricky to teach them to do otherwise, and would not
be optimal either since 64-bit adds&shifts are *usually* much more expensive
than 32-bit on AGX *except* for when fused into the load/store.
So we don't want 32-bit NIR, since then we can't use the hardware addressing
mode at all. We also don't want 64-bit NIR, since then we have excessive 64-bit
math resulting from deep deref chains from complex struct/array cases. Instead,
we want a middle ground: 32-bit operations that are guaranteed not to overflow
32-bit and can therefore be losslessly promoted to 64-bit.
We can make that no-overflow guarantee as a consequence of the maximum UBO/SSBO
size, and indeed Mesa relies on this already all over the place. So, in this
series, we use relaxed amul opcodes for addressing
math. Then, we rewrite our address mode pattern matching to fuse AGX address
modes.
The actual pattern matching is rewritten. The old code was brittle handwritten
nir_scalar chasing, based on a faulty model of the hardware (with the 32-bit
shift). We delete it all, it's broken. In the new approach, we add some NIR
pseudo-opcodes for address math (ulea_agx/ilea_agx) which we pattern match with
NIR algebraic rules. Then the chasing required to fuse LEA's into load/stores is
trivial because we never go deeper than 1 level. After fusing, we then lower the
leftover lea/amul opcodes and let regular nir_opt_algebraic take it from
here.
We do need to be very careful around pass order to make sure things like
load/store vectorization still happen. Some passes are shuffled in this commit
to make this work. We also need to cleanup amul before fusing since we
specifically do not have nir_opt_algebraic do so - the entire point of the
pseudo-opcodes is to make nir_opt_algebraic ignore the opcodes until we've had a
chance to fuse. If we simply used the .nuw bit on iadd/imul, nir_opt_algebraic
would "optimize" things and lose the bit and then we would fail to fuse
addressing modes, which is a much more expensive failure case than anything
nir_opt_algebraic can do for us. I don't know what the "optimal" pass order for
AGX would look like at this point, but what we have here is good enough for now
and is a net positive for shader-db.
That all ends up being much less code and much simpler code, while fixing the
soundness holes in the old code, and also optimizing a significantly richer set
of addressing calculations. Now we don't juts optimize GL/VK modes, but also CL.
This is crucial even for GL/VK performance, since we rely on CL via libagx even
in graphics shaders.
Terraintessellation is up 10% to ~310fps, which is quite nice.
The following stats are for the end of the series together, including this
change + libagx change + the NIR changes building up to this... but not
including the SSBO vectorizer stats or the IC modelling fix. In other words,
these are the stats for "rewriting address mode handling". This is on OpenGL,
and since the old code was targeted at GL, anything that's not a loss is good
enough - we need this for the soundness fix regardless.
total instructions in shared programs: 2751356 -> 2750518 (-0.03%)
instructions in affected programs: 372143 -> 371305 (-0.23%)
helped: 715
HURT: 75
Instructions are helped.
total alu in shared programs: 2279559 -> 2278721 (-0.04%)
alu in affected programs: 304170 -> 303332 (-0.28%)
helped: 715
HURT: 75
Alu are helped.
total fscib in shared programs: 2277843 -> 2277008 (-0.04%)
fscib in affected programs: 304167 -> 303332 (-0.27%)
helped: 715
HURT: 75
Fscib are helped.
total ic in shared programs: 632686 -> 621886 (-1.71%)
ic in affected programs: 113078 -> 102278 (-9.55%)
helped: 1159
HURT: 82
Ic are helped.
total bytes in shared programs: 21489034 -> 21477530 (-0.05%)
bytes in affected programs: 3018456 -> 3006952 (-0.38%)
helped: 751
HURT: 107
Bytes are helped.
total regs in shared programs: 865148 -> 865114 (<.01%)
regs in affected programs: 1603 -> 1569 (-2.12%)
helped: 10
HURT: 9
Inconclusive result (value mean confidence interval includes 0).
total uniforms in shared programs: 2120735 -> 2120792 (<.01%)
uniforms in affected programs: 22752 -> 22809 (0.25%)
helped: 76
HURT: 49
Inconclusive result (value mean confidence interval includes 0).
total threads in shared programs: 27613312 -> 27613504 (<.01%)
threads in affected programs: 1536 -> 1728 (12.50%)
helped: 3
HURT: 0
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31964>
Some drivers generally need int64 lowered, but prefer to do this lowering
themselves late, to have a chance to optimize targeted int64 patterns before
lowering the rest. This isn't currently possible since nir_lower_int64 takes no
options except what's const* in the shader, and frontends call nir_lower_int64
before passing the shader off to the driver. Add an option to defer int64
lowering. This is a bit ugly but the alternative is replumbing nir_lower_int64's
option handling cross-tree and no-thank-you-not-right-now.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31964>
It could be confusing that a newer platform named with a smaller
number than a half-generation of an older platform like 'gfx20' and
'gfx75' in xml files.
Down the road, it can be a little worse once we pass something like
'gfx40' when there is already a gfx45.xml for the oldest platform.
Unify naming xml files with verx10 numbers to resolve the issue.
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31943>
While the documentation says to use NUM_SIMD_LANES_PER_DSS for the stack
address calculation, what the HW actually uses is
NUM_SYNC_STACKID_PER_DSS. The former may vary depending on the platform,
while the latter is fixed to 2048 for all current platforms.
Fixes: 6c84cbd8c9 ("intel/dev/xe: Set max_eus_per_subslice using topology query")
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32049>
There are two fragment shaders from RDR2 that is hurt for spills and
fills on Lunar Lake.
Totals from 2 (0.00% of 551413) affected shaders:
Spill count: 1252 -> 1317 (+5.19%)
Fill count: 2518 -> 2642 (+4.92%)
Those shaders... have a lot of room for improvement. There are some
patterns in those shaders that we handle very, very poorly. Improving
those patterns would likely improve the spills and fills in these
shaders quite dramatically.
Given how much other platforms are helped, I don't this should block
this commit.
No shader-db or fossil-db changes on any pre-Gfx12.5 Intel platforms.
v2: Add some comments and an additional assertion. Suggested by Ken.
shader-db:
Lunar Lake
total instructions in shared programs: 18094517 -> 18094511 (<.01%)
instructions in affected programs: 809 -> 803 (-0.74%)
helped: 6 / HURT: 0
total cycles in shared programs: 921532158 -> 921532168 (<.01%)
cycles in affected programs: 2266 -> 2276 (0.44%)
helped: 0 / HURT: 3
Meteor Lake and DG2 had similar results. (Meteor Lake shown)
total instructions in shared programs: 19820845 -> 19820839 (<.01%)
instructions in affected programs: 803 -> 797 (-0.75%)
helped: 6 / HURT: 0
total cycles in shared programs: 906372999 -> 906372949 (<.01%)
cycles in affected programs: 3216 -> 3166 (-1.55%)
helped: 6 / HURT: 0
fossil-db:
Lunar Lake
Totals:
Instrs: 141887377 -> 141884465 (-0.00%); split: -0.00%, +0.00%
Cycle count: 21990301498 -> 21990267232 (-0.00%); split: -0.00%, +0.00%
Spill count: 69732 -> 69797 (+0.09%)
Fill count: 128521 -> 128645 (+0.10%)
Totals from 349 (0.06% of 551413) affected shaders:
Instrs: 506117 -> 503205 (-0.58%); split: -0.79%, +0.21%
Cycle count: 32362996 -> 32328730 (-0.11%); split: -0.52%, +0.41%
Spill count: 1951 -> 2016 (+3.33%)
Fill count: 4899 -> 5023 (+2.53%)
Meteor Lake and DG2 had similar results. (Meteor Lake shown)
Totals:
Instrs: 152773732 -> 152761383 (-0.01%); split: -0.01%, +0.00%
Cycle count: 17187529968 -> 17187450663 (-0.00%); split: -0.00%, +0.00%
Spill count: 79279 -> 79003 (-0.35%)
Fill count: 148803 -> 147942 (-0.58%)
Scratch Memory Size: 3949568 -> 3946496 (-0.08%)
Max live registers: 31879325 -> 31879230 (-0.00%)
Totals from 366 (0.06% of 633185) affected shaders:
Instrs: 557377 -> 545028 (-2.22%); split: -2.22%, +0.01%
Cycle count: 26171205 -> 26091900 (-0.30%); split: -0.54%, +0.24%
Spill count: 3238 -> 2962 (-8.52%)
Fill count: 10018 -> 9157 (-8.59%)
Scratch Memory Size: 257024 -> 253952 (-1.20%)
Max live registers: 28187 -> 28092 (-0.34%)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32041>
Previously an instruction like
cmp.l.f0.0(16) null:F, v359:F, 0f
would get lowered to
undef(16) v13703:UD
cmp.l.f0.0(16) v13703:F, v359:F, 0f
mov(16) null:UD, v13703:UD
After copy propagation and dead-code elimination are run again, the
original CMP gets turned back into its original form!
Some cases can also emit MOVs from the original NULL register.
It should be possible to not do any lowering here, but there are some
interactions with source lowering passes for things like
cmp.l.f0.0(16) null:HF, g89.1<16,16,1>:HF, 0hf
What inspired this was... diff'ing step-by-step dumps from
INTEL_DEBUG=optimizer had a lot of useless changes due to these MOVs
and undefs. It was very annoying. This low-effort change gets the
majority of the possible benefit.
No shader-db or fossil-db changes on any Intel platform.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32041>
Copy propagation would incorrectly occur in this code
mov(16) v4+2.0:UW, u0<0>:UW NoMask
...
mov(8) v6+2.0:UD, v4+2.0:UD NoMask group0
to create
mov(16) v4+2.0:UW, u0<0>:UW NoMask
...
mov(8) v6+2.0:UD, u0<0>:UD NoMask group0
This has different behavior. I think I just made a mistake when I
changed this condition in e3f502e007.
It seems like this condition could be relaxed to cover cases like (note
the change of destination stride)
mov(16) v4+2.0<2>:UW, u0<0>:UW NoMask
...
mov(8) v6+2.0:UD, v4+2.0:UD NoMask group0
I'm not sure it's worth it.
No shader-db or fossil-db changes on any Intel platform. Even the code
for the test case mentioned in the original commit did not change.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Fixes: e3f502e007 ("intel/fs: Allow copy propagation between MOVs of mixed sizes")
Closes: #12116
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32041>
Specifically, allow two immediate sources for BFE on Gfx12+. I stumbled
on this while trying some stuff with !31852.
v2: Don't be lazy. Add proper assertions for all the things on all the
platforms. Based on a suggestion by Ken.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Fixes: 7bed11fbde ("intel/brw: Allow immediates in the BFE instruction on Gfx12+")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31858>
This is required, otherwise we regress latency in cases where
applications are using FIFO without explicit KHR_present_wait.
This is an unacceptable regression.
The fix is to normalize the behavior to X11 WSI.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Fixes: d052b0201e ("vulkan/wsi/wayland: Use fifo protocol for FIFO")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32029>
If the gfx version is overriden by the exporter process, the surface
layout might not be compatible with the importer process (which uses
the real gfx version).
So fail early, except if the layout is LINEAR (because it should work
on all gen) or a modifier is used (which should be rejected elsewhere
if not supported).
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31841>
Instead of increasing the version number to describe which fields
are set, use the lower 16 bits for the metadata format version,
and the other bits as flags.
This way the version number defines the layout, and the flags
tell which values are set.
The format version is bumped to 3 (= can have flags), and 2 flags
are defined:
* AC_SURF_METADATA_FLAG_EXTRA_MD_BIT: replaces what was version
number = 2. This means the metadata contains extra information
for tools.
* AC_SURF_METADATA_FLAG_FAMILY_OVERRIDEN_BIT: if set, it means the
surface was allocated from a context that used an overriden gfx
family. This allows the importer process to fail the import early,
as the surface is likely to be invalid.
It also adds an extra dw at the end, to store the fake family.
This is a breaking change for existing code that interpreted
"version > 1" as 2, but only in one case:
AC_SURF_METADATA_FLAG_FAMILY_OVERRIDEN_BIT being set, but not
AC_SURF_METADATA_FLAG_EXTRA_MD_BIT, which produces a version number
of 0x20001 but there's not extra data.
I think this is ok, since both gfx family overriding and extra_md
are debugging tools.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31841>
mount -t tmpfs -o nosuid,nodev,size=2G,mode=1755 tmpfs ${SHADER_CACHE_DIR}
}
if[ -z "$DEQP_SUITE"];then
if[ -z "$DEQP_VER"];then
echo'DEQP_SUITE must be set to the name of your deqp-gpu_version.toml, or DEQP_VER must be set to something like "gles2", "gles31-khr" or "vk" for the test run'
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
