And use it in jobs for images using another Mesa image as their base.
Should fix the build of images which don't use another Mesa image as
their base (by no longer setting the FDO_BASE_IMAGE variable).
Fixes: 0781d9825b "ci: Append $MESA_TEMPLATES_COMMIT to image tags"
Acked-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Andres Gomez <agomez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7957>
This fixes the build of images which use another Mesa image as the base.
v2:
* Move $CI_REGISTRY_IMAGE expansion into FDO_BASE_IMAGE assignment as
well (Dave Airlie)
Fixes: 0781d9825b "ci: Append $MESA_TEMPLATES_COMMIT to image tags"
Reported-by: Dave Airlie <airlied@redhat.com>
Acked-by: Eric Anholt <eric@anholt.net> # v1
Reviewed-by: Andres Gomez <agomez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7957>
VK spec got clarification about the pSizes parameter.
Fixes set of new tests:
dEQP-VK.pipeline.extended_dynamic_state*with_offset*
v2: move offset subtract to be part of size calculation (Jason)
CC: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3871
Fixes: b9a05447a1 ("anv: dynamic vertex input binding stride and size support")
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7439>
This is more or less just compile-tested, but this seems about right to
me. I see the extension being supported when running on top of Zink,
which makes me happy enough for now ;)
v2: fixed up to copy the structs on pipeline create [airlied]
gallium doesn't support the 0 divisor case yet.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7930>
This isn't an integer, it's an enum, We need to support
VK_EXT_vertex_attribute_divisor if we want to support using values other
than 0 and 1 here.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7930>
We have to store every struct that is in the pipeline for processing
later, use ralloc to make freeing this mess easier.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7978>
We need to pick 1u vs 1.0f based on the type of the texture, just like for
normal samples. Move the decision up to the create_sampler_view, and use
that value from both sampler paths.
Cc: mesa-stable
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8012>
sgpr_count is unused. The size of the others is too small.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7939>
Instead of computing the number of color buffers in the start binning
function, just use the job's nr_cbufs, which already contains that
value.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8006>
For line primitives, the provoking vertex selection is done through the
DRAW.flat_shading_vertex field and PRIMITIVE.first_provoking_vertex must
be set to true.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7923>
Midgard has to split the writeout instruction if the number of bits per
pixel exceeds 128. We thus need to take the number of samples into
account when creating blend shaders.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7984>
Some MSAA+fmt combination require writeout to be split. Right now, it
only impacts blend shaders since we only support MSAA 4x, and the only
formats that could exceed the 128bit/pixel limit in MSAA 4x are
not supported by the fixed-function blend unit. We thus rely on the
blend shader to split things properly. Things will change once we add
MSAA 8x/16x to the mix, since even the blendable formats will exceed
the 128b/pixel limit in that case.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7984>
Commit 64d6f56ad2 ("panfrost: Allocate syncobjs in panfrost_flush")
aimed at optimizing the fencing logic but it looks it also broke the
fence-based synchronization in subtle ways.
Indeed, now that the fence only waits on a single syncobj, we're not
guaranteed that all jobs queued in panfrost_flush_all_batches() will
be done when the fence is signaled, because jobs at the top level
(those stored in the batches hashmap) have not inter-dependencies.
Commit 9e397956b0 ("panfrost: signal syncobj if nothing is going to
be flushed") made this even more apparent by signaling the fence right
away if nothing was left to be drawn in the current context, thus
ignoring any of the batches left to flushed in the ->batches map.
If we want to keep relying the existing kernel APIs there's clearly no
ideal solution here. We can either go back to the original fencing
mechanism where each fence contained an array of syncobjs to be tested
or serialize jobs that have no explicit dependencies so we know the last
submitted job will also be the last one to return. The orginal approach
has proven to add quite a significant overhead (caused by the amount of
ioctls and the time spent in kernel space to gather dma fences attached
to those syncobjs and test them). So let's go for the simple solution
where we have a single syncobj bound to the context which we update to
point to the last job out_sync every time we submit a top-level job.
This approach implies reworking the way we create fences since we
need to capture the syncobj state at the time the fence is created.
Unfortunately, there's not SYNCOBJ_CLONE ioctl, which forces us to
export/create/import a fence so we have a new object that's not
subject to changes done to the context syncobj.
If we want to further optimize the logic, we should probably explore
some of those options:
1/ Adding array based SYNCOBJ ioctls (SYNCOBJ_{CREATE,DESTROY,CLONE}_ARRAY)
so we can mitigate the cost of ioctls when we need to manipulate
arrays of syncobjs
2/ Support synchronization jobs. That is, jobs that have a NULL job chain
but an array of sync_in and a sync_out to allow creating
synchronization points
3/ Add syncobj aggregators so we only have to wait on one syncobj from
userspace. The syncobj aggregator would wait for all sub syncobjs to
be signaled before signaling the top-level one.
Fixes: 64d6f56ad2 ("panfrost: Allocate syncobjs in panfrost_flush")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7831>
We shouldn't reset the ->writer field when a reader comes in because we
want subsequent readers to have a dependency on the writer too. Let's
add a new field encoding the last access type and use it to replace the
writer != NULL test.
Reported-by: Roman Elshin
Fixes: c6ebff3ecd ("panfrost: Remove panfrost_bo_access type")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7831>