non-generated tcs has unique mechanics in that it doesn't have a base shader key,
so split that out to avoid unnecessary complexity
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18135>
these values don't need to be checked at all if dynamic vertex is enabled,
which wouldn't previously have been possible without adding even more
data to check to the pipeline state
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18135>
this is one of the hottest paths in the driver, and having to load
a function variant with all the extra dynamic state paths is not optimal
when they can never be used
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18135>
We'll terminate the process if a context is lost, so we don't have any
other choice.
Reviewed-by: Mihai Preda <mhpreda@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17968>
This reverts commit 247b8f2924.
this attempted to work around what is likely a bug in nvidia's modifier
support, namely their refusal to expose LINEAR as a valid modifier for
some bizarre reason
cc: mesa-stable
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18148>
This reverts commit 49efa73ba1.
this happens to work with mesa (sometimes), but it's going to be
illegal most of the time since swapchain images are treated as though
they are created with OPTIMAL tiling
cc: mesa-stable
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18148>
In the past we were doing per-quad lod for cube maps (when no_quad_lod
wasn't set), however commit d413fd0219 ("gallivm: Always take the
per-pixel LOD path for cubemaps.") unconditionally enabled calculating
per-pixel derivatives.
However, the actual lod calculation was still only done per quad, which
probably doesn't make much sense, so unconditionally enable taking the
per-pixel lod path for cubemaps (for op_is_lodq we always force
no_quad_lod to false in any case so there's no difference there neither).
v2: adjust ci results accordingly
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18126>
Additionally add support for PIPE_CAP_CLEAR_SCISSORED since we are already
touching the scissor state.
Fixes various gnome-shell rendering artifacts.
v2: Remove NEW_SCISSOR as clear now updates scissor registers explicitly
v3: Reset scissor_off state since its not off now after clear
Cc: mesa-stable
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18137>
textureCompressionBC is just a short-hand to know is *all* BPTC formats
are supported. We're already checking per format, so we don't need this
coarser check.
Besides, it's also kinda wrong; textureCompressionBC also requires all
BC formats, not just BPTC. In other words, all DXT formats and RGTC
formats were missing from the check.
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17986>
Alpha-to-coverage acts like discard and happens after FS ends,
so like with discard LRZ write should be disabled.
With discard we don't know at the moment of binning whether
fragment would be not discarded, so we cannot write its depth to LRZ.
Cc: mesa-stable
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18102>
SPIR-V shift ops unlike NIR have undefined behavior if shift count
larger than or equalt to bitwidth.
This means that true translation of NIR ishl/ishr/ushr to SPIR-V requires
masking like that done in gallivm.
This was seen in the case of soft fp64 in cts case
KHR-GL46.gpu_shader_fp64.builtin.ceil_double.
Cc: mesa-stable
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18074>
Loading indirectly from a register that was just written to
doesn't work on R600 class hardware, so add a NOP group with
the address register load being emitted in the t-slot. to make
sure that the register write was finished.
Fixes: 33765aa92a
r600/sfn: Enable NIR for pre RG hardware
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18130>
On R600 and R700 class hardware the input declaration order maps
directly to the register the hardware writes the inputs to, so
make all interpolated inputs come first, and only then emit the
system values like POS or FACE.
Related: #7035
Fixes: 33765aa92a
r600/sfn: Enable NIR for pre RG hardware
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18130>
This reverts commit 23e5b910c5.
Reason for revert:
It's causing the regression for H264 transcoding. We will Enable EFC
once we verify all corner cases and as of now disabling
Signed-off-by: Ikshwaku Chauhan <ikshwaku.chauhan@amd.com>
Reviewed-by: Thong Thai <thong.thai@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17869>
KVM requires memory mapping to be aligned to page size, otherwise it
refuses to do the mapping. In particular this causes KVM mapping errors
when llvmpipe is used by virtio-gpu on host and guest tries to map buffer
that has a persistent mapping, i.e. it tries to map the llvmpipe's host
blob/buffer. Mesa virgl driver uses host blobs only for the buffers with
persistent mapping, hence let's align buffer allocations to the page size
when the persistence flag is set to fix the KVM fault.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Acked-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18053>
the non-negotiated path assumes that drivers know what implicit modifiers they're
using, but zink doesn't know what it's doing, so instead try to copy the
swapchain's modifier and reuse that since in theory it should work
Fixes: 247b8f2924 ("zink: add all format modifiers when adding for dmabuf export")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18095>
the spec mandates that all modifiers passed to the driver be valid, so
iterate through all of them and delete the invalid ones
Fixes: 247b8f2924 ("zink: add all format modifiers when adding for dmabuf export")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18095>
if srgb-ness isn't supported by the driver for dmabuf, bail out early with an
error message with the assumption that this would later (maybe) explode when
trying to create a view for srgb framebuffer
ref !17900
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18095>
The lp_rasterizer is shared across contexts, and lp_rast_fence called
without holding rast_mutex could race with rast_mutex being replaced and
unref'd on a different thread.
Fixes: a680fd078c ("llvmpipe: make last_fence a screen/rast object not a context one.")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18116>
Since PIPE_CAP_TGSI_TEXCOORD is now enabled, texcoord is now declared
as TGSI_SEMANTIC_TEXCOORD instead of TGSI_SEMANTIC_GENERIC.
Fixes assert running REDTurbineDEMO with MTL Renderer when the guest needs to
fallback to swtnl for line stipple.
Fixes: e73443b7a5 ("svga: enable PIPE_CAP_TGSI_TEXCOORD for vgpu10 and up")
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18113>
The majority of the logic here was for the Gfx8-9 sample-from-hiz
hardware feature, which only applies to AUX_USAGE_HIZ, and neither
of the combined HiZ+CCS modes. So, reorganize the function to put
the logic for each case in the case itself.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4674>
When using HIZ_CCS_WT, we always want to use that for texturing so that
we're able to sample from the CCS buffer, which will have the latest
data due to the write-through mode.
With the previous commit in place, HiZ now exists for all miplevels
on platforms which support HIZ_CCS_WT, so we no longer need the
per-miplevel checks.
The other restrictions in this function only apply to the Gfx8-9 feature
where the sampler directly supported reading from HiZ itself, which was
removed. Hardware where HiZ and CCS can be used together doesn't have
that feature nor its restrictions.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4952
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4674>
8x4 alignment was absolutely required prior to Gfx8, and while some
things were relaxed on Gfx8-9, Nanley's experiments in issue #3788
indicated that there were still issues on those platforms.
It appears that the restrictions were relaxed on Icelake and
non-8x4 aligned HiZ "should" work on Gfx11+.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4674>
