Currently, the LAVA job submitter fetches the job results from the LAVA
XMLRPC call, but that is not necessary, as the job result is easily
found in the logs. E.g. the bare-metal and poe jobs uses that log to set
the final job status of their runs.
Another reason for the change is that the LAVA signals are not reliable
in some devices with one serial port, causing some troubles in a618
recently. So, if one signal fails to be sent/received, the job will
ultimately fail even when the hwci script has been successful.
Fixes: #6435
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16425>
this existed in order to reset query pools in advance so they
would never overflow. now the pools are reset every time the query
is started, so this behavior is no longer necessary
fixes#6475
Fixes: 57dd05616f ("zink/query: rewrite the query handling code to pass validation.")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16484>
Fix clip distance shadow copy writemask as the shadow copy
includes clip distances to all clip planes whether enabled or not.
Fixes spec@glsl-1.30@execution@interpolation@interpolation-*distance
Reviewed-by: Neha Bhende <bhenden@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16481>
Previously it would fail, and then we'd fall back to the transfer path
for things like readpix. But it would spam logcat w/ bo_mmap fail
messages. Since gralloc allocated buffers for GPU usage are allocate
without _USE_MAPPABLE, let's just assume we can't map imported bo's.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16477>
We no longer emit STATE_BASE_ADDRESS in every batch on XeHP, so the
decoder might not know what the various base addresses are if it's only
looking at a single batch. Fortunately, they also never change, so we
can just emit them once here.
On earlier platforms, initializing them here should be harmless. We'll
emit STATE_BASE_ADDRESS if we change them, which will update these.
Thanks to Iván Briano for catching this.
Fixes: 8831cb38aa ("anv: Stop updating STATE_BASE_ADDRESS on XeHP")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16287>
This allows to run most of the fossils we have right now. I will fix
up scratch in upcoming patches.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16369>
The API-style representation of descriptors is no longer used by
anything so let's get rid of it. All we really need is the data in the
descriptor set itself.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16276>
All we were doing was copying panvk_descriptor structs around which
don't actually contain data that's used by anything interesting. We
need to copy the actual data arround. Annoyingly, that means we need a
descriptor copy function per descriptor type. Woo!
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16276>
The new design is based on the ANV code which I massively cleaned up
some time ago. Each descriptor type has a write function and they have
consistent prototypes. This makes it all much easier to read and figure
out what's going on. It also makes it easier to make changes going
forward because you aren't re-plumbing function arguments if you ever
change the type of data in any given descriptor type. You just change
the write function.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16276>
Now that our SSBO descriptor handling code no longer craws deref chains
back to the variable, we should be handling variable pointers properly.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16276>
Instead of storing SSBO pointers in the very limited sysval space, store
them in the UBO we've attached to the descriptor set. This gives us a
virtually unlimited number of SSBOs. Dynamic SSBOs still live in the
sysval space so we can update them as part of vkCmdBindDescriptorSets().
Also, the new code (based on the code in ANV) loads those SSBO addresses
in a way that never chases the deref chain back to the variable so we
should now be able to handle all of variable pointers. The code as
written in this patch is a bit overly generic because it switches on
address modes a bit more than panvk needs but we ended up needing all
that flexibility in ANV so we may as well leave hooks for it in panvk.
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16276>
The original intention was to put all the non-dynamic UBOs first
followed by all the dynamic ones. However, we got the calculations
wrong and, once you went above one descriptor set, things start stomping
each other.
Also, the whole strategy is a bit busted. Vulkan pipeline layout
compatability rules say that it's ok to create a pipeline with one
layout and then bind with another so long as the bottom N descriptor set
layouts match and the pipeline uses at most N descriptors. This means
that, while it's safe to have each subsequent set add onto a given pool
of descriptors, if you're going to combine two of those pools, you need
to be careful that the position of descriptors in set N only depends on
the layouts of sets M <= N. The easy way to do this is to interleve
where we do the UBOs for set 0 then dynamic for set 0 then UBOs for set
1 then dynamic for set 1, etc.
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16276>
In theory, this may cost us a tiny bit of descriptor space but in
practice, given that the viewport transform is a sysval, we'll always
need it for 3D and given that SSBO pointers live there, we'll basically
always need it for compute. It also makes a lot of things simpler.
We're about to start using the sysval UBO directly in our descriptor set
code and knowing the index up-front is really nice.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16276>