We can use this to specify the maximum vertex index that can
be accessed, which the hardware will use to detect and prevent
out-of-bounds accesses to vertex buffers.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29425>
When programming the size, we should take into account the
offset from the start of the index buffer address.
cc: mesa-stable
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29425>
This layer was blocking Android emulated ASTC support as it did not
take "emu_astc_ldr" in to account.
Cc: mesa-stable
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Tested-by: Mi, Yanfeng <yanfeng.mi@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29415>
LLVMContextr is not thread safe. There are many code paths that use
llvmpipe_context::context and adding locking to all of them is
difficult and adds unnecessary overhead. This approach restricts locking
to lp_sampler_matrix, which makes covering all uses of the LLVMContext
easy and only adds overhead when running lavapipe.
Fixes: 7ebf7f4 ("llvmpipe: Compile sample functioins on demand")
Reviewed-by: Roland Scheidegger <roland.scheidegger@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29397>
Before VK_KHR_maintenance5 point size is undefined unless the
shader explicitly writes it, but this extension changes this and
expects a default point size of 1.0 if none has been written.
We accomplish this by emitting a POINT_SIZE packet with the
default point size the first time we draw with a POINT primitive
in the job. If the shaders used in the draw call doesn't write
point size then the hardware will take the point size from the
state set by the packet. If the shader does write to point size
then the value written in the shader will be used instead.
Passes all tests we support in:
dEQP-VK.rasterization.primitive_size.default_size.points.*
when forcing maintenance5 enabled.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29413>
If the shader writes point size, then the compiler needs to ensure it
writes it in the appropriate vpm output slot and also clamp its value to
expected limits. This is why we have the per_vertex_point_size in the
shader key, so it doesn't really make sense to set this if the shader
doesn't write point size.
If the shader record flags that the shader writes point size then the
hardware will use the shader written value to override point size state
(set with the POINT_SIZE packet), so again, we really only want to set
this in the shader state record if the shader actually writes its value.
While we could also limit this to point primitives, since these are the
only primitives where point size has an effect, this is not really
required, and skipping this allows us to use the same shader with any
primitive type (otherwise we would have to compile 2 different shaders).
Finally, this change makes the vertex shader setup for point size match the
one we had been doing for geometry shaders, so it makes both stages behave
consistently regarding point size behavior.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29413>
The stress counter after enable_job(retry), often stores the new status
instead of the job complete. So, the summary printed later doesn't show the
real evolution of the test.
Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29416>
Because of the differences between i915 and Xe KMD this function is
needed to abstract the special handling that Xe KMD needs while
reading perf stream.
This special handling will be implemented in the next patch.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29421>
To be more explicit lets have 2 macros one with sample lenght other
with header and sample length.
This will also help add Xe KMD support as it don't have a header like
i915.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29421>
drm_i915_perf_record_header requires i915_drm.h but we want to remove
all i915_drm.h includes from common code, so replacing it by
intel_perf_record_header.
No changes in behavior expected as the structs and enums are identical.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29421>
This is a i915 specific struct and Xe KMD will not need anything like
that so lets allocate it in heap memory.
This will help us remove the i915_drm.h includes from common code.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29421>
More code will be moved to i915 specific files in the next patches.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29421>
read_oa_samples_until() was returning OA_READ_STATUS_ERROR even
if already read samples, then it tried again and KMD returned 0/empty
or EAGAIN(as the read would block).
This is not causing any issue because read_oa_samples_for_query()
FALLTHROUGH OA_READ_STATUS_ERROR to OA_READ_STATUS_FINISHED
but that I think it is worthy to fix it.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29421>
If we arent in a renderpass, but still wanna start the time elapsed
query(eg. to figure out how long some random operation will take) then
this seems to fix that case.
Signed-off-by: Yusuf Khan <yusisamerican@gmail.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29411>
The copy from old buffer is only needed when appending (when
decode_bitstream is called more than once in one frame).
This avoids map old buffer -> memcpy to new buffer which can get
expensive with large buffers.
Reviewed-by: David (Ming Qiang) Wu <David.Wu3@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29318>
This patch resolves the problem by modifying the for loop condition
to ensure that it stays within the bounds of the array (i.e., i < 4)
Signed-off-by: Cong Liu <liucong2@kylinos.cn>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25446>
Adress an implicit function declaration error by ensuring that DRM-dependent
functions are only compiled when HAVE_LIBDRM is set.
Fixes: 59813ae468 ("wsi: Add common infrastructure for explicit sync")
Signed-off-by: Valentine Burley <valentine.burley@gmail.com>
Reviewed-by: Joshua Ashton <joshua@froggi.es>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29267>
Only mapper4 supports u_gralloc_get_buffer_color_info(), other gralloc
implementations do not. So add a fallback, so that we aren't telling
the app that the suggestedYcbcrModel is RGB_IDENTITY. We only go down
this path for YUV formats.
Fixes android.graphics.cts.BasicVulkanGpuTest#testBasicBufferImportAndRenderingExternalFormat
Fixes: 8732a619f1 ("vulkan/android: Add common vkGetAndroidHardwareBufferPropertiesANDROID")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Roman Stratiienko <r.stratiienko@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29391>
This instruction is so restricted that encode_alu() really isn't gaining
us much so we may as well just type it out. Also, the bindless version
is quite a bit different and doesn't follow the ALU patterns so it'll
make more sense to do it this way long-term.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29393>
Adding with +0 is technically fine because the other source has abs()
applied and a non-negative value added to +0 is a no-op. However, copy
propagation won't detect that properly as of a43e6addca ("nak: Fix
fneg to do fadd(-0, x)")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29393>
Since Piglit buildsystem changes, we know it's already available
in all images anyway as we build with Wayland by default.
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29370>
