Implement Buffer Device Address for Rendering Device Vulkan and DirectX12

[thimenesup]

This is an extremely useful feature that is supported on many GPUs which may be worthwhile to have it since the changes are minimally invasive, and allows for a lot of flexibility, specially for compute shaders and a requirement for ray tracing.

Tested to work on Windows 10 with Vulkan driver.
On DirectX12 the SPIR-V to NIR shader compiler doesn't have implemented this extension (yet?), so remains untested.
Test project used available here

Do note that it only has been implemented for storage buffers, to not change function signatures, but it could be implemented for the other buffer types, either by adding another default parameter, or breaking compatibility and using bitwise flags.

[DarioSamo]

Both you and #99119 are trying to implement this as buffer device address is required for RT as well. You might want to coordinate how to support this particular feature as both implementations seem to be a bit different. CC @Fahien

[thimenesup]

From what I have seen the implementations are fairly similar, albeit with some small differences, mine loads the extension either from core 1.2 or the KHR version which has a wider support compared to the EXT used in the other branch (sourced from the gpuinfo database), and also flags index and vertex buffers by default, which likely won't play nicely on devices where its not supported.

I think the buffer device address feature its worthwhile on its own and should be merged beforehand, then the other ray tracing branch could be rebased from it.

Went ahead an added it as optional functionality to index, vertex and uniform buffers while preserving compatibility, and updated the documentation.
Also implemented it for Metal to ensure compilation, but its an API I haven't really used, so I don't know for sure if its 100% correct.

[Fahien]

@thimenesup: I think the buffer device address feature its worthwhile on its own and should be merged beforehand, then the other ray tracing branch could be rebased from it.

I agree.

[DarioSamo]

I think the buffer device address feature its worthwhile on its own and should be merged beforehand, then the other ray tracing branch could be rebased from it.

I believe so as well, it's easier to integrate it piece-meal like this. I just wanted to make sure you were both in agreement as it'll break the RT branch as soon as it's merged. I have no qualms with integrating the feature as I know how necessary it is for advanced rendering.

[RandomShaper]

Looks good, but there are compatibility breakages.

[thimenesup]

Added the GDExtension compatiblity methods and rebased with the current master again to fix merge conflicts.

[Fahien]

Do we need something like this in _initialize_device()?

	VkPhysicalDeviceBufferDeviceAddressFeaturesKHR device_address_features = {};
	if (buffer_device_address_support) {
		device_address_features.sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_DEVICE_ADDRESS_FEATURES_KHR;
		device_address_features.pNext = create_info_next;
		device_address_features.bufferDeviceAddress = buffer_device_address_support;
		create_info_next = &device_address_features;
	}

[thimenesup]

I think it might be needed for the devices that aren't initializing core Vulkan 1.2 but a prior version instead.

[stuartcarnie]

I've left a couple of notes for Metal. Your implementation is correct, so I suggest you add a property to the MetalFeatures structure, that is set on initialisation, so you can return the correct value for the SUPPORTS_BUFFER_ADDRESS feature.

[stuartcarnie]

This can be true, but I would like to implement it by adding a new boolean property on the MetalFeatures struct:

godot/drivers/metal/metal_device_properties.h

Line 73 in f27764e

struct API_AVAILABLE(macos(11.0), ios(14.0)) MetalFeatures {

[stuartcarnie]

This is correct for Metal 👍🏻