TpvVulkanDeviceMemoryStaging causes VK_ERROR_DEVICE_OUT_OF_MEMORY fail

[johnhutch111]

The recently added fMemoryStaging in TpvVulkanDevice can cause an VK_ERROR_DEVICE_OUT_OF_MEMORY during the TpvVulkanDeviceMemoryStaging.Initialize stage. (When the TpvVulkanBuffer.Create is called a VK_ERROR_DEVICE_OUT_OF_MEMORY is generated and everything shuts down).

Seems to happen when running in 32bit environment when inside the Delphi IDE or when RenderDoc is capturing a frame.
It does not happen all the time in 32bit.
It does not happen at all when running in 64bit.

The fSize is being set to 268435456 bytes for both 32bit and 64bit on an NVIDEA GPU. Is this OK?

Any thoughts on reason and fix?

[johnhutch111]

Further, manually setting the fSize to 16Mb stops the fail.

[johnhutch111]

Further, using the fDevice.fMemoryManager.fMaximumMemoryMappableNonDeviceLocalHeapSize value as the starting point for the fail

[BeRo1985]

Thank you for your issue report on the Vulkan memory staging issue in a 32-bit environment. The 256 MB allocation you're dealing with is significant, particularly for graphics programming. This size aligns with the maximum PCI Base Address Register (BAR) size in systems lacking Resizable BAR (ReBAR) technology, making it a substantial but potentially problematic allocation in 32-bit systems, which are limited to about 4 GB of addressable memory.

The use of a 256 MB staging buffer in Vulkan is strategic, allowing for efficient data transfer to the GPU (CPU memory => staging buffer => GPU memory), which is optimized for fast graphics rendering. However, in 32-bit environments, allocating such a large amount can lead to memory allocation issues like the VK_ERROR_DEVICE_OUT_OF_MEMORY error you're experiencing, especially when system memory is already under pressure.

It's important to note the shift in the computing landscape towards 64-bit systems, impacting not just high-performance graphics but all areas, including low-end devices and applications. This transition is driven by the need for more memory and processing power, essential for modern applications. As a result, most Vulkan-enabled systems, including single-board computers (such as the Raspberry PI, from RPI3 onwards), smartphones (since around 2014-2016), and tablets (since around 2014-2016), have been moving to 64-bit architectures. This includes low-end devices, where even Android smartphones and tablets under 200€ or $200 are typically 64-bit nowadays.

Reflecting this trend, Android has also transitioned to being 64-bit only, following in the footsteps of iOS, and many contemporary game engines are also now exclusively 64-bit. This shift is indicative of the growing requirements in modern gaming, which often involves complex graphics and large-scale data processing beyond the capacity of 32-bit systems.

If you're really stuck with debugging or using RenderDoc in a 32-bit environment and absolutely need this fix, let me know. I can add the IFDEFs for the Vulkan memory staging issue, but I'll do this only if it's absolutely necessary. Just remember, we're moving towards a 64-bit world, and that's where our main focus should be. So, if you're in a tight spot and really need this 32-bit "workaround", shoot me a message, and we'll sort it out.

Bear in mind, though, that this will be really just a targeted, temporary measure, reflecting the specific challenges of your current situation then. The computing industry is steadily migrating to 64-bit systems. While I'm ready to help with this 32-bit issue as needed, we should keep our eyes on the future, ensuring our work stays in step with 64-bit advancements. This focus is key to keeping our application at the forefront of technology and meeting the standards of modern graphics computing.

[johnhutch111]

I take your point on the move toward 64bit and will make this as the default. However, as there is still access to 32bit in the Delphi environment and the packages need to have a 32bit target, then is it possible to test using IFDEF WIN32 to set a safer size for 32bit only. The fail is so dramatic ie no exception trapping and the running system crashing completely. Can the Vulkan system be queried to see if the proposed allocation can be achieved??