As Xe requires engine info, it is not possible to fetch max priority
from anv_physical_device_get_parameters() call chain, so here
anv_xe_physical_device_max_priority_update() was added.
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/22058>
Xe engine is not equal to hardware engine, it is just a submission
queue that will be scheduled in the hardware engine during process
time slice of the GPU.
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/22058>
Using the value that is not dependent on the KMD uapi.
Not marking as a fixes because both have the same value, so we
don't need a backport.
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/22058>
Add some set macro defines for mesh shading packets.
The naming convention is:
S_(packet opcode)(dword index)_FIELD_NAME
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/21409>
Now with fixed ccache 4.7.5.
`ccache` changelog:
Disabled the inode cache by default again since there have reports of ccache
processes hanging on futex calls related to the inode cache.
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22037>
When stencil is enabled and it isn't non-op, Early-Z must be disabled.
The condition that checks this for stencil[0] is correct, but the one
for stencil[1] is wrong: it uses an "and" instead of "or" condition.
This affects dEQP-GLES3.functional.fragment_ops.interaction.basic_shader.14
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22081>
Also fixing the max URB entries for VS stage.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reported-by: Chuansheng Liu <chuansheng.liu@intel.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21949>
Mainly for nir_load_smem_buffer_amd which pass i32 for this parameter.
Fixes: 8030fbcf16 ("nir,ac/llvm: add nir_load_smem_buffer_amd")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22043>
The mediump lowering tests are important for poking at the lowering pass
behavior, since you can't really assert the behavior in any given driver,
given that the GLSL spec allows any mediump op to be done in highp.
But, in hacking on mediump lowering, I wanted several things that the old
test couldn't do:
- Be able to assert about the actual NIR code we expect to generate for a
hypothetical driver (important if other compiler stages might do invalid
transformations like eliminating highp temps, or if we were to move the
lowering after GLSL IR)
- Run faster (gtest unit tests rather than python forking off the standalone
glsl compiler per testcase).
- Express expectations with a lot less escaping of typical syntax.
- High-quality logs for displaying failures.
This new test does all of that, I think, though I haven't converted all of
the unit tests over yet. In converting, I dropped some of the
combinatorial explosion for float/int variations, instead only doing so
when it gets at some different code path (default precision flags). I've
also included some new tests I wrote in the process of writing my proposed
gl_nir mediump lowering.
Even if the conversion isn't complete, getting these tests to run faster
is probably a good idea on its own, for anyone iterating running Mesa's
unit tests (80 tests in 25ms, compared to 109 tests in 1.5s!).
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21886>
We set the "mode" to 1 for CS because we want CP_SET_DRAW_STATE to
immediately execute the state groups. But in the 3d path, we don't
restore the value in the sysmem path. This was causing GPU faults
on 7c3 and presumably other a6xx gen4 things. But somehow not on
a6xx gen1.
Let's just set it as part of initial state restore where we are
ensuring that the GPU is in a sane state.
Fixes: dec49ec50a ("freedreno/a6xx: Move CS state to PROG state group")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22080>
This reverts commit bc04e2daca that handled the change as a WA while
this is about a new feature, change done in message layout. Patch also
changes the original comment to not refer to Wa but bspec page.
Fixes: bc04e2daca ("intel/fs: use generated helpers for Wa_1209978020 / Wa_18012201914")
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Mark Janes <markjanes@swizzler.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22068>
KHR-GL46.multi_bind.dispatch_bind_image_texture has been failing on
both Navi10 and VanGogh, so let's document that.
Zmike says he could not reproduce the fails on a newer version of
glcts, so the next release should address this issue.
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22055>
As part of https://gitlab.freedesktop.org/tanty/mesa-valve-ci/-/jobs/38416444,
we saw the following flakes:
- dEQP-VK.dynamic_rendering.primary_cmd_buff.basic.2_cmdbuffers_resuming
- dEQP-VK.dynamic_rendering.primary_cmd_buff.basic.contents_secondary_2_primary_cmdbuffers_resuming
- dEQP-VK.pipeline.fast_linked_library.extended_dynamic_state.two_draws_static.topology_line
And the following failure (seen 4/4 times in the run):
- dEQP-VK.draw.dynamic_rendering.primary_cmd_buff.linear_interpolation.offset_min_2_samples,Fail
Samuel told me that these are usual flakes, so let's document all of them.
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22055>
Compilers are free to make the assumption that pointers don't violate
strict aliasing. If that assumption is incorrect, as it is with the
framebuffer pointer packing code here, the job can fail.
This depends heavily on the compiler and optimization levels, so it's
hard to reproduce, but it did happen for at least two users running with
-O2 on gcc.
Fixes: 67cbbf9417 ("panfrost: Use framebuffer pointer XML")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8627
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21991>
With the weston idle-time issue fixed, these no longer timeout and
can be enabled again.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22012>
