If descriptor heap is used, there's no pipeline layout created. So we
have to patch compute and RT pipelines to allow it. Graphics pipeline
doesn't need the change because of GPL.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39762>
There're potential optimizations available for below:
- vkWriteSamplerDescriptorsEXT
- vkWriteResourceDescriptorsEXT
- vkGetPhysicalDeviceDescriptorSizeEXT
- vkRegisterCustomBorderColorEXT
...and we can revisit if there's perf hit from above for real apps.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39762>
On the ppc64le architecture error log fail to compile with error:
../src/virtio/vulkan/vn_renderer_virtgpu.c: In function ‘virtgpu_ioctl_map’:
../src/virtio/vulkan/vn_renderer_virtgpu.c:751:66: error: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 6 has type ‘__u64’ {aka ‘long unsigned int’} [-Werror=format=]
751 | "mmap failed: gpu_fd=%d, handle=%u, size=%zu, offset=%llu, err=%s",
| ~~~^
| |
| long long unsigned int
| %lu
752 | gpu->fd, gem_handle, size, args.offset, strerror(errno));
| ~~~~~~~~~~~
| |
| __u64 {aka long unsigned int}
cc1: some warnings being treated as errors
Parse the parameters to fix the failure.
Fixes: a49b7adad8 ("venus: add error log coverage for virtgpu backend")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39775>
Those have long been supported by vn_image_deferred_info_init because of
AHB support. For non-aliased ANB image, those are directly passed from
the platform swapchain create info as well. So we just need to drop the
obsolete asserts to make newer Android platform and ANGLE happy.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39750>
WSI used to track the similar for aliased wsi image creation, but later
got deprecated. So let's rename wsi.memory to wsi.anb_mem and drop
wsi.memory_owned to avoid confusions with common wsi related trackings.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39401>
Vulkan is supposed to operate in explicit synchronization mode. However,
for legacy compositors that only support implicit fencing, we have to
extract the compositor implicit fence (release fence) and resolve it
properly.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39401>
Previously common wsi has a special submission to install implicit fence
to wsi memory directly, which has been deprecated in favor of bonfire
implicit fencing (implicit fencing has been turned into explicit fencing
within vulkan since then). The virtgpu backend is fine but the vtest
backend has been regressed since then, only relying on renderer side hw
driver doing implicit fencing.
With async present landed earlier, we can directly tell which submission
is done by common wsi, and can revive the idle waiting accordingly.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39377>
ANV can return different memory requirements with and w/o the ALIAS bit.
See https://gitlab.freedesktop.org/mesa/mesa/-/issues/14671 for details.
Meanwhile, venus has a driver side cache for image memory requirements.
As blessed per spec for memory aliasing, venus strips the ALIAS bit when
populating the cache key. Because of the use of imageless mem req query,
the ALIAS mem req now can hit the cache first, leaving a smaller/relaxed
requirement in the cache...busted.
Venus is unable to fix ANV behavior behind the scene, so this workaround
is only to align Venus behavior with ANV to not suffer from Venus-only
rendering artifacts.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39368>
As mentioned in earlier commit, for sem fd export on async present
thread, it occurs after internal queue submissions for all swapchains.
So we can allow queue commands while sync wait w/o violating ordering.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39283>
For sem fd export on async present thread, it occurs after internal
queue submissions for all swapchains and before presenting to WSI
backend. We can safely unlock the chain acquire lock though we still
have to lock against chain destroy as well as chain async present on
other queues.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39283>
Brief:
1. present info is deep-copied and passed to async present thread
2. normal queue present always waits for async present to take over
3. queue access is protected by async present queue lock
4. chain access is protected by chain locks
5. no perf gain in practice since we haven't allowed parallel queue
submit or acquire image yet
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39283>
During async presentation, swapchain is accessed by the async present
thread. With proper queue and chain access locks within venus driver,
we still have to rely on mesa common wsi implementation specifics for
optimal async present performance:
Below need to be protected:
- vkAcquireNextImage2KHR
- vkDestroySwapchainKHR
Below are safe:
- vkGetSwapchainImagesKHR
- vkWaitForPresentKHR
- vkWaitForPresent2KHR
- vkReleaseSwapchainImagesKHR
- VkSwapchainPresentFenceInfoKHR::pFences
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39283>
When suboptimal is returned, the fence payload is missed to be installed
unexpectedly. Instead, we can directly return errors from sync import.
With this change, dEQP-VK.wsi.xcb.maintenance1.release_images.* can pass
robustly now.
Fixes: a312bb4285 ("venus: refactor wsi acquire to use semaphore and fence SYNC_FD import")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39283>
The prios aren't consistent when guest and host are different OS'es.
Even if they are the same, sometimes the forwarding can hit other
permission issues. The entire ring prio thing has to be redesigned, and
before that we just disable it on Windows.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38969>
