Introduce a new Texture type with DX,VK,MTL implementations.

[EmilioLaiso]

Summary

• Introduced Texture.h with a shared TextureCreateDesc, TextureFormat enum, TextureUsage flags, ClearValue variant (ClearColor / ClearDepthStencil), and validateTextureCreateDesc returning specific llvm::Error messages
• Added createTexture to all three backends (DX, Vulkan, Metal) as a virtual method on Device, handling resource creation, optimized clear values, and format/usage validation
• Unified render target creation via createRenderTargetFromCPUBuffer(Device&, CPUBuffer&) free function — all backends now route through createTexture instead of manually calling API-specific resource creation
• Unified depth/stencil creation via createDefaultDepthStencilTarget(Device&, Width, Height) free function with D32FloatS8Uint format — added depth testing to DX and Metal backends (previously only Vulkan had it)
• Readback buffers created through the virtual createBuffer API with MemoryLocation::GpuToCpu; Metal refactored from StorageModeShared texture with getBytes() to StorageModePrivate texture + blit copy to readback buffer (this is to align functionality between backends in preparation of api-agnostic code-flow. Sacrifices had to be made 😛)
• Views on textures — RTV/DSV descriptor heaps (DX) and VkImageView (VK) are now created at createTexture time for RenderTarget/DepthStencil usage, removing view creation boilerplate from pipeline setup
• Render target and readback buffer are stored directly as shared_ptr<VulkanTexture> / shared_ptr<VulkanBuffer> on InvocationState
• Clear values read from texture descriptors in all backends instead of being hardcoded
• Added toTextureFormat(DataFormat, Channels) as a bridge function while refactoring, with validateTextureDescMatchesCPUBuffer to catch mismatches between the old and new description systems
• Split Metal storage mode helpers into getMetalTextureStorageMode and getMetalBufferResourceOptions because GpuToCpu maps differently for textures (Managed) vs buffers (Shared)

Future direction

Added for context to better understand some of the changes in this PR.

• SRV/UAV views on textures — currently not stored on the texture because they would require a descriptor heap allocation scheme
• Work towards eliminating DataFormat + Channels dual description.
• Route VK vertex buffer through createBuffer — still uses the old ResourceRef/BufferRef system
• Abstract readback copy
• Unify InvocationState across backends

[manon-traverse]

NOTE: unmapping is not necessary in Vulkan or DX12. It's fine to leave it as is, but I thought it was good to know it's fine to leave this persistently mapped.

[manon-traverse]

Just a couple of small comments, but other than that looks good to me

[MarijnS95]

Fwiw in our codebase we use a custom heap that might not place this restriction on buffers.

[manon-traverse]

Note: we should try to store the platform-agnostic pointer here and downcast where needed, as the goal is to use these only in the platform-abstract way.

I am fine with keeping it this way for this PR, but it's something we should do in the future. Perhaps once we have an agnostic way of binding resources?

[MarijnS95]

LGTM; I can mostly see where the flow is intended to be going, albeit this still needs quite a significant portion of helpers to keep the current APIs working before they're migrated to the new createTexture() call with (more) general arguments.

Left a few notes where comments could be better, specifically some comments that seem to have appeared on the wrong line (maybe a rebase artifact?) but nothing major.

[MarijnS95]

Do we have a tracking issue for this conversion and removal?

[MarijnS95]

Nice

[s-perron]

I looked at the Vulkan code. Looks good to me. My only real question is the use of std::shared_ptr. If other are okay with it, I won't get in the way.

[s-perron]

Do we want to use std::shared_ptr? I know a lot of projects avoid using it because it is slow.

[manon-traverse]

I would recommend using the shared_ptr. We want to be able to use reference counting to determine if resources need to be kept alive so that we can free them once they are no longer being used on the GPU timeline.

IMO the overhead of shared_ptr is a bit overblown (an atomic increment on copy). If we ever run into a case where we need thousands of textures that need to be kept alive we can look at alternative solutions for those use cases. However, in my experience, that case is only there for bindless resources where you are going to need an alternative anyway.

[s-perron]

I think we need to revisit this. I'm not sure how you count "thousands of textures", but, as the number of tests increases, we could easily reach that over all of the tests. I'll let others like @bogner and @llvm-beanz give their opinions.

I'll go along with what the community thinks.

[damyanp]

@manon-traverse - can you file an issue to follow up on this please? Ideally, we'd get consensus before the PR is merged, but we as long as we figure it all out it's ok to that post-merge.

[s-perron]

I'm use to the Google style guide. We generally do not allow std::shared_ptr unless there is a very good reason for it.

I've only looked at the code quickly. However, would it be possible to make the std::unqiue_ptr to say that they are owned by the InvocationState?

I'll don't have strong opinions for this project, but we should make a conscience decision.

[manon-traverse]

This PR fails some CI tests, but only after changing the name of a getter (unrelated to any errors). It fails on Mac because that machine is out of storage. Intel-clang failure is one that also happens on main, I am going to assume this is because of a change in the llvm-project repo.

Because these reasons have nothing to do with the PR and enough reviewing and applying feedback has happened I am gonig to merge this PR so we can move forward. If any more issues arise, we can address those in follow-up PRs.