The query result resource will be written to by the host, so we have to
declare it as dirty if we want to see the change.
Fixes: 9279a28f0 (virgl: ARB_query_buffer_object support)
v2: Update expectations in CI
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23121>
This is a one-line wrapper, so let's just use the v3d_X or v3dX macros
instead.
Acked-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23172>
This is a one-line wrapper, so let's just use the v3d_X or v3dX macros
instead.
Acked-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23172>
This is a one-line wrapper, so let's just use the v3d_X or v3dX macros
instead.
Acked-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23172>
Improve readability by using an auxiliar
struct v3d_device_info *devinfo = &screen->devinfo;
this was triggered by the use of the v3d_X macro, where just having a
devinfo makes is more friendly. As we are here, we used it on other
places of the code.
Acked-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23172>
this adds indexing for ssa/reg defs with the accompanying current
type of a given def (inaccurate for objects but whatever), enabling
that type to be used directly in order to avoid bitcasts in some places
this upends the assumption that all stored srcs are uint type
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22934>
it's not necessary to check whether dynamic states are set before
the null checks since any issues there would be VU errors
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22236>
has_work controls whether a flush can be deferred, i.e., when unset
a flush may be deferred
since a promoted cmd must still be flushed to take effect, ensure this
is always set when promoted cmds are pending
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23035>
when needs_present_readback is set, reordering is disabled without hitting
the path that would normally disable promotion for the resource, so this
needs to be changed manually to avoid layout desync on the swapchain
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23035>
resources use a private refcount to avoid overhead from atomics on
descriptor binds, but this has the side effect of evading batch usage,
meaning that the usage may not be properly removed once the batch state
is reset, which will cause issues with detecting whether usage exists
for a given resource
to fix this, the mechanism for tc fence disambiguation can be reused,
namely adding the batch state's submit count to the usage info and
then using that to add a second set of comparisons such that it becomes
possible to check both whether the batch usage for a resource matches
a given batch AND whether the batch usage is the current state of the
batch
affects:
KHR-GLES3.copy_tex_image_conversions.required.cubemap_posy_cubemap_negz
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23035>
in a scenario where an ordered read op occurs for an image,
successive read-only barriers SHOULD be able to be promoted
...but they can't, because there isn't yet a mechanism for handling layout
transitions between the unordered cmdbuf and the ordered cmdbuf,
meaning that promoting e.g., a SHADER_READ_ONLY barrier after a TRANSFER_SRC
barrier will leave the image with the wrong layout for the transfer op:
TRANSFER_SRC(unordered) -> COPY(ordered) -> SHADER_READ_ONLY(unordered)
becomes
TRANSFER_SRC(unordered) -> SHADER_READ_ONLY(unordered) -> COPY(ordered)
ideally I'll get around to figuring this out at some point
affects:
dEQP-GLES31.functional.copy_image.non_compressed.viewclass_32_bits.r32i_r32i.texture2d_array_to_renderbuffer
Fixes: bf0af0f8ed ("zink: move all barrier-related functions to c++")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23035>
This gives us ARB_polygon_offset_clamp and EXT_polygon_offset_clamp, and
most of the actual state plumbing was already in place.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23169>
OpenGL has a goofy feature that allows creating an image view of a single layer
of an array texture... in which case that image is treated as non-arrayed in
shader. If you have a 16x16x16 3D texture and bind the third layer, you get a
16x16 2D texture instead of a 16x16x1 3D texture. That distinction matters to
the hardware on AGX, since the texture dimension needs to match between the
shader and the pipe_image_view. If the shader is going to use image2D, we need
to know that the pipe_image_view should be treated as 2D (even though the
underlying resource is 3D).
"But, Alyssa, we already have first_layer and last_layer. Surely you can just
check if first_layer == last_layer?" you ask. The problem is that doesn't
distinguish a 16x16x1 3D texture (accessed as image3D in the shader) from a
16x16 slice (accessed as image2D in the shader) of a 16x16x16 3D texture. To
solve, we add a boolean flag indicating we want to create a view (with a lower
dimension than the underlying resource). This provides an unambiguous way to
communicate this case to drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23142>
in the case where a draw is triggered after a flush, zink_update_descriptor_refs
will be called to set batch tracking for descriptors. this function also
handles refs for fb attachments, and everything is usually fine there
the problem with this approach is that tracking is no longer set on view
objects at renderpass begin, which makes them susceptible to early deletion
if a rp isn't started from a draw call
instead, apply batch tracking to fb attachment resources on renderpass
begin if the BATCH_CHANGED flag is set (need to rename this at some point)
in order to guarantee that the resource (object) lifetime will match the
cmdbuf runtime [since imageviews are now only freed upon batch completion]
fixes#9059
Fixes: f6bbd7875a ("zink: remove batch tracking/usage from view types"
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23132>
For Zink.
This marks one piglit test as expected failure because polygon
smoothing can't be implemented properly in Vulkan.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21587>
Now that we've dropped macOS support in the driver, this is all dead code and
gets garbage collected.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23138>
When intel_ioctl(DRM_IOCTL_XE_EXEC) fails it returns -1 sets errno
with the fail reason.
This fail reason is than is used to know if engine was banned in
context_or_engine_was_banned().
Not adding a fixes tag because Xe is not enabled by default.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23139>
C++17 is the project-wide default since f9057cea51 ("fix(FTBFS):
meson: raise C++ standard to C++17"), so let's drop these local
overrides.
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23048>
