r300 and r400 have strict rules with swizzles, so we
will need to convert swizzle back.
Operating on 0, 1, H in this case unnecessarily makes
rest of r300 overly complicated.
(also it's not currently able to handle this)
helps with:
deqp-gles2@functional@shaders@random@exponential@fragment@24
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17117>
Starting with Valhall, the provoking vertex state is specified per-framebuffer
(batch) instead of per-draw. We use the pan_tristate infrastructure to translate
between desktop OpenGL's per-draw semantics to Valhall's per-framebuffer
semantic. This is notably not required for GLES or Vulkan.
If the provoking vertex is unset when the tiler context is generated, it could
be set (incompatibly) later in the batch, and the tiler context's provoking
vertex field would no longer match the framebuffer's. That would violate a
hardware invariant. To ensure that doesn't happen, we make sure to set provoking
vertexes *before* generating the tiler context so it can't change after.
Fixes arb-provoking-vertex-render on Valhall.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17068>
If we need to change batch state (currently just point coord origins), not only
do we need to flush the old batch, but also set the desired state on the new
batch. That second step was missing. Fix that so this mechanism works as
intended.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Fixes: 3641dfe436 ("panfrost: Flip point coords in hardware")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17068>
Even with the fixes in the rest of the series, arb-provoking-vertex-render is
still failing on Valhall for a single subcase (involving QUADS). It seems likely
that QUADS support is broken on Valhall, given it's not used in any of the APIs
for which Arm ships drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17068>
This commit extends the graphics hard coding infrastructure to
allow the independent hard coding of stages, i.e. hard code fragment
stage and vertex stage separately instead of having to hard code
everything.
It also extends the infrastructure to allow per device hard coding.
Signed-off-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Reviewed-by: Rajnesh Kanwal <rajnesh.kanwal@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17106>
To avoid dangling BO references if it's destroyed without being
previously unbound. This is under Vulkan spec clarification but it
looks like the "global" BO fix is simple enough to workaround the
issue for now.
This fixes a CPU hang with Halo Infinite because the kernel rejects
a submission (invalid BO handle found).
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17085>
there's no point in updating blend state for this when it does nothing,
so skip updates for this functionality
in the future, I expect zink will export this conditionally based on
the underlying driver, and some sort of functionality will be implemented
to do something
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17043>
This reverts commit 4824396572.
The newest version of b2c has changed the mount point of the cache
device, which is has proven to be working very well in my local
testing, but ends up confusing podman when the cache device had been
initialized using an older version of b2c. The end result is that we
end up using tmpfs to run our jobs, and some machines just run out of
RAM before the end of the job...
We'll be fixing this issue, cut a new b2c release, then re-introduce
in Mesa.
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17120>
We used to use WZYX and apply swizzles. Because swizzles apply for
border colors as well, the gallium driver un-swizzled the border colors
to cancel out swizzles. That did not work for turnip because turnip
advertises customBorderColorWithoutFormat and does not know when to
un-swizzle.
This change replaces WZYX by XYZW and removes the swizzles.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6516
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16647>
Whether a sync object is used cannot depend on where the batch is
submitted from, remove the in_sync and out_sync fields from
panfrost_batch_submit.
Always use an output syncobj, this is required for glFinish to work
correctly. This could be skipped for batches which another batch
depends on, but because of the existence of empty batches which emit
no job, doing so is not trivial.
Never use an input syncobj. There appears to be no point to this, the
kernel driver does implicit sync anyway.
Fixes "seconds per frame" rendering with Neverball; previously, every
batch was submitted with out_sync=0, so DRI's frame throttling could
do nothing. New jobs would keep getting submitted until more than a
thousand were queued in the kernel, which increased rendering latency
for the compositor far beyond acceptable levels.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16966>
PAN_BIND_SHARED_MASK is all binding flags that mean that a resource
might be shared and accessible by other contexts.
Don't replace the usage of this pattern in panfrost_should_afbc and
panfrost_should_tile in case a new binding is introduced that not all
layouts can support.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16966>
Filip Gawin