diff options
author | Eduardo Lima Mitev <[email protected]> | 2016-10-25 10:20:12 +0200 |
---|---|---|
committer | Eduardo Lima Mitev <[email protected]> | 2016-10-25 13:22:38 +0200 |
commit | 750d8cad72a532d977df10ffbbdd1902bd06f50b (patch) | |
tree | ea28c6cfed2d26109c7fdf1927a72903ab5487bd /src/gallium | |
parent | a1652a059edc5a5f0f4b0836ba310a22e094bd85 (diff) |
vulkan/wsi/x11: Fix behavior of vkGetPhysicalDeviceSurfaceFormatsKHR
x11_surface_get_formats() is currently asserting that the number of
elements in pSurfaceFormats must be greater than or equal to the number
of formats available. This is buggy because pSurfaceFormatsCount
elements are later copied from the internal formats' array, so if
pSurfaceFormatCount is greater, it will overflow it.
On top of that, this assertion violates the spec. From the Vulkan 1.0
(revision 32, with KHR extensions), page 579 of the PDF:
"If pSurfaceFormats is NULL, then the number of format pairs supported
for the given surface is returned in pSurfaceFormatCount. Otherwise,
pSurfaceFormatCount must point to a variable set by the user to the
number of elements in the pSurfaceFormats array, and on return the
variable is overwritten with the number of structures actually written
to pSurfaceFormats. If the value of pSurfaceFormatCount is less than
the number of format pairs supported, at most pSurfaceFormatCount
structures will be written. If pSurfaceFormatCount is smaller than
the number of format pairs supported for the given surface,
VK_INCOMPLETE will be returned instead of VK_SUCCESS to indicate that
not all the available values were returned."
So, the correct behavior is: if pSurfaceFormatCount is greater than the
internal number of formats, it is clamped to that many formats. But
if it is lesser than that, then pSurfaceFormatCount elements are copied,
and the call returns VK_INCOMPLETE.
Reviewed-by: Dave Airlie <[email protected]>
Diffstat (limited to 'src/gallium')
0 files changed, 0 insertions, 0 deletions