if loading the default hardware driver fails, implicitly loading zink
should now be preferable to hitting the software fallback now that zink
has all the same capabilities
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25640>
this is going to be broken, so don't bother trying
also add LIBGL_KOPPER_DRI2 so people can continue to footgun if they
really really want to
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25640>
Add u_trace initialization and callbacks in new files si_utrace.h/c
Change si_context in si_pipe.h to add si_ds_queue and u_trace to
collect traces.
Add si_record_ts function in si_gfx_cs.c to add timestamp in command
stream.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23664>
Add perfetto code in new files si_perfetto.h/cc which add tracepoint
begin and end event and calls to the generated code from python
si_tracepoints.py
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23664>
This makes sure that the semaphore is only written when all work
on the compute queue is finished.
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/25770>
Create a version of this function that takes a CS and queue family.
move it to radv_cs.h so it can be called from multiple other files.
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/25770>
We need to shut down the runtime queue threads before tearing down
anything else.
Gets rid of helgrind errors like this :
==212772== Possible data race during write of size 4 at 0xADCBFB0 by thread #1
==212772== Locks held: 1, at address 0x6B8F260
==212772== at 0x8AC3EFF: simple_mtx_destroy (simple_mtx.h:97)
==212772== by 0x8ACB24D: intel_ds_device_fini (intel_driver_ds.cc:603)
==212772== by 0x6CBD4D4: anv_device_utrace_finish (anv_utrace.c:471)
==212772== by 0x6C71577: anv_DestroyDevice (anv_device.c:3679)
==212772== by 0x6B2F1E2: loader_layer_destroy_device (loader.c:4358)
==212772== by 0x6B3F10B: vkDestroyDevice (trampoline.c:983)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: cc5843a573 ("anv: implement u_trace support")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10010
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25805>
The limozeen runners are quite under-committed, while we had 10 jobs
running for our 9 cheza runners, causing an unnecessary wait even when the
farms were idle.
I've removed the old 630 skqp bits, so we can just track what's being
tested on 618. 618 had skqp toml and xfails laying around alreaady.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25790>
We have only 6 of these boards since one died in May, and 7 jobs allocated
to them. So you ended up with a 5 minute delay on each pipeline with an
otherwise-idle farm while you waited for the first batch of jobs to
complete so you could get the last one started. It turns out that piglit
was taking 3 minutes of runtime each, so we can just shard piglit 2 ways,
stay under runtime, and not over-allocate the farm
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25790>
We have job-level retry on failure now, and will continue to need to in
order to work around fd.o infrastructure flakes. If we stop doing retry
inside the job, then we can crank down the gitlab-level timeouts on test
jobs to be closer to our CI guidelines and avoid blocking a runner for an
hour when things go wrong (for example, cheza #16 failing to boot in a
recognized way and continuously looping due to the intra-job retry).
Plus, the job logs will be more readable when you don't have two boots in
one job, and we'll get the flakes surfaced in our monitoring dashboards.
If internal retries were really doing useful work we may see an increase
in flakes as a result of this. I'm committing to turning off boards or
reducing coverage as necessary to handle this.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25790>
Until the performance issues get resolved, enable the extension
if `VN_DEBUG=gpl`.
Also enable the required (and trivial) VK_KHR_pipeline_library.
Signed-off-by: Lina Versace <linyaa@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22419>
Function vn_fix_graphics_pipeline_create_infos() had two interleaved
phases: discovery of needed fixes, and application of those fixes.
Move the discovery phase into new function
vn_find_graphics_pipeline_create_info_fixes(). The two-phase approach
will be simplify the implementation of VK_EXT_graphics_pipeline_library.
No intended change in behavior.
Signed-off-by: Lina Versace <linyaa@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22419>
Use a more consistent naming scheme for everything. Follow-up patches
will implement VK_EXT_graphics_pipeline_library, which will make the
code significantly more complex, in which better names will make the
code more readable.
Except for replacing `any_fix` with `erase.mask`, this patch does modify
any procedural code. It merely renames structs and fields.
Signed-off-by: Lina Versace <linyaa@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22419>
No change in behavior. Prepares for storing more state in graphics
libraries for VK_EXT_graphics_pipeline_library.
Signed-off-by: Lina Versace <linyaa@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22419>
No intended change in behavior. This little improvement will help
vn_pipeline track its graphics state more accurately.
Signed-off-by: Lina Versace <linyaa@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22419>
When writing vn_fix_graphics_pipeline_create_info() long ago, I defined
some always-true dummy vars that represented some
VkGraphicsPipelineLibraryFlagsEXT. In the conditions that decide which
state to fixup, I used the dummy vars.
My intent was that this would ease the implementation of
VK_EXT_graphics_pipeline_library, because some of the GPL fixup logic
would already be present. I was wrong. After I studied GPL more,
I discovered that the conditions were using the dummy vars incorrectly.
The incorrect usage produced no bugs, because the vars are always true.
Delete the dummy vars.
Signed-off-by: Lina Versace <linyaa@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22419>
With VK_EXT_graphics_pipeline_library, the layout may be omitted or
ignored in incomplete pipelines.
Signed-off-by: Lina Versace <linyaa@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22419>
We should avoid erasing VkGraphicsPipelineCreateInfo when possible
because the erasure add cpu overhead. Do not erase pViewports if
viewportCount is 0. Do not erase pScissors if scissorCount is 0.
Signed-off-by: Lina Versace <linyaa@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22419>
This isn't meant to be exhaustive and only prints the packets
and fields which were interesting to me during debugging the
RADV transfer queue implementation.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-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/25769>
This makes it clearer what is what when reading IBs
for debugging purposes.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-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/25769>
