if this isn't supported, don't use rect-related sampling
cc: mesa-stable
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17714>
The CTS does a lot of 1x1x1 compute shaders (all that stuff like
dEQP-GLES31.functional.shaders.builtin_functions.precision.mul.highp_compute.scalar)
which finish with store_ssbos. Instead of doing the invocation loop in
that case (which LLVM has to later unroll), just emit the single
invocation's store.
Fixes timeouts running
dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.36, which does
a spectacular number of SSBO stores in a long 1x1x1 compute shader.
Reduces runtime of on llvmpipe from 66s to 29s locally, and virgl from
1:38 to 43s. virgl
dEQP-GLES31.functional.ssbo.layout.random.nested_structs_arrays_instance_arrays.22
goes down to 7 seconds.
Fixes: #6797
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17730>
RECT textures used to be required to be supported by drivers. But since
the state-tracker learned how to lower these to 2D textures, some
drivers no longer support them.
While we have lowering in place for this, lowering it involves some
needless overhead. So let's just use a 2D texture instead of a RECT
texture.
Because having two versions and switching between them is more
complicated than it needs to be, let's just always use a 2D texture.
Similarly, let's just always multiply the reciprocal here, so we don't
have to test for PIPE_CAP_TGSI_DIV first.
Cc: mesa-stable
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17707>
The asserts that check the pointer element type can't be used on LLVM >= 15.
Instead of using precompiler #if, use boolean shortcut in assert.
Reviewed-by: Brian Paul <brianp@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17650>
This is needed for LLVM-15 opaque pointers.
The new variants taking the type are named with the suffix "2", using
the same naming pattern LLVM (e.g. LLVMBuildGEP2 vs. LLVMBuildGEP).
Reviewed-by: Brian Paul <brianp@vmware.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17650>
LLVM 15 requires transition to opaque pointers; factorize a bit the cache
memthods to help this transition.
Reviewed-by: Brian Paul <brianp@vmware.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17650>
As LLVM 15 transitions to opaque pointers, we need to update
the deprecated methods dealing with non-opaque pointers.
Reviewed-by: Brian Paul <brianp@vmware.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17650>
LLVM-15 enables opaque pointers by default. We temporarilly request
non-opaque pointers while we migrate our code to support non-opaque pointers.
This workaround needs to be removed before LLVM-16.
See #6615
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Kai Wasserbäch <kai@dev.carbon-project.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17514>
This allows a VMware test to pass. The comments in lp_bld_limits.h
mention SM 3.0 requirements, but we're in the SM 5.0 era...
Signed-off-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17062>
the EXT_external_object spec originally was underspecified with regards
to this function, leaving room for synchronization errors where:
* app calls SignalSemaphoreEXT to signal a semaphore
* mesa defers pipe_context::fence_server_signal with threaded context
* driver defers gpu submission
* SignalSemaphoreEXT has long since returned, app submits vk cmdbuf waiting on semaphore
* spec violation / device lost
to prevent this, the spec is being changed to:
1) require an implicit flush when calling SignalSemaphoreEXT
2) require that this implicit flush also forces GPU submission before SignalSemaphoreEXT returns
all affected drivers have been updated
fixes#6568
cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17376>
this is for drivers (like freedreno) which need the format in the sampler
state in order to accurately handle border colors
when set, drivers MAY receive a format in the sampler state if the frontend
supports it (e.g., nine does not), and the cso sampler cache will include
the format member of the struct
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17189>
Most drivers don't care about the property, and virgl should only handle
it if the host supports it.
This is a partial revert of b634030, i.e. we keep the definition of the
property, but we don't set it only based on the shader info.
Fixes: b634030542
tgsi: Add SEPARABLE_PROGRAM property
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17344>
TGSI has no legitimate[1] notion of linked shaders, which means tgsi_to_nir
should conservatively assume everything all shaders are separable. This requires
setting nir->info.separate_shader to warn drivers that shader CSOs might be
mixed and matched. Otherwise, the driver might enable optimizations that
are invalid for separate shaders, causing issues when the shaders are
later treated as separable.
This will fix varying linking with u_blitter's shaders on Panfrost (Bifrost and
older), when util_blitter_clear is used with Panfrost.
[1] There was a TGSI property added recently to forward
nir->info.separate_shader up to virglrenderer, but it's not actually used for
anything in virglrenderer and I am still struggling to understand what the use
case would be. My gut says we should revert b634030542 ("tgsi: Add
SEPARABLE_PROGRAM property"), but I'm not interested in fighting that yak right
now. Notably, the u_blitter and hud shaders are separable but are not marked
with this property.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17282>
This is hit using lavapipe with zink on top running
dEQP-GL45-ES31.functional.primitive_bounding_box.wide_points.global_state.vertex_tessellation_fragment.default_framebuffer_bbox_equal
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17270>
Ensure the argument name is serialized "state" not, "&tr_ctx->unwrapped_state".
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17107>
GL_MAP_UNSYNCHRONIZED_BIT depends on the app having its threading
handled correctly. This allows us to force disable the bit when
they get it wrong.
CC: 22.1 22.0 <mesa-stable>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17199>
[Alyssa: Add a default CPU implementation of pipe->clear_buffer(). This hook is
mandatory for OpenCL support. Even though this implementation isn't optimal by
any means, having a conformant default available in core will lower the barrier
of entry to OpenCL support.]
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16044>
It is now unused. We cannot yet remove the streamout functionality in u_blitter
as r600g still uses it for clear_buffer on GPUs older than Evergreen.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17142>
st/mesa will expose GL_ARM_shader_framebuffer_fetch_depth_stencil
if this new capability is supported by the driver.
Signed-off-by: Pavel Asyutchenko <sventeam@yandex.ru>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13979>
Fix the transform to make sure it doesn't disturb the depth range
of the blitted image. Set the Z coordinates of the vertices
by hand instead of relying on the transform to do it.
This is a pre-requisite to Zink always enabling depth clamping.
Fixes: 26c6640835
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16929>
this is for drivers like zink that may or may not
handle dithering and so getting blend state changes
when this state changes isn't useful
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17043>
Mike Blumenkrantz
Emma Anholt
Erik Faye-Lund
Marek Olšák
Mihai Preda
Dave Airlie
Sil Vilerino
Konstantin Seurer
Brian Paul
Kai Wasserbäch
Jesse Natalie
Georg Lehmann
Jason Ekstrand
Gert Wollny
Alyssa Rosenzweig
Jose Fonseca
Timothy Arceri
Pavel Asyutchenko
Timur Kristóf