The spec says that VkGraphicsPipelineCreateInfo::pTessellationState is
ignored and may be an invalid pointer in some cases. When ignored,
patch the pCreateInfo with `pTessellationState = NULL`, so the encoder
doesn't attempt to encode an invalid pointer.
Tested in Borealis, with debug build of venus, with a minimal test app
that sets `.pTesselationState = 0x17`. Pre-patch, the app crashes;
post-patch, the app works.
Signed-off-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16284>
We currently do only a single fix. Prepare to do multiple independent
fixes.
Signed-off-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16284>
Layering clients, e.g. angle and zink, use wide sets of buffer usage
flags because they don't know what a resource will be used for in the
majority cases, which is on the other hand making it easier for layering
to optimize resource management.
This change adds a super-set usage to the buffer cache entries, that
will mostly ensure no cache-miss for non-sparsed buffer usages. Since
that involves usage bits from extensions, we'll mask out those disabled
ones upon querying but will use the static cache create info for
checking cache hit for code simplicity.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16379>
extended_dynamic_state.*_raster tests timeout because the new
VK_DYNAMIC_STATE_RASTERIZER_DISCARD_ENABLE is not handled in venus.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16222>
This syncs up with the protocol of what eventually landed in virglrender.
1) Move all static params to capset to avoid having to query host
(reduce synchronous round trips at startup)
2) Use res_id instead of host_handle.. costs extra hashtable lookups in
host during submit, but this lets us (with userspace allocated IOVA)
make bo alloc and import completely async.
3) Require userspace allocated IOVA to simplify the protocol and not
have to deal with GEM_NEW/GEM_INFO potentially being synchronous.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16086>
If supported by host virglrenderer and host kernel, use userspace
allocated GPU virtual addresses. This lets us avoid stalling on
waiting for response from host kernel until we need to know the
host handle (which is usually not until submit time).
Handling the async response from host to get host_handle is done
thru the submit_queue, so that in the submit path (hot) we do not
need any additional synchronization to know that the host_handle
is valid.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16086>
There's below AHB VU on the image view:
VUID-VkImageViewCreateInfo-image-02399
If image has an external format, format must be VK_FORMAT_UNDEFINED
This is well hidden and completely missed from the original venus ahb
implementation.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16159>
Towards the renderer, venus better uses VK_EXT_image_drm_format_modifier
to force linear with tiling modifier and mod_linear. Doing so won't make
any difference on the mesa implementations we care about given we have
required VK_EXT_image_drm_format_modifier for wsi support.
A lucky side effect of this is to allow common wsi to work with host
implementations not supporting dma_buf export.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15993>
WSI images and Android AHBs can have tiling modifier overrides, thus we
must override the aspectMask upon image subresource layout query.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15993>
These are the changes automatically generated from the venus-protocol
repository.
Update the file to add `VK_EXT_index_type_uint8` and
`VK_EXT_conditional_rendering`
Signed-off-by: Igor Torrente <igor.torrente@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15652>
We're trying to replace VK_OUTARRAY_MAKE() by VK_OUTARRAY_MAKE_TYPED()
so people don't get tempted to use it and make things incompatible with
MSVC (which doesn't support typeof()).
Suggested-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15522>
Add a new backend to enable using native driver in a VM guest, via a new
virtgpu context type which (indirectly) makes host kernel interface
available in guest and handles the details of mapping buffers to guest,
etc.
Note that fence-fd's are currently a bit awkward, in that they get
signaled by the guest kernel driver (drm/virtio) once virglrenderer in
the host has processed the execbuf, not when host kernel has signaled
the submit fence. For passing buffers to the host (virtio-wl) the egl
context in virglrenderer is used to create a fence on the host side.
But use of out-fence-fd's in guest could have slightly unexpected
results. For this reason we limit all submitqueues to default priority
(so they cannot be preepmted by host egl context). AFAICT virgl and
venus have a similar problem, which will eventually be solveable once we
have RESOURCE_CREATE_SYNC.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14900>
Based on profiling, these 10us sleeps are behaving closer to ~60us
and causing higher-than-necessary CPU overhead. 120us seems like a
good balance between latency management and overhead.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15565>
Update venus-protocol files to move vkGetCalibratedTimestamps function
from vn_protocol_driver_transport.h to vn_protocol_driver_device.h.
Signed-off-by: Igor Torrente <igor.torrente@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15389>
Several `vn_Cmd` share the same code to enqueue the command to the
command stream.
This adds a macro with this common code.
Signed-off-by: Igor Torrente <igor.torrente@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15344>
