When dealing with debug logging, it's useful to track when an object's
construction is finished and it's now visible to the client. We can
detect this pretty easily by setting a flag the first time foo_to_handle
is called. As long as drivers only ever call that function at the end
of object construction (they all do to my knowledge), this should be a
reliable mechanism for detecting when a client knows about a handle.
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
This is an attempt at simplifying the spirv_to_nir() backend when it
comes to choosing between system values and input varyings. Let's patch
drivers to do the sysval to input varying conversion on their own so we
can get rid of the frag_coord_is_varying field in spirv_to_nir_options
and unconditionally create create sysvals for FragCoord, FrontFacing and
PointCoord inputs instead of adding new xxx_is_{sysval,varying} flags.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Suggested-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Hyunjun Ko <zzoon@igalia.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13017>
Gallium caches sampler states for TBOs. Now if a buffer is first
attached to a TBO specifying one format, and later attached by
specifying another format and this TBO is then used, that would lead
to an assertion failure in debug builds, or to invalid rendering in
release builds, because the TBO picks the original, wrong format for
the sampler view.
Resolve this by signalling the change to Gallium (and other drivers), so
that Gallium clears the sampler view cache.
Fixes: f0ecd36ef8
st/mesa: add an entirely separate codepath for setting up buffer views
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13230>
Doing this copy using SDMA frees up the dGPU to do more
interesting things while the copy is happening; for instance
the rendering of the next frame.
hw queue activity before:
------------------------
dGPU:
gfx: [renderframe 1][copy->iGPU][renderframe 2][copy->iGPU]...
iGPU:
gfx: [Xorg] [Xorg]
hw queue activity before after:
------------------------------
dGPU:
gfx: [renderframe 1][renderframe 2][renderframe 3]....
sdma: [copy->iGPU] [copy->iGPU] [copy->iGPU]
iGPU:
gfx: [Xorg] [Xorg] ...
If SDMA isn't available or can't do the copy, use an async compute
context instead.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12763>
SDMA support was dropped in 1f31a21664 mainly because the
advantages of delegating some copy/clear operations to the
SDMA hw came with large drawbacks: CPU overhead due to the
sdma/gfx synchronization and hangs.
This commit restores SDMA support for all gfx7+ chips but
only for the image copy operations.
SDMA operations won't be intertwined with gfx operations
like before. Instead, a SDMA IB will contain a single copy
at a time and the synchronization will be handled by the
winsys (based on the used buffers).
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12763>
The old REVIEWERS file was useful back in the mailing lists days, but
nowadays we use GitLab, and we tag people by using their usernames, not
email addresses.
Most of us know each other's usernames by now, but documentation like
this is not meant for us but for everyone else, so that they can talk to
us.
Let's convert the file into GitLab's CODEOWNERS format, which maps files
in the repository to GitLab users that people can look up or tag in
their issues or merge requests.
See also: https://docs.gitlab.com/ce/user/project/code_owners.html
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2178>
v2: Use u_foreach_bit64() (Samuel)
v3: Add missing handling of VkMemoryBarrier2KHR in pNext of
VkSubpassDependency2KHR (Samuel)
v4: Remove unused ANV_PIPELINE_STAGE_PIPELINED_BITS (Ivan)
v5: fix missing anv_measure_submit() (Jason)
constify anv_pipeline_stage_pipelined_bits (Jason)
v6: Split flushes & invalidation emissions on
vkCmdSetEvent2KHR()/vkCmdWaitEvents2KHR() (Jason)
v7: Only apply flushes once on events (Jason)
v8: Drop split flushes for this patch
v9: Add comment about ignore some fields of VkMemoryBarrier2 in
VkSubpassDependency2KHR (Jason)
Drop spurious PIPE_CONTROL change s/,/;/ (Jason)
v10: Fix build issue on Android (Lionel)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9045>
One of the unfortunate effect of Vulkan starting to use 64bit bitmasks
is that they can no longer be defined using enums because C doesn't
guarantees that enum values will be 64bits.
Vulkan therefore started using those patterns :
static const VkAccessFlags2KHR VK_ACCESS_2_INDIRECT_COMMAND_READ_BIT_KHR = 0x00000001;
This has the effect that we can not longer use those values in
switch/case statements.
This change introduces defines so that we can keep doing this. For now
only VkAccessFlags2KHR/VkPipelineStageFlags2KHR are allowed to be
redefined this way, this list could be changed later (or all bitmask
could be processed this way).
v2: Generate hexadecimal numbers (Jason)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9045>
Jason Ekstrand