I wanted to find slow pieces of code in our Anv driver using our
drm-shim stub.
The last bit of code still talking to the compositor was the WSI
swapchain code and failing because none of the submissions are taking
place (because of the stub).
This change introduces a new variable MESA_VK_WSI_HEADLESS_SWAPCHAIN
which when set turns every swapchain creation into a headless
swapchain. This swapchain does not present anything, allowing the
application to spin as many frames as possible. Thus helping to
identify slow spots in command buffer building path.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6156>
vulkancts test dEQP-VK.wsi.direct_drm.surface.create_simulate_oom is failing
because in wsi_display_alloc_connector() function memory allocation for
connector is not checked for return NULL. create_simulate_oom test simulates
out of memory, hence memory allocation fails for connector and later when
tried to dereference connector program will segfault.
This patch fixes the dEQP-VK.wsi.direct_drm.surface.create_simulate_oom test
segfault issue by checking if connector is NULL afer memory allocation.
Cc: mesa-stable
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21701>
Destroy the surface dmabuf feedback proxy before destroying the event
queue that the proxy is attached to.
This silences a warning that libwayland 1.22 emits for programs that use
Vulkan/Wayland:
warning: queue 0x557a4efbcf70 destroyed while proxies still attached:
zwp_linux_dmabuf_feedback_v1@18 still attached
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21647>
The Vulkan Specification states about possible return values from
vkAcquireNextImageKHR:
* VK_NOT_READY is returned if timeout is zero and no image was
available.
* VK_TIMEOUT is returned if timeout is greater than zero and less than
UINT64_MAX, and no image beae available within the time allowed.
That is, if info->timeout is larger than zero, the function must return
VK_TIMEOUT instead of VK_NOT_READY if no image became available before
the timeout elapsed.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21190>
Depths 24 and 30 happen to have uniform bpc but 16 does not. Pull the
real channel width out of the format description instead. This is still
a bit ignorant of channel order though.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20673>
We set the different data being freed to NULL after freeing it, and
checks for NULL before freeing it.
This fixes several double free crash with v3dv, when running OOM wsi
tests, like for example:
dEQP-VK.wsi.xlib.swapchain.simulate_oom.composite_alpha
Although note that only one person got those on a new fresh install of
the Raspbian OS, so this problem was rare.
Fixes: 5b13d74583 ("vulkan/wsi/drm: Break create_native_image in pieces")
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20695>
Same thing as https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20530:
newly added `src/vulkan/util/rmv/vk_rmv_tokens.h` (see !17331) includes
`src/util/` files, so anything that includes it needs `idep_mesautil`.
In file included from ../src/vulkan/util/rmv/vk_rmv_common.h:29,
from ../src/vulkan/runtime/vk_device.h:26,
from ../src/vulkan/wsi/wsi_common.c:31:
../src/util/simple_mtx.h:34:12: fatal error: valgrind.h: No such file or directory
34 | # include <valgrind.h>
| ^~~~~~~~~~~~
compilation terminated.
Fixes: 5f30a7538b ("vulkan: Add RMV token definitions")
Signed-off-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Friedrich Vock <friedrich.vock@gmx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20642>
The CPU copy is horribly slow, so let's hook-up DXGI swapchains. Note
that we're still limited in term of features. For instance, we can't
support more than 2 images per swapchain because of the DXGI present
ordering constraint. We also have to do an extra copy, because DXGI
only allows rendering to a resource on the queue that the swapchain
was created against, but swapchains in Vulkan don't have a queue.
The swapchain is bound to the window using DirectComposition aka
DComp. The DComp infrastructure is set up in the surface, and is
transitioned from one swapchain to the next when the new swapchain
begins presenting.
Unlike Wayland and X, there's no requirement that the compositor has
to release a surface before you can start rendering against it. However,
since we're now supporting the non-sw path, we do need to prevent apps
from rendering to a resource *while* the blit is occurring. We do this
by blocking for a fence while acquiring an image.
Co-authored-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16200>
The win32 swapchain can be backed by a DXGI swapchain, but such swapchains
are incompatible with STORAGE images (AKA UNORDERED_ACCESS usage in
DXGI). So, we need to allocate an intermediate image that will serve as
a render-target, and copy this image to the WSI image when QueuePresent()
is called. That's pretty similar to what we do for the buffer blit case,
except the image -> buffer copy is replaced by an image -> image copy.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16200>
Right now, the WSI core supports copying WSI images to a linear buffer
for implementations that want the result in this form. This being said,
most of the blit logic can be re-used for image to image copies, and that's
exactly what we'll need if we want to hook-up DXGI swapchains in the
win32 WSI implementation. So let's rename a few fields so we no longer
imply that images are copied to a buffer, and the use_buffer_blit boolean
an enum so we can extend the implementation to support image -> image
copies.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16200>
With the introduction of locks around the XCB polling mechanism,
a possible deadlock was introduced.
If all 5 images were rapidly acquired and presented before the
FIFO thread had the chance to submit a present,
we would deadlock.
Before the lock however, it was still buggy since the two threads would
race to poll events and update internal state.
The fix is to just ensure that there are pending presentation requests
in flight, so that forward progress is guaranteed before we take the
poll lock.
Also, use a timedlock for acquire next image.
Similar as WaitForPresentKHR.
Also need to make the busy flag atomic to actually allow acquire thread
and present threads to access the busy flag.
Take advantage of busy flag being atomic so that we can gracefully handle
timeout == 0 scenarios where there actually are images available.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Fixes: 8fc7927787 ("wsi/x11: Implement VK_KHR_present_wait on X11.)
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19990>
When we need to poll the XCB connection with a non-trivial timeout,
be very careful to not hit an XCB bug where a poll() may hang for too
long even if an event is ready in the special event queue.
This is a pragmatic workaround, a wait_for_special_event_with_timeout()
is the only proper solution here.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19279>
Danylo Piliaiev