In the future, we're going to have "real" BOs representing GEM objects,
and "slab allocated" BOs suballocated out of a larger BO. Many fields
are properties of the real underlying BO, but we may still want to ask
about an arbitrary BO, and have the accessor chase answers down as
necessary.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12848>
When I wrote this code originally, I decided to try and construct the
validation list up front, rather than at submission time. That worked
okay, but it's not really necessary. It's a fair amount of data to
store (struct drm_i915_gem_exec_object2 is 56 bytes per object), when
we can easily construct it on the fly.
More importantly, with suballocation, batch->exec_bos[i] may have
multiple entries corresponding to a single validation list entry.
Rather than tracking two lists with an awkward mapping between them,
we choose to just store the BO list and generate the other on the fly.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12848>
When we start suballocating BOs, multiple logical BOs may map to the
same GEM object, and thus share a validation list entry. However, we
want to track whether logical BOs are written, to avoid unnecessary
cross-batch data dependencies.
Just track that in a bitfield instead, where bit i corresponds to
batch->exec_bos[i].
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12848>
batch->validation_list[] will be going away shortly, but exec_bos[]
will live on. bo->index is the index into both lists, so we can just
refer to the one we're not about to delete.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12848>
gallium needs pipe_surface::context to reflect the context used to create
the surface, but zink caches surfaces, so instead return a wrapper object
that can be destroyed without blowing up the stack
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12843>
this is a partial barrier, so having access of any kind is invalid
VUID-vkCmdPipelineBarrier-srcAccessMask-02815(ERROR / SPEC): msgNum: 618171435 - Validation Error: [ VUID-vkCmdPipelineBarrier-srcAccessMask-02815 ] Object 0: handle = 0x2834530, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x24d88c2b | vkCmdPipelineBarrier(): .pImageMemoryBarriers[0].srcAccessMask bit VK_ACCESS_TRANSFER_READ_BIT is not supported by stage mask (VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT). The Vulkan spec states: The srcAccessMask member of each element of pMemoryBarriers must only include access flags that are supported by one or more of the pipeline stages in srcStageMask, as specified in the table of supported access types (https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VUID-vkCmdPipelineBarrier-srcAccessMask-02815)
Objects: 1
[0] 0x2834530, type: 6, name: NULL
zink DEBUG: ERR: 'Validation Error: [ VUID-vkCmdPipelineBarrier-srcAccessMask-02815 ] Object 0: handle = 0x2834530, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x24d88c2b | vkCmdPipelineBarrier(): .pImageMemoryBarriers[0].srcAccessMask bit VK_ACCESS_TRANSFER_READ_BIT is not supported by stage mask (VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT). The Vulkan spec states: The srcAccessMask member of each element of pMemoryBarriers must only include access flags that are supported by one or more of the pipeline stages in srcStageMask, as specified in the table of supported access types (https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VUID-vkCmdPipelineBarrier-srcAccessMask-02815)'
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12845>
It only makes sense to call this pass for fragment shaders, and the
first thing the pass does is read a FS-specific field out of a union,
so it isn't safe to call it for other shader stages.
We could make it early return, but instead we just assert, so that
drivers know to only call it when appropriate.
(A previous version of this patch, which early returned instead of
asserting, was Reviewed-by: Emma Anholt <emma@anholt.net> as well.)
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12839>
i965 called this pass unconditionally, while st/mesa only calls it for
fragment shaders. It only makes sense to run for fragment shaders, and
the first thing the pass does is read a FS-specific field out of a
union. This isn't safe for other stages.
Fixes about 20,630 test failures on i965 since 91dc863921, which moved
the advanced_blend_modes field. The field had previously been in a
union with no other fields, so it never aliased anything, and thus
worked, even if it was wrong. That commit moved it to a union that had
fields for other stages, so it started reading garbage and trying to
lower advanced blending for other stages on i965.
Fixes: 91dc863921 ("mesa: Move the advanced blend bitmask to shader_info.")
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12839>
this reduces the component key size for decomposition by up to 75%, down
to as low as 2 bytes, which is more optimal for both hashing and memcmp of
the key
it will become more useful as further changes are added to improve vertex format
support, enabling the keysize to remain relatively small
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12771>
`hasAttribute()` in `llvm::AttributeList` is gone, use `hasParamAttr()` instead.
This fixes an FTBFS.
Signed-off-by: Kai Wasserbäch <kai@dev.carbon-project.org>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12826>
This consolidates several duplicated pieces of code into devinfo.
max_scratch_ids is an array that provides the max number of threads
for the rendering and compute stages.
This fixes some exceptions missed by crocus for scratch ids on haswell
and cherryview.
It also fills out devinfo->max_scratch_ids properly for stages VS
through CS on Gfx12.5. But, functionally this should not make a
difference as Gfx12.5 already uses COMPUTE for all stages.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12799>
By default, Mesa's X11 Vulkan WSI will wait for buffers to be ready
before submitting them to Xwayland when the swapchain is created
with the IMMEDIATE mode.
This is undesirable when the Wayland compositor already monitors
fences. A Wayland compositor may want to know the delay between
the buffer submition and the end of the GPU work, this is impossible
to measure if the WSI waits for the buffer to be ready before
submission.
Since most compositors don't monitor fences, let's introduce a driconf
option for this for now. We can reconsider once more compositors
have better support for fences.
Signed-off-by: Simon Ser <contact@emersion.fr>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11290>
For drivers that don't lower advanced blend to FBFETCH, we need the
bitmask to be in the NIR shader so that it gets carried over to TGSI
successfully.
Reviewed-by: Rob Clark <robdclark@chromium.org>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12813>
this isn't the max per type, it's the max that can be used for a type,
which is the max used by a shader stage * the number of shader stages
Cc: mesa-stable
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12829>
Kenneth Graunke
Dave Airlie
Mike Blumenkrantz
Jordan Justen
Anuj Phogat
Marek Olšák
Kai Wasserbäch
Simon Ser
Emma Anholt
Rob Clark