This was sort of well intentioned, but wrong. bits_per_rgb_value is the
number of significant bits in the color (channel) specification, not the
number of bits used to name that color within the pixel. If you have a
depth 24 visual but the colormap is 11 bits deep then each of those
channels selects one of 256 11-bit color values in the output ramp.
The open source drivers mostly don't expose anything like that, but
nvidia does, and we refuse to work. That's silly. Practically speaking
we can probably render to any TrueColor or DirectColor visual that your
X server exposes, since it is probably not going to have visuals for
non-color-renderable formats. Just check the visual class instead.
Likewise when matching formats to visuals, count the bits in the rgb
masks in the visual.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6995
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18381>
The image is busy until xcb_put_image returns. This isn't a major worry
at the moment since we're doing the PutImage directly from
vkQueuePresent, but if we moved that to a worker thread the race window
would be a lot easier to hit.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18214>
For AMD we kinda have some modifiers with a max size ... (Which is
really a compositor/kms issue, but getting them to try kinda falls
into the unsolved "how to allocate/what pitch to use" bucket, so
we solve it on the allocating side)
Cc: mesa-stable
Tested-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Joshua Ashton <joshua@froggi.es>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18139>
Yes this is a round trip, but X_PresentPixmap is not itself a blocking
operation, it just instructs the server to do the next presentation at
some time. More importantly, if _we_ don't catch the presentation error,
xlib's error queue will, and the calling code is certainly not prepared
to handle errors from Present.
Forcing the round trip here is also a bit more correct semantically.
This is the end of the Vulkan client part of the present queue, and the
X_PresentPixmap request transfers the queue operation to the server, so
we should not return until we are sure the handoff has happened.
Fixes some flakiness with piglit@glx-visuals-* with zink+radv.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17685>
in this case, lying about having multiple images and then returning the
same image every time doesn't work, so use the busy flag
and return an available image when possible
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17590>
We're about to make it so that the compiler warns/errors if you use the
wrong iterator macro. Fix up a bunch of places where someone used the
wrong one before we break anything.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17630>
First, because we're using __vk_append_struct which attacks it on the
end, memory_wsi_info is modified even though it's const. Make things
non-const so we aren't silently violating assumptions. Also, we set a
pNext in memory_export_info which causes a loop in the pNext chain in
the handle_types != 0 case.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6826
Fixes: 124848bf9e ("vulkan/wsi: Support tiled CPU images")
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17434>
Some drivers such as lavapipe are 100% fine with using linear for WSI
images. Most HW drivers, however, would rather render tiled and eat a
blit.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17388>
This isn't a big deal for the current buffer paths because the required
alignment for PRIME is already higher than any driver advertises.
However, the SW path we're about to add won't have the PRIME requirement.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17388>
Instead of taking a single boolean for device-local, take a set of
required properties and denied properties. This will let us require
additional things like being CPU mappable in the future.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17388>
ENOSYS is commented as "Invalid system call number". This is returned
by qemu-user for unbridged ioctls.
Fixes: 30b57f10b3 ("vulkan/wsi: Signal semaphores and fences from the dma-buf")
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17325>
If you set a name of on a swapchain object, because the base object
struct has not been initialized with a VkDevice,
vk_object_base_finish() will segfault when trying to free the object
name.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: cb1e0db23e ("vulkan/wsi: Make wsi_swapchain inherit from vk_object_base")
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17165>
FreeBSD supports DMA-BUF but not DMA_BUF_IOCTL_SYNC and similar yet.
As it returns EBADF instead of ENOTTY all consumers fail due to
VK_ERROR_OUT_OF_HOST_MEMORY.
Fixes: 30b57f10b3 ("vulkan/wsi: Signal semaphores and fences from the dma-buf")
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17070>
