I didn't catch this typo in !33377 until it got merged. Correctness in this
list is necessary for the job in the build-only stage.
Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com>
Reviewed-by: Valentine Burley <valentine.burley@collabora.com>
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33428>
Rename the drirc and call it radv_disable_dedicated_sparse_queue instead,
since normal queues support sparse now anyway.
Keep the workaround for existing known games, since they might not
expect a separate SPARSE queue to pop up.
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>
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>
We're about to enable our first Android test job.
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>
Save the current git hash to /angle/hash after applying local patches,
and use it to verify that we're using our own ANGLE build in
Cuttlefish.
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>
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>
Only amd64 needs the VK-main build, as it's only used by Raven and
Stoney on RADV.
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>
Android officially only supports GLES, and we don't need the desktop
GL CTS in CI.
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>
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>
We'll use this for D32->D24X8 conversion on Intel on Gfx11/Gfx12.0/DG2
(where HW doesn't have fp64 support).
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33422>
This change adds the SimpleFloatBlendEnable field to the structure.
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32739>
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>
this is now handled in vtn_bindgen2 for vtn path code. this does drop support
from printf from GRL but that seems appropriate at this point.
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>
