We never implemented it, and having broken mipmaps works out better
for applications and CTS. Actually implementing stencil adjust is
going to be a major pain due to stuff like the GENERAL layout.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21869>
The zap shader knows the offset of the embedded shader within the zap
sqe instructions, but uses this control reg to get it's own address in
memory, in order to calculate the address of the compute shader part of
the zap shader.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21748>
Before SLM fence compiler needs to insert SYNC.ALLWR in order to avoid
the SLM data race.
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22050>
At ring creation, if supported by renderer, we can request
ringMonitoring. During driver ring waits, the ring's new ALIVE status
bit will be checked periodically at the configured rate. If the bit is
not set, the renderer must have crashed and the driver should do the
same to signal a problem to the app/user.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22036>
This reverts commit dda85cf94b ("venus:
move exp features init back to use ring submit"), and additionally adds
per stream shmem caching to determine when vkSetReplyCommandStreamMESA
is needed.
Checking renderer features before setting up ring means that the bound
shmem for replies on the ring will no longer be implicitly set on first
shmem creation (it was set for the renderer stream instead). So the
test for when another vkSetReplyCommandStreamMESA is needed must
independently consider the last stream set on renderer/ring(s)
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22036>
Use a new calling contract so we can do pre/post-work around every ring-waiting
iteration. All looping uses of `vn_relax()` must now call `vn_relax_init()` and
`vn_relax_fini()` before/after their loop bodies.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22036>
Disable tessellation distribution when primitive id is enabled.
v2: some changes squashed from Tapani:
- leave mode initially as TEDMODE_OFF (0) so we can merge
- take fs primitive ID overrides in to account
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21982>
Performance jobs should work better if we fix the device under test to
be the same in every test, instead of using any device from a group of
devices of the same type.
We can do it quickly in LAVA, but it seems more
complicated on Google's farm. So, let's replace the a630 (in Google
farm) with a fixed a618 device to test freedreno traces performance.
Add a618-traces job as well, as we need to confirm that a618 is
generating stable traces with good results before proceeding to track
its performance
Co-authored-by: David Heidelberg <david.heidelberg@collabora.com>
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22065>
Explicitily define the caching proxy via piglit
`--download-caching-proxy-url` argument.
We have different URLs for caching proxy for LAVA and freedreno farms.
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22065>
.lava-test hidden job was setting the HWCI_TEST_SCRIPT variable to deqp
runner. But that is not always the case. When we run piglit traces jobs,
we use piglit-traces.sh instead, for example.
Splitting into:
- .lava-test-deqp (deqp-runner + deqp)
- .lava-traces (deqp-runner + piglit)
- .lava-piglit (piglit-runner + piglit)
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Co-authored-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22065>
We filter out traces that work only in standard replay mode but not
profile one via yq (jq for YAML) manipulation.
The previous query needed to be fixed in some scenarios, such as traces
labeled with only `["no-perf"]`, which was being ignored by the query.
This commit updates the yq query with newer syntax to cover all current
cases (at least for freedreno).
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22065>
A new property was added to drm_xe_query_config with the max engine
priority for running process, so we can use it directly on
anv_xe_physical_device_get_parameters() and nuke
anv_xe_physical_device_max_priority_update().
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/22112>
To replace the hard-coded values.
Not fully importing gpu_scheduler.h because it includes several Linux
specific headers that will make the life of anyone porting Xe to
other Unix harder.
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/22112>
Based on commit f6e26dff8fa3 ("drm/xe: Add max engine priority to xe query")
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/22112>
mpv didn't ask to be on this list, was never consulted about being
on this list and to the best of my knowledge has no problem with
adaptive sync. If there is an issue exposed by mpv having adaptive
sync enabled, then it should be reported to mpv, so that it can be
fixed in mpv.
The only problem I could remotely imagine with mpv and VRR is that
its display-resample mode tries to do something similar, and the
two mechanisms will likely race each other to the bottom, but the
display-resample mode is not the default and this is already a
known issue on Windows so users wouldn't expect this to behave any
differently on Linux.
In short, please don't try to make a list of all applications that
are not video games, it is not conducive to having a good time on
the computer.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20701>
We don't provide executable properties for the prolog shader.
Fixes: f123d65e9f ('radv/rt: use prolog for raytracing shaders')
Fixes: dEQP-VK.pipeline.monolithic.shader_module_identifier.pipeline_from_id.ray_tracing_libs.*
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22111>
The goal is to make radv_shader_create() a function that creates a shader
from a binary without any additional information.
Postprocessing the config is only needed after compilation.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22029>
Faith Ekstrand
Bas Nieuwenhuizen
Rob Clark
Mike Blumenkrantz
Sagar Ghuge
Ryan Neph
Guilherme Gallo
David Heidelberg
José Roberto de Souza
Nicolas F
Daniel Schürmann