summaryrefslogtreecommitdiffstats
path: root/src/3rdparty/VulkanMemoryAllocator
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Add missing override" for 3rdparty vk_mem_alloc.hAlexander Volkov2020-07-291-70/+70
| | | | | | | | | This partially reverts 9bad3508fccb058261d47e023400868147f2d733. Disable -Wsuggest-override for gcc when including the header instead. Change-Id: Id2507ce731da62bbd64aa6477b181735ba62adc1 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Add missing overrideAlexander Volkov2020-05-211-70/+70
| | | | | | Change-Id: I88000e82ecbdc55e621dc8e22aff5e8f55cf9d0e Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* vkmemalloc: make it compile with macOS 10.15 SDKLaszlo Agocs2020-04-232-1/+66
| | | | | | | | | | | | Simply rename the function in order to not clash with aligned_alloc() that is marked as 10.15 only (and thus would need annotation etc.) in the 10.15 SDK. (note that aligned_alloc is a C11 function which was presumably not present in earlier SDKs, by renaming our own version everyone will be happy, hopefully) Change-Id: Iee400d81df6a0af4fa2129358ed27b049720685b Pick-to: 5.15 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Make sure documentation for VulkanMemoryAllocator 3rdparty code shows upKai Koehne2019-12-031-1/+1
| | | | | | | | | There's no qt documentation module for 'qtrhi' - instead, it should be added to the qtgui documentation module. Fixes: QTBUG-80489 Change-Id: Iea61b907811cd2135c2f1258599d9868d2218679 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* vkmemalloc: Disable SRWLOCK for mingwLaszlo Agocs2019-06-182-1/+14
| | | | | | | | | | | | | | | | | ...until some day someone investigates what is exactly the problem with the sdk that ships with mingw. Task-number: QTBUG-76424 Change-Id: I64869a4fbb07a64cfc1430234d732e143fefe720 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Add VulkanMemoryAllocatorLaszlo Agocs2019-06-125-0/+17241
The Vulkan backend of QRhi relies on vk_mem_alloc.h from AMD in order to get a stable, performant, and tested GPU memory allocator. It is not unthinkable that we will move away from this in the future, especially considering that a potential future D3D12 backend may need a similar solution, but until then this will do. Change-Id: I198a898f216d0795b4bf339ccea80b0cd2efbabc Reviewed-by: Lars Knoll <lars.knoll@qt.io>