For each pipeline, we launch 13 jobs for kingoftown, let's decrement it
to match the number of 12 trogdor-kingoftown available in Collabora's
farm atm.
Let's decrement the parallel no., and increment the dEQP fraction for
a618_vk job.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31699>
We have 6 DUTs but we are running a total of 7 jobs per pipeline,
increasing the DUT pending time.
- Job: parallel no.
- 'a618_gl: 2'
- 'a618_egl: 1'
- 'a618_piglit: 1'
- 'zink-tu-a618: 1'
So, reduce the `a618_gl` parallel from 2 to 1 and increase dEQP fraction
from 2 to 5 to reach the 10-min mark.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31699>
We have one spare meson-g12b-a311d-khadas-vim3 DUT, and this job is
taking 14 minutes to run on average and retries are rare, so let's
increment the parallel to reach the 10 min-mark.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31699>
With the addition of the radeonsi-raven-cdna-lower-image:x86_64 job,
zork devices are being overutilized.
To balance the load, we're moving the radv-raven-traces job to dalboz,
where one DUT per pipeline remains available.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31699>
These skip files contain tests that exceed one minute in execution time,
which are better suited for nightly jobs. This change aims to optimize
execution time and prevent delays in merge pipelines under time
constraints.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31699>
- Increase the fraction for radv-stoney-vkcts from 15 to 18.
- Same for radv-angle, from 2 to 3
The last one should take around 7 minutes, but this new 3 minute gap can
be filled in by the ~95% DUT availability and eventual infra retries.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31699>
This change has two main advantages. First is that the previous code
had a subtle bug where state updates would drop the previous state
pushbuf without first guaranteeing that the queue was idle, potentially
leading to a fault. This worked when I first wrote the code because we
were using the old nouveau UAPI which took a list of BOs on each submit
and the kernel would interanlly reference count them. With the modern
UAPI, there is no such safety net.
The second effect of this commit is that we're now only submitting the
pushbuf when one of the pointers or ranges actually changes. This
should hopefully reduce GPU stalling as setting those pointers is a
pretty heavy-weight operation.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30596>
There are more driver params than what is contained in the indirect
buffer. So switch things around to always allocate a buffer into which
we copy the indirect params.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31534>
Before the gallium driver can support load_shader_consts_via_preamble it
needs a way to differentiate between # of API level UBOs and the number
of UBOs after the driver inserts ones for driver-params, etc. This is
because the driver UBOs are emit in a different place from user UBOs.
If we didn't have this distinction, and the app had more UBOs bound than
the shader used, we would otherwise emit some conflicting UBO
descriptors (ie. ones for unused const slots conflicting with the driver
UBO slots).
This also moves the consts_ubo emit into the PROG state.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31534>
Move this to where the rest of the hs/ds params are emit, because for
a7xx with load_shader_consts_via_preamble we'll need this all to be a
single UBO. So we won't be able to piecemeal upload consts.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31534>
Looks like this was disabled by mistake. RadeonSI relies on the default
value which is "no force" and PAL only sets this to FORCE_DISABLE when
HTILE is completely disabled using settings.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31690>
Using address of drawable as hash table key will cause memory issue in this
situation:
1. drawable A with address addr is destroyed and deleted from the hash table.
2. drawable B with same address addr is created and added to the hash table
right after 1 is done.
3. st_framebuffers_purge will seach the hash table with drawable addr that
associated with each framebuffer. If drawable is not in the hash table, then
free this framebuffer.
So when drawable B is created, then the framebuffer that associated with
drawable A will not be freed in time. This will cause framebuffer memory leak.
Since drawable->ID is unique, this uses drawable-ID as pre-hash to store
drawable in hash table. This also removes key_hash_function because we already
use drawable-ID as pre-hash when insert the data and we need to avoid assert of
_mesa_hash_table_search_pre_hashed fail.
Signed-off-by: Julia Zhang <Julia.Zhang@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31161>
Long time ago svga had a sourceforge project where auto-generated
header files for the SVGA device were hosted. Gallium's svga driver
copied those files and when the sourceforge project became
obsolete they started being updated by hand.
Kernel and igt projects switched to the official way in which the SVGA
header files are generated but Mesa3d wasn't ported at the time.
The official SVGA headers diverged from the official ones creating bugs.
Fix it by porting the SVGA Gallium driver to the auto-generated SVGA
header files.
Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31653>
This will make things easier in situations where we don't want to use
the binding table at all (indirect draws/dispatches).
The mechanism is simple, upload a vec3 either through push constants
(<= Gfx12.0) or through the inline parameter register (>= Gfx12.5).
In the shader, do this :
if vec.x == 0xffffffff:
addr = pack64_2x32 vec.y, vec.z
vec = load_global addr
This works because we limit the maximum number of workgroup size to
0xffff in all dimension :
maxComputeWorkGroupCount = { 65535, 65535, 65535 },
So we can use the large values to signal the need for indirect
loading.
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/31508>
This intrinsic was initially dedicated to mesh/task shaders, but the
mechanism it exposes also exists in the compute shaders on Gfx12.5+.
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/31508>
In SIMD32, the fence instruction is currently going to read grf0-3
leading to such assertions in the backend :
../src/intel/compiler/brw_fs_reg_allocate.cpp:206:
void fs_visitor::calculate_payload_ranges(bool, unsigned int, int*) const:
Assertion `j < payload_node_count' failed.
The reason we haven't seen the problem yet is that there always enough
payload register to accomodate this. But the following change is going
to make the inline parameter register optional.
Since SHADER_OPCODE_MEMORY_FENCE is emitted in the generator as SIMD1
NoMask (see brw_memory_fence), we can limit ourselves to SIMD1
exec_all() in the IR as well so that the IR accounts for grf0 as a
source.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31508>
Useful to insert debug traces a bit later in the lowering process (in
particular after load/store vectorization).
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/31508>
