News: 0001515681

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

AMD's GPUOpen Vulkan Memory Allocator Now Supports Vulkan 1.4

([Radeon] 6 Hours Ago Vulkan Memory Allocator 3.2)


AMD's GPUOpen team managed to squeeze in a new Vulkan Memory Allocator release into 2024. As a reminder this is a easy to use/integrate Vulkan memory allocation library for both Windows and Linux systems with hopes of making memory allocation and resource creation more easier like with Direct3D 11 and OpenGL.

This morning Vulkan Memory Allocator 3.2 was released by the GPUOpen project. The headline change is now supporting [1]Vulkan 1.4 that debuted earlier this month. Vulkan 1.4 is already [2]supported by various Mesa drivers and as of last week [3]supported by AMDVLK as AMD's official open-source Vulkan driver. Vulkan Memory Allocator 3.2 is now compatible with Vulkan 1.4 usage.

The Vulkan Memory Allocator 3.2 release also adds support for the VK_KHR_external_memory_win32 extension on Windows systems. Plus fixes some thread safety issues and other bug fixes / improvements. Vulkan developers wanting to make use of this GPUOpen project for easier Vulkan memory management can find the code via [4]GitHub .



[1] https://www.phoronix.com/search/Vulkan+1.4

[2] https://www.phoronix.com/news/Vulkan-1.4-Mesa-Drivers

[3] https://www.phoronix.com/news/AMDVLK-2024.Q4.3-Released

[4] https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator/releases/tag/v3.2.0


phoronix

It is a very humbling experience to make a multimillion-dollar mistake, but
it is also very memorable. I vividly recall the night we decided how to
organize the actual writing of external specifications for OS/360. The
manager of architecture, the manager of control program implementation, and
I were threshing out the plan, schedule, and division of responsibilities.
The architecture manager had 10 good men. He asserted that they
could write the specifications and do it right. It would take ten months,
three more than the schedule allowed.
The control program manager had 150 men. He asserted that they
could prepare the specifications, with the architecture team coordinating;
it would be well-done and practical, and he could do it on schedule.
Furthermore, if the architecture team did it, his 150 men would sit twiddling
their thumbs for ten months.
To this the architecture manager responded that if I gave the control
program team the responsibility, the result would not in fact be on time,
but would also be three months late, and of much lower quality. I did, and
it was. He was right on both counts. Moreover, the lack of conceptual
integrity made the system far more costly to build and change, and I would
estimate that it added a year to debugging time.
-- Frederick Brooks Jr., "The Mythical Man Month"