We are using unnamed arrays to describe repeating portions of a pm4
packet. So allow the name to be optional. Instead of just using
the empty-string hack, drop the attribute.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6107>
We have already been using this to describe pm4 packets that are
specific to certain generations.
Maybe we should introduce a new "packet" element type instead. But
first lets just get validation working with what we already use.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6107>
We are already using non-hex offsets to describe pm4 packet payloads.
Let's just permit this in the schema, rather than updating all the xml
to use hex.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6107>
In the schema, boolean means strictly "true" or "false". But rnn
parsing code was looking for "yes"/"1"/"no"/"0". So split the
difference, and add a relaxed boolean type, and update rnn to also
accept "true" or "false".
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6107>
Ideally we'd like to express that *either* 'high' + 'low' OR 'pos' is
required, but it doesn't appear that this is possible. But the rnn
parsing code should still enforce this.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6107>
For testing Mesa on LAVA devices with the amd64 architecture, build
kernels and rootfs in the same way as we do for arm64 and armhf.
Also add a few trivial jobs for a specific AMD Chromebook.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Rohan Garg <rohan.garg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5903>
As we are doing that in several places already and we'll need to build
in others as well.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Rohan Garg <rohan.garg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5903>
master-tot doesn't have that zip file any more, but the just made
release still does.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Rohan Garg <rohan.garg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5903>
So we can get an idea if what are the bottlenecks when looking for
opportunities to speed things up.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Rohan Garg <rohan.garg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6101>
I'm seeing occasional unexpected 403 errors when uploading artifacts.
Print the response in case MinIO is telling us why.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Rohan Garg <rohan.garg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6101>
We'll need this for finding where INDIRECT/STRIDE are in
CP_DRAW_INDIRECT_MULTI, since they are in different locations in each
variant.
This is tricky because we need to bubble up success/failure to the upper
levels, and 0 could be a valid offset if the stripe is inside an array
or in a packet. Hence we refactor tryreg to return success/failure
separately, although I stopped short of modifying rnndec_decodereg
itself.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6104>
This was being packed as 1-src and so the Src1 was not set up properly.
It only worked by accident.
Signed-off-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6111>
Most ops use the common handling in emit_alu in order to convert NIR
sources to bifrost sources, but the "special" math op lowering handrolls
the conversion (due to needing to reference the same source multiple
times).
Unfortunately, that handrolled lowering did not consider that there
might be a non-identity swizzle on the source. In this case we would
reference the wrong component of the source and generate garbage.
Fixes all but two of the remaining failures on G31 in:
dEQP-GLES2.functional.shaders.operator.exponential.*highp*
The following tests are still broken due to some other issue:
dEQP-GLES2.functional.shaders.operator.exponential.exp2.highp_float_fragment
dEQP-GLES2.functional.shaders.operator.exponential.exp2.highp_vec2_fragment
Signed-off-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6108>
NIR doesn't have atomic loads/stores, so we have to workaround that with
this for dEQP-VK.memory_model.* to pass.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4905>
Lower them to ACCESS_COHERENT to simplify the backend and
probably give better performance than invalidating or writing back the
entire L0/L1 cache.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4905>
Once we start going through the free list of the descriptor set pool,
we might use a free entry larger than the descriptor set we want to
allocate. When we free that descriptor set, we use the size of the set
rather than the size of the entry that was picked. This leads to leaks
of some amount of descriptor set pool.
This fix saves the size of the entry in the descriptor set so we know
what amount of the pool needs to freed.
v2: Don't bother adding a new size field
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Cc: <mesa-stable@lists.freedesktop.org>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3324
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6084>
Volume textures don't have a concept of "layers"
v1: set last_layer to zero for 3D textures (Axel Davy)
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com>
Reviewed-by: Axel Davy <davyaxel0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5808>
Otherwise mesa will crash in glEndPerfQueryINTEL because OA BO is NULL.
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Mark Janes <mark.a.janes@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6094>
Otherwise mesa will crash in glEndPerfQueryINTEL because OA BO is NULL.
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Mark Janes <mark.a.janes@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6094>