This decreases overhead of si_update_shaders and overall driver overhead.
The VS shader key portion related to VS inputs is updated in set & bind
functions. Other fields related to outputs are still updated
in si_shader_selector_key.
Now that all modified fields are set to 0 when not needed, and remove
the memsets.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12343>
This decreases overhead of si_update_shaders and overall driver overhead.
There is only one function that depends on the rasterized primitive type,
and thus it can't be moved to set & bind functions.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12343>
In addition to a global skip list introduced in
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11333
(enabled by
https://gitlab.freedesktop.org/anholt/deqp-runner/-/merge_requests/4)
it is also useful to have a per-driver skip list in addition to a
per-gpu list. Now, there are multiple levels at which skips can be
specified, from least to most specific,
- (deqp|piglit)-all-skips.txt :: affecting all tests
- (deqp|piglit)-$(DRIVER_NAME|VK_DRIVER|GALLIUM_DRIVER)-skips.txt ::
affecting the specified driver
- (deqp|piglit)-$GPU_VERSION-skips.txt :: affecting a specific GPU
This idea could be useful for -fails.txt as well.
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Martin Peres <martin.peres@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11426>
While it doesn't immediately hang like on a660, it seems to be buggy and
the blob disables it.
This fixes a bunch of r8_* dEQP-VK tests, which seem to pass
individually but don't work when run after other tests. For example this
fixes failures running dEQP-VK.pipeline.sampler.*.r8_uint*.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12830>
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>
Marek Olšák
Mike Blumenkrantz
Charlie Turner
Connor Abbott
Tomeu Vizoso
Danylo Piliaiev
Kenneth Graunke
Dave Airlie
Jordan Justen