b0653370d0
STACK_ARRAY() is used in a lot of places. When games are running we see STACK_ARRAY() arrays being used all the time: each queue submission uses 6, WaitSemaphores and syncobj waiting also uses them: they're constantly present in Vulkan runtime. There's no need for STACK_ARRAY()'s stack array to be initialized, callers cannot not depend on it. If the number of elements is greater than STACK_ARRAY_SIZE, then STACK_ARRAY() will just malloc() the array and return it not initialized: anybody depending of zero-initialization is going to break when the array is big. The reason why we're zero-intializing STACK_ARRAY()'s stack array is to silence -Wmaybe-uninitialized warnings: see commitd7957df318("vulkan: fix uninitialized variables"). I don't think that commit is the ideal way to deal with the problem, so this patch proposes a better solution. The problem here is that zero-initializing it adds code we don't need for every single caller. STACK_ARRAY() already has 63 callers and only 3 of them are affected by the -Wmaybe-uninitialized warining. So here we undo what commitd7957df318did and instead we fix the 3 cases that actually generate the -Wmaybe-uninitialized warnings. Gcc is only emitting those warinings because it knows that the number of elements in the array may be zero, so the loops we have that set elements to the array may end up do nothing, and then we pass the array uninitialized to other functions. For the cases related to vk_sync this is just returning VK_SUCCESS earlier, instead of relying on the check that eventually happens at __vk_sync_wait_many(). For the vkCmdWaitEvents() function, the Vulkan spec says that "eventCount must be greater than 0", so the early return doesn't hurt anybody either. In both cases we make the zero case faster by not defining an 8-sized array, zero-initializing it, then returning success without using it. Reference:d7957df318("vulkan: fix uninitialized variables") Acked-by: Yonggang Luo <luoyonggang@gmail.com> Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28288>
`Mesa <https://mesa3d.org>`_ - The 3D Graphics Library ====================================================== Source ------ This repository lives at https://gitlab.freedesktop.org/mesa/mesa. Other repositories are likely forks, and code found there is not supported. Build & install --------------- You can find more information in our documentation (`docs/install.rst <https://mesa3d.org/install.html>`_), but the recommended way is to use Meson (`docs/meson.rst <https://mesa3d.org/meson.html>`_): .. code-block:: sh $ mkdir build $ cd build $ meson .. $ sudo ninja install Support ------- Many Mesa devs hang on IRC; if you're not sure which channel is appropriate, you should ask your question on `OFTC's #dri-devel <irc://irc.oftc.net/dri-devel>`_, someone will redirect you if necessary. Remember that not everyone is in the same timezone as you, so it might take a while before someone qualified sees your question. To figure out who you're talking to, or which nick to ping for your question, check out `Who's Who on IRC <https://dri.freedesktop.org/wiki/WhosWho/>`_. The next best option is to ask your question in an email to the mailing lists: `mesa-dev\@lists.freedesktop.org <https://lists.freedesktop.org/mailman/listinfo/mesa-dev>`_ Bug reports ----------- If you think something isn't working properly, please file a bug report (`docs/bugs.rst <https://mesa3d.org/bugs.html>`_). Contributing ------------ Contributions are welcome, and step-by-step instructions can be found in our documentation (`docs/submittingpatches.rst <https://mesa3d.org/submittingpatches.html>`_). Note that Mesa uses gitlab for patches submission, review and discussions.