This works by copying the input headers at the beginning of the output
bitstream buffer. VPS/SPS/PPS are still written by driver and slice
headers are written by FW, but all other headers are directly copied
from application input.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30927>
Add PIPE_VIDEO_CODEC_UNIT_LOCATION_FLAG_SINGLE_NALU to set
VA_CODED_BUF_STATUS_SINGLE_NALU for each segment.
Always set this flag in d3d12 to keep the old behavior.
Reviewed-By: Sil Vilerino <sivileri@microsoft.com>
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30927>
Make all packed headers received from application available
to drivers. Add emulation prevention bytes if the packed header
was sent without them, so the driver will always get the headers
with emulation prevention bytes and is able to directly copy them
to output bitstream as is.
Reviewed-By: Sil Vilerino <sivileri@microsoft.com>
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30927>
Prevent the accidental passing of 0 components or bits, as it makes no sense.
Cc: mesa-stable
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Suggested-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31103>
By default we have to take into account that the application could set
offsets, or that one kernel launch won't fit into a single hw dispatch.
In order to mitigate the overhead it causes at kernel runtime, and because
those things are in most cases irrelevant, we compile an optimized kernel
making a few assumptions.
We also make use of the the workgroup_size_hint as an additional
optimization.
This should speed up relatively small kernels significantly as it can cut
the instruction count in half for those.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30152>
If we allow this whenever the extension is supported by the driver, we
end up allowing out-of-spec behavior for instance on GLES 1.x.
So let's tighten these checks to consider the current API, by using the
new helpers.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31039>
We don't want to expose GLSL versions above what should be exposed for
the current API, otherwise we allow out-of-spec behavior.
This is unlikely to have any real-world effect, because most of the
time, the version is the highest supported. It's only if the version is
artificially limited that this should matter.
But it's also a bit cleaner this way.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31039>
Instead of recreating the packets in the DGC prepare shader, the best
solution is to emit them to a temporary CS object at pipeline creation
time. Then in the DGC prepare shader, the driver just needs to copy
the packets.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31101>
When VK_PIPELINE_CREATE_2_CAPTURE_DATA_BIT_KHR is set, implementations
shouldn't store pipeline data to an internal cache.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30812>
The Vulkan spec says:
"disableInternalCache can be used to disable the driver’s internal
cache, allowing an application to take full control of both memory
and disk usage."
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30812>
This change was wrong but there is nothing testing this. For example,
if we have a pipeline with VS+GS+FS and DGC only updates push constants
for VS. On GFX9+, VS is merged to GS, so the VS push constants info
would be zero and nothing would be emitted.
This reverts commit 45319cb253.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31099>
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>
This caused GLX applications to segfault under zink.
This technically also fixes cleanup when any driver fails init
Signed-off-by: Sid Pranjale <mail@sidonthe.net>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31072>
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>
To avoid confusion with the vtn_pointer::deref that is a NIR deref. New
name comes from description of OpTypePointer, where is described as the
"type of the object pointed to".
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>
If there's difference between scan_inst dest type and inst src type we
should be more careful, because difference in signedness can cause
incorrect results after the propagation.
Updated ror-default.trace hash, as the change fixes misrendering there.
Fixes: b23432c5 ("intel/fs: Fix a cmod prop bug when the source type of a mov doesn't match the dest type of scan_inst")
Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30998>
