Introduce a new Texture type with DX,VK,MTL implementations.#1020
Introduce a new Texture type with DX,VK,MTL implementations.#1020EmilioLaiso wants to merge 6 commits intollvm:mainfrom
Texture type with DX,VK,MTL implementations.#1020Conversation
ee21f04 to
48dadd6
Compare
217f6ef to
505d3f0
Compare
de634bd to
0bf7cfc
Compare
e1c50e9 to
eb9f868
Compare
| const CPUBuffer &B = *P.Bindings.RTargetBufferPtr; | ||
| memcpy(B.Data[0].get(), Mapped, B.size()); | ||
| vkUnmapMemory(Device, ResRef.Host.Memory); | ||
| vkUnmapMemory(Device, IS.RTReadback->Memory); |
There was a problem hiding this comment.
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
left a comment
There was a problem hiding this comment.
Just a couple of small comments, but other than that looks good to me
4c4f1a6 to
c0ab760
Compare
8786868 to
cbda773
Compare
cbda773 to
352383a
Compare
lib/API/DX/Device.cpp
Outdated
| // Readback heaps do not support UAV access. | ||
| const D3D12_RESOURCE_FLAGS Flags = | ||
| D3D12_RESOURCE_FLAG_ALLOW_UNORDERED_ACCESS; | ||
| HeapType == D3D12_HEAP_TYPE_READBACK | ||
| ? D3D12_RESOURCE_FLAG_NONE | ||
| : D3D12_RESOURCE_FLAG_ALLOW_UNORDERED_ACCESS; |
There was a problem hiding this comment.
Fwiw in our codebase we use a custom heap that might not place this restriction on buffers.
…oryLocation` and `Format` types. Add `FormatConversion.h` containing bridge functions between old and new API.
…earDepthStencil` types defined in `Texture.h` and `validateTextureCreateDesc` function Add `createTexture` function in device and supporting function `createRenderTargetFromCPUBuffer`
| std::shared_ptr<VulkanTexture> RenderTarget; | ||
| std::shared_ptr<VulkanBuffer> RTReadback; | ||
| std::shared_ptr<VulkanTexture> DepthStencil; |
There was a problem hiding this comment.
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?
…eanup code to use the new helper functions
…ncil support to both MTL and DX backend to align with behaviour of VK backend
352383a to
f6ac12e
Compare
Summary
Texture.hwith a sharedTextureCreateDesc,TextureFormatenum,TextureUsageflags,ClearValuevariant (ClearColor/ClearDepthStencil), andvalidateTextureCreateDescreturning specificllvm::ErrormessagescreateTextureto all three backends (DX, Vulkan, Metal) as a virtual method onDevice, handling resource creation, optimized clear values, and format/usage validationcreateRenderTargetFromCPUBuffer(Device&, CPUBuffer&)free function — all backends now route throughcreateTextureinstead of manually calling API-specific resource creationcreateDefaultDepthStencilTarget(Device&, Width, Height)free function withD32FloatS8Uintformat — added depth testing to DX and Metal backends (previously only Vulkan had it)createBufferAPI withMemoryLocation::GpuToCpu; Metal refactored fromStorageModeSharedtexture withgetBytes()toStorageModePrivatetexture + blit copy to readback buffer (this is to align functionality between backends in preparation of api-agnostic code-flow. Sacrifices had to be made 😛)VkImageView(VK) are now created atcreateTexturetime forRenderTarget/DepthStencilusage, removing view creation boilerplate from pipeline setupshared_ptr<VulkanTexture>/shared_ptr<VulkanBuffer>onInvocationStatetoTextureFormat(DataFormat, Channels)as a bridge function while refactoring, withvalidateTextureDescMatchesCPUBufferto catch mismatches between the old and new description systemsgetMetalTextureStorageModeandgetMetalBufferResourceOptionsbecauseGpuToCpumaps differently for textures (Managed) vs buffers (Shared)Future direction
Added for context to better understand some of the changes in this PR.
DataFormat + Channelsdual description.createBuffer— still uses the oldResourceRef/BufferRefsystemInvocationStateacross backends