Ability to allocate transient buffers/textures + hint to lazy allocate

[EriKWDev]

Popped up during discussion in #213

The current Memory enum and TextureUsage still doesn't quite allow expressing what in vulkan becomes a lazilly allocated texture with transient flags set as is ideal for MSAA as outlined in https://docs.vulkan.org/samples/latest/samples/performance/msaa/README.html

I still have not measured what the drivers do when given user-code that uses textures allocated in the current way, but the link seems to suggest there is measurable bandwidth differences if one can correctly specify these options.

Vulkan

The gpu_allocator that is used by blade's vulkan backend has a UsageFlags::TRANSIENT and some special code paths to make those allocations more optimal. It also has MemoryPropertyFlags::LAZILY_ALLOCATED

I think the lazilly_allocated bit is marked as a valid one if supported (

blade/blade-graphics/src/vulkan/init.rs

Line 621 in 5309b49

let known_memory_flags = vk::MemoryPropertyFlags::DEVICE_LOCAL

), so a new blade_graphics::Memory profile would be needed

blade/blade-graphics/src/vulkan/resource.rs

Line 24 in 5309b49

let alloc_usage = match memory {

The final piece would then be to also be able to specify the requirement of being lazilly-allocated for image creation at

blade/blade-graphics/src/vulkan/resource.rs

Line 276 in 5309b49

let requirements = unsafe { self.device.core.get_image_memory_requirements(raw) };

Metal

At least the Metal docs on multisampling seem to indicate nothing this granular is required to be specified by the user https://developer.apple.com/documentation/metal/mtlrenderpassattachmentdescriptor#1968767

The concept of transient attachments seems not explicit in Metal

Opengl Es

Even possible to specify this?

[EriKWDev]

The TextureDesc currently has no kind of Memory hints which would maybe be desirable to address this. Could maybe be covered in TextureUsage flags though unsure if that would be the right place

[kvark]

Transient images aren't really saving you any bandwidth. The savings on mobile are from using the CLEAR load op and RESOLVE store op. The transient memory is just for memory savings, as an analogue for aliasing.

[EriKWDev]

I would assume you are correct, the load and store op is what would cause all the bandwidth usage from writing and are alone enough to describe that

In the article it seems phrased as if all three are required in order to see any benefit, not really separated what the separate benefits are.

the multisampled attachment must use storeOp = VK_ATTACHMENT_STORE_OP_DONT_CARE and usage |= VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT, and allocate the image with the LAZILY_ALLOCATED memory property