Include drm_helper.h to define the driver descriptor again, but with a
new define GALLIUM_KMSRO_ONLY to disable defining descriptors for the
drivers that kmsro uses.
Fixes clinfo on Panfrost.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4002
Fixes: 9ec28b8d22 ("gallium/drm: Deduplicate screen creation for the dynamic (clover) pipe loader.")
Acked-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9380>
In some cases we will change the type of the destination register of
an instruction. This is the type we should use to verify that we're
allow to do the replacement.
Otherwise we can hit restrictions on CHV and upcoming Xe-Hp for
instance where the copy propagation transforms this :
send(16) (mlen: 2) vgrf10:UD, 0u, 0u, vgrf35:D, null:UD
mov(16) vgrf11:UW, vgrf10<2>:UW
mov(16) vgrf12:UW, vgrf10+0.2<2>:UW
mov(16) vgrf15:HF, |vgrf11|:HF
mov(16) vgrf16:HF, |vgrf12|:HF
mov(8) vgrf41<2>:UW, vgrf15+0.0:UW group0
mov(8) vgrf42<2>:UW, vgrf15+0.16:UW group8
mov(8) vgrf45<2>:UW, vgrf16+0.0:UW group0
mov(8) vgrf46<2>:UW, vgrf16+0.16:UW group8
into this :
send(16) (mlen: 2) vgrf10:UD, 0u, 0u, vgrf35:D, null:UD
mov(8) vgrf41<2>:HF, |vgrf10+0.0|<2>:HF group0
mov(8) vgrf42<2>:HF, |vgrf10+1.0|<2>:HF group8
mov(8) vgrf45<2>:HF, |vgrf10+0.2|<2>:HF group0
mov(8) vgrf46<2>:HF, |vgrf10+1.2|<2>:HF group8
Because of the floating point use, stride and offets should be the
same.
v2: Fix final destination type selection (Curro)
v3: constify (Curro)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9832>
Otherwise pass->tile_align_w will be 0, leading to a divide by zero and
undefined behavior. In practice, I saw this lead to an infinite loop in
tests like
dEQP-VK.draw.instanced.draw_indexed_indirect_vk_primitive_topology_line_list_attrib_divisor_0_multiview
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9606>
A little low-stakes RE effort as I unwind from fighting CI all day. Comes
from diffing dEQP-VK.clipping.user_defined.clip_distance.vert.* on the
blob and comparing to a6xx behavior. (My blob doesn't do tess, so if
there are equivalent tess fields for some of these, I didn't find them)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9870>
FMASK/CMASK make no sense with depth/stencil or stencil-only surfaces.
gfx9_compute_miptree() was called twice for stencil-only surfaces,
and the first call was allocating FMASK/CMASK.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9612>
This should catch any build breaks in release mode. iris was already
build tested in debug builds, but not release mode.
Suggested by Michel Dänzer.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9862>
Linux Kernel 4.15+ is now required for RADV, this kernel has been
released 3 years ago and should be in most modern distros.
This allows us to remove a lot of legacy code for fence/semaphore.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9800>
It seems that when the linker optimized the IO it might leave gaps
in the driver output locations, therefore set the size of the output
array based on the highest driver location occupied by a store_output.
Fixes#4520
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9879>
They are not supported by the hardware.
Fixes:
dEQP-GLES2.functional.vertex_arrays.single_attribute.strides.buffer_0_32_short3_vec4_dynamic_draw_quads_1
dEQP-GLES2.functional.vertex_arrays.single_attribute.strides.buffer_0_32_short3_vec4_dynamic_draw_quads_256
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9877>
The indirect draw call already encodes the index bias so that no
additional encoding in the hardware is needed in this case.
This fixes a regression with a number of tests from
dEQP-GLES31.functional.draw_indirect.random.*
Fixes: c6c532faa8
"gallium/u_vbuf: use updated pipe_draw_start_count while using draw_vbo"
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9877>
It seems that this has to be 4 (radeonsi also sets this value to 4)
Fixes deqp-gles31:
functional.texture.texture_buffer.modify.bufferdata.offset_1_alignments
functional.texture.texture_buffer.modify.bufferdata.offset_7_alignments
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9877>
This is the final step of this little journey, which allows us to no
longer deal with the shader-slot mapping inside the NIR to SPIR-V
translation.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9836>
These locations should match what we get out of the pre-existing pass,
and are currently unused. They will be used in a later commit in this
series, but is left like this because this code is fairly fragile.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9836>
We need to check against the correct define, DRM_FORMAT_INVALID.
Checking an uint32_t against DRM_FORMAT_MOD_INVALID will always produce
false anyway.
Caught by Coverity.
Fixes: b85c6531f6 ("frontends/va: add support for VA_EXPORT_SURFACE_COMPOSED_LAYERS")
Reviewed-by: Simon Ser <contact@emersion.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9897>
pan_blend_shaders.{c,h} files are removed from Makefile.sources
in order to avoid the following building error:
FAILED: out/target/product/x86_64/obj_x86/STATIC_LIBRARIES/libmesa_pipe_panfrost_intermediates/pan_blend_shaders.o
...
clang: error: no such file or directory: 'external/mesa/src/gallium/drivers/panfrost/pan_blend_shaders.c'
clang: error: no input files
Fixes: 7994929e84 ("panfrost: Use the blend shader cache attached to the device")
Acked-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9894>
While looking at the traces emitted by chromium, I saw a lot of those
errors. But looking at the value of ns, it is 0, so it's probably just
the application checking whether work is done or not. Not much point
in printing out an error.
v2: check ret value (Christian)
check both timeout codes (Lionel)
Signed-off-by: Lionel Landwerlin <llandwerlin@gmail.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9875>
This changes how the L3 cache affinity code works out the affinity
masks. It works better with multi-CPU systems and should also be
capable of handling big/little type situations if they appear in
the future.
It now iterates over all CPU cores, gets the core count for each
CPU, and works out the L3_ID from the physical CPU ID, and
the current cores L3 cache. It then tracks how many L3 caches
it has seen and reallocate the affinity masks for each one.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4496
Fixes: d8ea509965 ("util: completely rewrite and do AMD Zen L3 cache pinning correctly")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9782>
resolve_draw_info() is only for drawing from streamout, so this check
can be moved forward to avoid overwriting draw params when not necessary
no functional changes at this time
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9844>
We were using a write dependency to ensure ordering since LDTMUs sequences
are ordered, but by using a write dependency with TMU config we were also
preserving ordering with TMU config writes that are not a sequence
terminator, which is not required and reduces scheduling flexibility.
Instead, use a write dependency to ensure strict ordering of TMU reads,
but only a read depdency with TMU config.
With this change we also need to update CS barriers to also have a write
dependency with TMU reads to ensure that we don't move TMU reads around
CS barriers.
total instructions in shared programs: 13602500 -> 13597851 (-0.03%)
instructions in affected programs: 2681428 -> 2676779 (-0.17%)
helped: 6567
HURT: 4960
Instructions are helped.
total max-temps in shared programs: 2317927 -> 2317914 (<.01%)
max-temps in affected programs: 13861 -> 13848 (-0.09%)
helped: 355
HURT: 300
Inconclusive result (value mean confidence interval includes 0).
total sfu-stalls in shared programs: 32074 -> 32247 (0.54%)
sfu-stalls in affected programs: 848 -> 1021 (20.40%)
helped: 160
HURT: 327
Inconclusive result (%-change mean confidence interval includes 0).
total inst-and-stalls in shared programs: 13634574 -> 13630098 (-0.03%)
inst-and-stalls in affected programs: 2703041 -> 2698565 (-0.17%)
helped: 6558
HURT: 5020
Inst-and-stalls are helped.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9856>
Instead of last TMU write. According to the documentation, the entries
in the output FIFO are pushed with the *final* input write for the
lookup, which is the one terminating the sequence. We flag these
with last_tmu_config.
This will allow us to move all TMU register writes for a lookup except
the last one ahead of the LDTMUs for the previous lookup, possibly
allowing us to pair up these writes the wrtmuc instructions for the
same lookup, turning code like this:
nop ; nop ; wrtmuc (tex[0].p0 | 0x3)
nop ; nop ; wrtmuc (tex[2].p1 | 0x1)
nop ; nop ; ldunif (ubo[2]+0xe0)
fadd r4, rf33, rf51 ; mov unifa, r5 ; ldunif (ubo[2]+0x110)
fmax rf34, 0, r4 ; nop
nop ; mov tmut, rf11
nop ; mov tmus, rf0
into:
nop ; mov tmut, rf11 ; wrtmuc (tex[0].p0 | 0x3)
nop ; nop ; wrtmuc (tex[2].p1 | 0x1)
nop ; nop ; ldunif (ubo[2]+0xe0)
fadd r4, rf33, rf51 ; mov unifa, r5 ; ldunif (ubo[2]+0x110)
fmax rf34, 0, r4 ; nop
nop ; mov tmus, rf0
total instructions in shared programs: 13648140 -> 13602500 (-0.33%)
instructions in affected programs: 3497402 -> 3451762 (-1.30%)
helped: 12044
HURT: 3484
Instructions are helped.
total max-temps in shared programs: 2318687 -> 2317927 (-0.03%)
max-temps in affected programs: 17234 -> 16474 (-4.41%)
helped: 615
HURT: 198
Max-temps are helped.
total sfu-stalls in shared programs: 32354 -> 32074 (-0.87%)
sfu-stalls in affected programs: 1462 -> 1182 (-19.15%)
helped: 461
HURT: 188
Sfu-stalls are helped.
total inst-and-stalls in shared programs: 13680494 -> 13634574 (-0.34%)
inst-and-stalls in affected programs: 3514405 -> 3468485 (-1.31%)
helped: 12062
HURT: 3486
Inst-and-stalls are helped.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9856>
each indexed direct draw cmd now contains n draws (though right now n=1)
indexed draws now also have a flag used to avoid recalculating start index if
a cmdbuf is submitted multiple times
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9843>
now that the results are automatically being copied to internal buffers,
mapping the buffers will handle any fencing that's required
the only caveat is that the query still needs to be flushed for a result
to be returned
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9811>