to complement BITSET_CALLOC for when you want a memctx in there.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38245>
The sm8350-hdk devices have been fixed in the lab with help from
Qualcomm.
Also adjust the parallelism of the job, as we're still within the time
limit with just 2 devices instead of 3.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38239>
Some new CTS tests have geometry shader looking like this :
void main()
{
gl_Position = gl_in[0].gl_Position;
EmitVertex();
EndPrimitive();
// <-- some storage buffer write
}
The generate shader has :
- a message to write the position
- a message to write to the storage buffer
- a final message to end the thread
This generates an empty EOT URB messages which is apparently not legal
(simulation complains, HW hangs) :
send(8) nullUD g126UD nullUD 0x04088007 0x00000000
urb MsgDesc: offset 0 SIMD8 write masked mlen 2 ex_mlen 0 rlen 0 { align1 1Q A@1 EOT };
Instead emit a write with actual data and the mask set at 0 to discard
the effect :
mov(8) g127<1>UD 0x00000000UD { align1 WE_all 1Q };
mov(8) g125<1>UD 0x00000000UD { align1 1Q };
send(8) nullUD g126UD g125UD 0x04088007 0x00000040
urb MsgDesc: offset 0 SIMD8 write masked mlen 2 ex_mlen 1 rlen 0 { align1 1Q A@1 EOT };
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38243>
This commit changes SSA based spilling of values in loops.
As described in the paper by Hack, W_entry should consider which values
are used inside of the loop since we would really like to avoid spilling
those because we need to do so every loop iteration.
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38181>
The Vulkan spec change hasn't been released yet but the VKCTS test
is public, so let's merge the fix to make VKCTS green again locally.
Fixes dEQP-VK.shader_object.tessellation.*.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38209>
Moved helper functions for binary upload and dump
code from si_shader.c to new file si_shader_binary.c
Signed-off-by: Saroj Kumar <saroj.kumar@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38166>
This is a framebuffer fetch for blend equation advanced lowering. We're
using a binding table index as the offset, which is not a slot.
Also, validate the shader after setup_binding_table so that we catch
errors here at the right place, rather than deeper in the compiler.
Acked-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38231>
Now that lavapipe sparse resource support on external memory has been
fixed, expose sparse resource support from venus on lavapipe. Meanwhile,
make remaining failures explicit (failed in lavapipe as well).
This CL also drops an obsolete comment and updates expectations from
full nightly runs.
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38074>
Store a dup fd for OPAQUE type as required by sparse binding. Use
os_map_memory_fd_placed to handle binding for opaque fd backed memory,
while the unbind will still correctly share the same code path with
other cases. This adds sparse resource support with OPAQUE type in
addition to DMA_BUF, and venus no longer has to hide sparse resource on
lavapipe.
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38074>
Since it early returns, refactor our with a dedicated helper for
cleaness and to prepare for further refactors.
No behavior change involved.
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38074>
This is mainly to ensure internal anonymous file based memory allocs do
not collide with opaque fd type. Since we are here, add INVALID type and
assign to non-Linux internal alloc.
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38074>
This completes the opaque fd api coverage, and is needed by lavapipe for
sparse binding support with opaque fd external memory.
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38074>
This change:
1. add new helpers to handle dmabuf alloc/import/free
2. use FREE to match with alloc macro
3. simplify opaque fd code path
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38074>
There's already the type, and there's no concurrent usage of fd and
dmabuf fd, so just drop it. This fixes sparse resource to work with
dmabuf external memory for lavapipe. In addition, this makes sparse
resource from venus on lavapipe to work with dmabuf backing.
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38074>
This change:
1. Move size validation within sparse binding, but not escape to
non-sparse code path.
2. Error out if sparse is requested on unsupported platforms.
Fixes: d747c4a874 ("lavapipe: Implement sparse buffers and images")
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38074>
Not the most optimal solution but 64-bit vertex attributes are rarely
used. Could still revisit if we find a real use case that matters.
This fixes recent VKCTS coverage:
dEQP-VK.pipeline.fast_linked_library.vertex_input.component_mismatch.r64g64b64.*_to_dvec2
dEQP-VK.pipeline.shader_object_.*.vertex_input.component_mismatch.r64g64b64.*_to_dvec2
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14243
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38237>
Most of the infrastructure was already in place for 8 bit (we just
had to add the AFBC mode to use). We also needed to add support for
the 10 bit format (X6R10X6G10_X6R10X6B10_UNORM). Note that this
10 bit format is only supported for AFBC, for linear we have to fall
back to the old multi-plane way of handling it.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35771>
When importing an image, check that the specific combination of
format plus modifier is supported, rather than just checking the
format. This will allow drivers to support some YUV formats in
special cases (specific modifiers, like AFBC for panfrost) while
also allowing us to fall back to generic multi-plane formats when
those modifier+format combinations are not supported by
hardware.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35771>
Including the 10 bit variant X6R10X6G10_X6R10X6B10_UNORM. Only the
RG_RB variants seem to have fourccs, so those are the only ones being
added for now, although they would, obviously, be easy to add).
These are used for Y210, Y212, and Y216 fourccs. In particular Y210
is interesting for panfrost, as it is the fourcc used to indicate a
10 bit single plane 4:2:2 encoded as AFBC (similar to how YUYV is
the canonical AFBC for 10 bit 4:2:0).
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35771>
We had assumed AFBC superblocks were always tiled in an 8x8 pattern,
but this is true only for 32bpp and lower formats; for larger formats
the pattern is 4x4. This isn't an issue yet, but will be when we
support R16G16B16A16 in AFBC.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35771>
This is required because otherwise dri2_get_modifier_num_planes will be
confused: dri2_get_mapping_by_fourcc gives the emulated 2 plane YUYV,
but panfrost itself supports a hardware single plane YUYV. This is
arguably a problem with dri2, but other drivers have implemented
dri2_get_modifier_num_planes so we may as well. It also gives us a
hook for supporting more exotic planar configurations, should that
be necessary in the future.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35771>
