When importing a BO, if it is already imported, then the handle will
alias an existing BO instance. It is possible for the existing owner to
free the BO after the import and leave a dangling handle before we get a
chance to increase the refcount, so we need to lock the BO table mutex
before importing, to make sure nobody else goes through the free path
during that window.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20403>
When importing a BO, if it is already imported, then the handle will
alias an existing BO instance. It is possible for the existing owner to
free the BO after the import and leave a dangling handle before we get a
chance to increase the refcount, so we need to lock the BO table mutex
before importing, to make sure nobody else goes through the free path
during that window.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20403>
When importing a BO, if it is already imported, then the handle will
alias an existing BO instance. It is possible for the existing owner to
free the BO after the import and leave a dangling handle before we get a
chance to increase the refcount, so we need to lock the BO table mutex
before importing, to make sure nobody else goes through the free path
during that window.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20403>
BOs can only have one handle. If renderonly_create_gpu_import_for_resource
ends up importing a BO that was already mapped for scanout, it will get
the same handle. This leaves us with two renderonly_scanout objects for
one handle, and the first one to be destroyed will free it.
Import the BO map tracking logic from asahi, to avoid aliasing
renderonly_scanout objects. Each actual BO now is only represented by a
single object instance, which is reference counted.
Fixes KWin full-screen PipeWire capture breaking scanout entirely.
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20397>
This switches us over to Mesa's code style [1], normalizing us within the tree.
The results aren't perfect, but they bring us a hell of a lot closer to the rest
of the tree. Panfrost doesn't feel so foreign relative to Mesa with this, which
I think (in retrospect after a bunch of years of being "different") is the right
call.
I skipped PanVK because that's paused right now.
find panfrost/ -type f -name '*.h' | grep -v vulkan | xargs clang-format -i;
find panfrost/ -type f -name '*.c' | grep -v vulkan | xargs clang-format -i;
clang-format -i gallium/drivers/panfrost/*.c gallium/drivers/panfrost/*.h ; find
panfrost/ -type f -name '*.cpp' | grep -v vulkan | xargs clang-format -i
[1] https://docs.mesa3d.org/codingstyle.html
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20425>
We'll use the one in src/panfrost/.clang-format instead, which isn't identical
but should be good enough. This way they don't conflict with each other.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20425>
The issue we're addressing here is that we have 2 batches and the both
grow at different rate. We want to keep doubling the main batch size
as the application writes more and more commands to limit the number
of GEM BOs. But we don't want to have the generation batch size to be
linked to the main batch.
v2: remove gfx7 code
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15642>
I noticed a sequence like the following in a scheduled SuperTuxKart shader:
TEX_SINGLE.slot0 @r0:r1, ..
LD_VAR.wait0 @r2, ...
FMA r1, ...
Why do we stall waiting for the TEX_SINGLE instruction when it's not actually
read? Because its upper channels are *never* read, leading to a
write-after-write dependency when the register allocator puts some unrelated ALU
destination in there. By appropriately masking the texture instruction's write,
that false dependency disappears, avoiding the stall.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20426>
Unsure if this can actually be hit, but bug fix by inspection: there is no need
to flush for read-after-read relationships.
This might be a bit faster, shrug.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20426>
Just check on the context instead. Usually the number of batches is small so
this is still fast, and avoids all the tricky atomics and the batch->resources
set which existed only for bookkeeping.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20426>
anv_bo has information that will be needed by a future patch in
anv_gem_mmap(), so here already preparing for that.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20423>
It is only used in iris_bufmgr.c so no neeed to export it.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20423>
This was copied from Iris, but it's not actually used in the new NIR-based
transform feedback implementation that we now use on all chips.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20420>
There are too many problems with indirect draws on v7 that we never got this
code path to the finish line, and none of us have a good plan (or reason) to fix
this. Proper indirect draws are only possible since v10 on Mali.
There was interest in using this path to implement indexed draws in PanVK, that
MR is stalled and it's not clear how much sense it makes to do Vulkan on
anything older than v9 or v10 at this point. This code isn't *gone*, it'll still
be in git history, but I don't see a lot of reason in keeping it in tree if it's
unused and complicating e.g. the sysval upload path of the driver.
Indirect dispatch remains supported on v7, as that path *is* working and flipped
on for end users. Indirect dispatch on v7 is considerably less complicated than
indirect draws.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20420>
Folding signed or unsigned i32 -> i16 conversion into sampling
instruction causes it to behave differently with out-of-bounds
values. The conversion expects higher bits being masked, however
folded variant does clamp the value.
A concrete example is that:
isaml.base0 (u16)(x)hr0.x
is not equal this:
isaml.base0 (u32)(x)r0.w
(sy)cov.u32u16 hr0.x, r0.w
Fixes misrendering in "Injustice 2".
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7869
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20396>
Some HW may be able to fold only some of dst types, e.g.
for Adreno folding i32 -> i16 could cause a different result since
folded variant clamps the result instead of masking it.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20396>
Linear PE causes a lot of issues in the ZS stage. While some of those issues
can be worked around on newer GPU cores by doing all ZS operations in the
late stage, GC600 r4653 exhibits spurious Z fails when linear PE is active
even though this GPU does not even have a early Z stage.
Disable linear PE for now, until the issue can be analyzed further. Leave the
debug option in place to allow to enable linear PE for testing.
Fixes: 43eb5e777e ("etnaviv: add debug option to disable linear PE feature")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20405>
Because commit b9403b1c47 moved dispatch enable handling away from the
compiler, the drivers must ensure correct dispatch enable values. This
is handled by the intel_set_ps_dispatch_state function.
v2: Fix gfx6 build and use brw_fs_get_dispatch_enables for gfx6 in
crocus
v3: Rebase, use intel_set_ps_dispatch_state, drop gfx6 handling
Fixes: b9403b1c47 ("intel: factor out dispatch PS enabling logic")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20267>
Jobs are failing almost immediately with :
Cleaning up project directory and file based variables
ERROR: Failed to cleanup volumes
ERROR: Job failed: exit code 1
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20421>
This makes the downloaded artifacts reflect the content of the folder
as generated by the job.
In this the case of vkcts, this removes from the downloaded artifacts
the log files that were deemed uninteresting by deqp-runner.
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20415>
These files are relatively big (amounting to ~4.5GB for one run) but
are not really useful.
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20415>
This fixes an issue when conditional rendering and multiple views
were used with a task+mesh draw call.
Fixes: 2479b62869
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/20098>
Currently, LAVA jobs only show metadata when successful, let's show this
info in all retries to make it easier to debug or report issues.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20051>
To debug the LAVA jobs locally, we have an option in the
lava_job_submitter script to ignore the JWT token to make it possible to
retry jobs without the need to get an unexpired token.
But this trick needs to modify the overlayed directory so that we would
need to download and extract it earlier in the run.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20051>
LAVA splits the DUT log lines with `\r` in them. Unfortunately, it
breaks the Gitlab section line syntax when the HWCI script calls it
since it is a oneliner.
This commit changes the` fix_lava_gitlab_section_log` function to a
stateful generator that can merge lines that respects two consecutive
patterns.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7703
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20051>
LAVA uses XMLRPC to send jobs information and control, more specifically
it sends device logs via YAML dumps encoded in UTF-8 bytes.
In Python, we have xmlrpc.client.Binary class as the serializer
protocol, we get the logs wrapped by this class, which encodes the data
as UTF-8 bytes data.
We were converting the encoded data to a string via the `str` function,
but this led the loaded YAML data to use single quotes instead of double
quotes for string values that made special characters, such as `\x1b` to
be escaped as `\\x1b`.
With this fix, we can now drop one of the hacks that fixed the bash
colors.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20051>
