Move it before the new source is used. This currently works because all
instructions have a minimum amount of sources allocated, but a later commit
will change that.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36817>
If vkCmdSetRenderingAttachmentLocations() isn't setting all color
attachment locations (ie. MAX_RTS), the remapping might be wrong
because MESA_VK_ATTACHMENT_UNUSED is used to trim the unused locations
Found by inspection while implementing a new extension.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36778>
The scheduler sets the flag when scheduling the ALU
instructions into ALU groups, so there is no need to
set these flags early and it was already done inconsistently
anyway. The only expection is the ALU predicate instructions,
because it is not yet handled direcly by the scheduler.
Clanup the use of alu_write too.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36790>
On Mali, GPU timestamp cycle counts are mapped to the arch counter, and
so advance at the same rate as CNTVCT (with a fixed offset). The kernel
applies gradual NTP adjustments to CLOCK_BOOTTIME by modifying the rate
of the cycle->ns conversion slightly from the nominal frequency of the
clock, which causes it to drift from the GPU clock's ns values (which
just use the nominal frequency). On a rock5b, I measured this drift in
the 25-30µs/s range.
Perfetto's clock synchronization applies a fixed offset between each
clock snapshot, and so does not handle clocks with significantly
different rates and infrequent snapshots well. For panvk, we emit
snapshots once per second, and so the drift results in an error of
~25µs right before the next snapshot. This is significant for measuring
the latency of CPU<->GPU operations, and shows up as a sawtooth pattern
on the measured latency distribution over time.
CLOCK_MONOTONIC_RAW does not have the NTP adjustment, and so the only
source of drift is error in the shift/mult approximation that the kernel
uses for cycle->ns. This error is very small, and so by emitting CPU
trace events against CLOCK_MONOTONIC_RAW instead of CLOCK_BOOTTIME, we
can get much more accurate synchronization.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34390>
Everything is currently using CLOCK_BOOTTIME, which is perfetto's
default, and matches the previous behavior. On some hardware, different
clocks may be better synchronized with the gpu clock.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34390>
GitLab 18.2.2 introduced a security restriction that only allows
uploading artifacts to the user's own namespace.
To work around this, hardcode the artifact location to the path where
the artifacts were uploaded to in
ce0d4f998d ("ci: Fix for GitLab 18.2.2 upgrade").
This is an ugly but temporary workaround until a proper solution is in
place.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36836>
To ensure all submitted commands are visible on screen flush them.
Fixes tri.cpp test with softpipe.
Signed-off-by: Max Ramanouski <max8rr8@gmail.com>
Signed-off-by: Max R <max8rr8@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36769>
This change fixes the gds implementation of
atomic_counter_comp_swap which requires three arguments.
This update is based on 4e3b43f180 "r600/atomic: fix
ATOMCAS instruction." which was the tgsi implementation.
Note: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36554
is required for this change to work properly on cayman.
This change was tested on palm, cypress and barts. Here is the test fixed:
khr-gl4[5-6]/shader_atomic_counter_ops_tests/shaderatomiccounteropsexchangetestcase: 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/36254>
Now the `subject` from S3 id_token JWT refers to the target project when
we are in an MR pipeline, due to this patch [1].
So, let's use workflow variables to help us define where the S3 paths
should be pointing at.
[1] 7e9f329e8f
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Suggested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36832>
This will avoid kernel overhead on tu (implicit syncs every BO) and radv
(implicit syncs the swapchain BOs) for doing implicit synchronization on
non-explicit-sync WSI backends (old X11 and Wayland, KHR_display without
!36591, and headless).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19309>
