Change how device address is requested to avoid future API breakage

[darksylinc]

PR #100062 introduced BUFFER_USAGE_DEVICE_ADDRESS_BIT.

However it did so by adding a boolean to uniform_buffer_create(), called "bool p_enable_device_address".

This makes maintaining backwards compatibility harder because I am working on another feature that would require introducing yet another bit flag.

This would save us the need to add fallback routines when the feature I am working on makes it to Godot 4.5.

Even if my feature doesn't make it to 4.5 either, this PR makes the routine more future-proof.

This PR also moves STORAGE_BUFFER_USAGE_DEVICE_ADDRESS into BUFFER_CREATION_DEVICE_ADDRESS_BIT, since it's an option available to both storage and uniforms.

This PR also moves the boolean use_as_storage into BUFFER_CREATION_AS_STORAGE.

[darksylinc]

In the XML docs, I had to mix tabs & spaces instead of only tabs so that the code would be properly indented in Godot.

If I used pure tabs, the doctool would undo the indentation, showing this:

rd = RenderingServer.get_rendering_device()

if rd.has_feature(RenderingDevice.SUPPORTS_BUFFER_DEVICE_ADDRESS):
storage_buffer = rd.storage_buffer_create(bytes.size(), bytes, RenderingDevice.STORAGE_BUFFER_USAGE_SHADER_DEVICE_ADDRESS):
storage_buffer_address = rd.buffer_get_device_address(storage_buffer)

Instead of this:

rd = RenderingServer.get_rendering_device()

if rd.has_feature(RenderingDevice.SUPPORTS_BUFFER_DEVICE_ADDRESS):
	  storage_buffer = rd.storage_buffer_create(bytes.size(), bytes, RenderingDevice.STORAGE_BUFFER_USAGE_SHADER_DEVICE_ADDRESS):
	  storage_buffer_address = rd.buffer_get_device_address(storage_buffer)

[akien-mga]

In the XML docs, I had to mix tabs & spaces instead of only tabs so that the code would be properly indented in Godot.

That's by design (for now). The XML structure should be indented with tabs, and code in codeblocks should be indented with 4 spaces. They're two different contexts using a different indent convention, albeit an arguably weird one.

We'll probably change this with #89819 but for now you need to follow the current convention.

[DarioSamo]

The suggested change is a good idea, but there's some inconsistency with the usage of bits in this class when we usually refer to them as "flags" in any other function on it. If the terminology is fixed I think this is good to go if it's given some testing.

[darksylinc]

You mean BUFFER_CREATION_DEVICE_ADDRESS_BIT should be BUFFER_CREATION_DEVICE_ADDRESS_FLAG and BufferCreationBits should be BufferCreationFlags ?

[DarioSamo]

You mean BUFFER_CREATION_DEVICE_ADDRESS_BIT should be BUFFER_CREATION_DEVICE_ADDRESS_FLAG and BufferCreationBits should be BufferCreationFlags ?

Only the latter change, you shouldn't need to specify _BIT or _FLAG on the enum itself.

[darksylinc]

Only the latter change, you shouldn't need to specify _BIT or _FLAG on the enum itself.

Wait. I'm confused. A lot of other code in the codebase uses that convention. e.g.

enum TextureAspectBits {
	TEXTURE_ASPECT_COLOR_BIT = (1 << TEXTURE_ASPECT_COLOR),
	TEXTURE_ASPECT_DEPTH_BIT = (1 << TEXTURE_ASPECT_DEPTH),
	TEXTURE_ASPECT_STENCIL_BIT = (1 << TEXTURE_ASPECT_STENCIL),
};

enum PipelineStageBits {
	PIPELINE_STAGE_TOP_OF_PIPE_BIT = (1 << 0),
	PIPELINE_STAGE_DRAW_INDIRECT_BIT = (1 << 1),
	// ...
};

enum BarrierAccessBits {
	BARRIER_ACCESS_INDIRECT_COMMAND_READ_BIT = (1 << 0),
	BARRIER_ACCESS_INDEX_READ_BIT = (1 << 1),
	// ...
};

enum WindowFlagsBit {
	WINDOW_FLAG_RESIZE_DISABLED_BIT = (1 << WINDOW_FLAG_RESIZE_DISABLED),
	WINDOW_FLAG_BORDERLESS_BIT = (1 << WINDOW_FLAG_BORDERLESS),
	// ...
};

[akien-mga]

It seems the usage is currently inconsistent between Flags vs Bits suffix for the enum, and _BIT or nothing for the actual flags. So I'd just align with whatever seems to be used in this class / related classes. From the above there seems to be a fair bit of Bits/_BIT in rendering.

[DarioSamo]

Let's go with Bits for the enum and _BIT for the enum itself.

[darksylinc]

All checks passed!

[clayjohn]

Looks fine to me.

It is a bit awkward to break compatibility in the late beta stages. But we agreed we wanted to break compatibility now so we don't have to do it next release. From the perspective of users updating from 4.3 to 4.4 we will only break compatibility once anyway.

[Repiteo]

Thanks!

[adamscott]

This PR caused a huge regression unfortunately: #102791
cc. @darksylinc