When use LA464(3A5000 pc), LLVM18 and kernel(which not supports lsx/lasx),
it will get a illegal instruction error. LA464 will return LA464 and
LA664 will return a generic when calling getHostCPUName(). Return LA464
name will add all feature(+f,+d,+lsx,+lasx,lvz) by default and generate
vector instruction, generic will add null. Hence we use util_get_cpu_caps
to judge if kernel supports lsx/lasx or not.
Set lsx and lasx by util_get_cpu_caps. Only LLVM 18 on loongarch
supports lsx and lasx completely. LLVM 16 isn't supported and
LLVM 17's LSX support is incomplete.
Signed-off-by: Jiale Zhao <zhaojiale@loongson.cn>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30220>
Although we don't want to rely on hwconfig for devinfo->verx10 == 120,
due to the dependence on closed source software, we do check to see if
hwconfig reports different values in the DEVINFO_HWCONFIG macro.
Matt was seeing this warning on 8086:a7a0:
> MESA: warning: INTEL_HWCONFIG_TOTAL_PS_THREADS (128) != devinfo->max_threads_per_psd (64)
Reported-by: Matt Turner <mattst88@gmail.com>
Fixes: 3e4f73b3a0 ("intel/dev: Update hwconfig => max_threads_per_psd for Xe2")
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31077>
Now there's a single vtn_type associated with a vtn_pointer, so
discard the qualifier.
After this and previous changes, here's a summary of where/what types
are:
```
struct vtn_pointer *p;
p->type; // type of this pointer
p->deref; // NIR deref of this pointer (unchanged)
p->type->pointed; // type of the object pointed by this pointer
```
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31069>
This can be obtained by the pointer type (currently at ptr_type). For
the cases where there wasn't an user provided type for that, now create
an internal vtn_type. This can happen when creating intermediate
vtn_pointer for complex loads/stores/copies.
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31069>
The TGL PRM says,
This bit should never be programmed to 0
So, set it to true. I chose not to use the MBO attribute in genxml
because the field lacks the "Format: MBO" line in the PRM.
We previously made this programming conditional with commit 2e1be771e4
because of tests failing in
dEQP-GLES3.functional.texture.specification.tex*depth*. However, those
failures were fixed when we started using gl_FragDepth for depth buffer
copies in commit 6cec618e82.
Note: when bisecting this, I cherry-picked commit 7a68045b5d in order
to get past build failures related to a deprecated python function.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31066>
Optional const allocations (preamble, UBO, etc.) may shift the required
consts (e.g. driver params) more than they expect.
The free space for optional allocations should respect the aligment of
required consts that come after them.
Example: there are maximum 100 vec4 consts, driver params take 4 units,
something else takes 1 unit. Now premable thinks that there is 95 free
units, however driver params cannot start at offset=95 it has higher
aligment.
Fixes some d3d12 games.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31027>
SC2319 is actually helpful! It's telling us that in:
foo="$(bar)"
[ -n "$foo" ] && ret=$?
ret actually gets us the return code from [ which is by definition zero,
instead of the return code from bar that we wanted.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30978>
This was the only thing running shellcheck and pytest. Unsurprisingly,
tons of them regressed whilst it was gone. Since these have now been
moved to other jobs, we can just bring back debian-build-testing in the
non-critical-path stage if we drop LTO, so let's do that as there hasn't
been any movement towards fixing it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30978>
The following things needed to be fixed:
- lp_build_tiled_sample_offset has to use the block size of the
underlying 3D texture. Remaining calculations use the dimensions of
the view since the z-coordinate is undefined and has to be ignored.
- The layer offset must be calculated using llvmpipe_get_texel_offset.
Fixes: d747c4a ("lavapipe: Implement sparse buffers and images")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31038>
anv_tests tries to create a large number of threads, all of which wait
to be able to execute simultaneously, then launch a reasonable-size
workload.
Under load, cloning each of the 16 threads takes 15ms serially, for a
delay of 240ms before the tests start running; running the test 64
times gives us 15.36s for a single testcase in isolation, assuming that
the bits which aren't forking are free.
To give it the best shot at completing in time, mark it as a
non-parallelisable test (since Meson will also try to parallelise it
out), and also halve the number of runs it attempts. And then give it a
longer timeout so it doesn't fail even in extremis.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31059>
For example, if the application wants to create linked shaders with
VS/TCS/TES but the next stage of TES isn't present, the driver would
have to compile shader variants (ie. nextStage could be NONE,TES,GS).
This isn't supported by RADV without re-compiling all shaders twice,
and it's also likely less optimal than compiling unlinked shaders.
This fixes recent CTS
dEQP-VK.shader_object.link.linked_linked_linked_unlinked_unlinked.*
Fixes: 37d7c2172b ("radv: add support for creating/destroying shader objects")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31062>
Jiale Zhao