-
Notifications
You must be signed in to change notification settings - Fork 234
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memoryless tiler #477
base: master
Are you sure you want to change the base?
Memoryless tiler #477
Conversation
…oryless and VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT
First of all, we should be able to globally disable the use of memoryless. Because some very heavy scenes can give an out of tile memory error and simply not render anything (we had such cases on Metal in Live Home 3D). For this purpose we introduced "WindowMemoryless" param. Actually it's almost the same as "memoryless_depth_buffer". But if "WindowMemoryless"/"memoryless_depth_buffer" is false, then we have to remove MTLStorageModeMemoryless from depth buffer and also from MSAA buffer as well. Indeed, this way Metal will be able to split rendering into several passes with intermediate results stored in these buffers, and Metal does this. I don't know about Vulcan, but I think he rules in the same way. |
Second, we should be able to use memoryless for depth only when we render to MSAA texture. For this purpose we need something like TextureFlags::TilerDepthMemoryless.
Here we use ordinary MSAA texture planarReflect_msaa_rtt and memoryless depth when we render into target planarReflect_msaa_rtt create with following code:
So to be flexible, it would be great to have texture flags: TilerMemoryless and TilerDepthMemoryless |
Hm, may be the special memoryless depth pool is enough and we may avoid TilerDepthMemoryless |
However, we still need the ability to disable memoryless mode for implicit MSAA along with depth. For example when too many triangles are visible and we run out of tile memory. |
Oh! I didn't know this. Then yes, we need a global toggle. The only issue I see is that such toggle requires quite a bunch of resources to be recreated (if you want it to be toggled at runtime and not at startup). Regardless Vulkan, ARM Mali has a 180MB limit (memoryless or not). That 180MB is in the data that gets sent from VS to PS, i.e. position + interpolators data. ARM published more details about this yesterday, see page 13.
Yes, the memoryless depth pool should be enough. |
- Added extensive validation: - Load & Store actions are validated - TextureGpu::copyTo validates - AsyncTextureTicket validates - StagingTexture validates - Validation is used on non-tilers too, to ease development and cross-platform compatibility & testing. - Replaced TextureFlags::TilerDepthMemoryless with DepthBuffer::POOL_MEMORYLESS - Eugene's code was more aggressive in deducing if memoryless could be used, but this would break advanced user cases (i.e. where UAV / Compute Shaders are involved). While it might be possible to deduce a that a NotTexture + RenderTexture + not UAV should be memoryless, such specific flag combination implies the user knows what they're doing and can request the memoryless explicitly. Discardable does not mean it's safe for the texture to be memoryless, since Discardable is for content that can be discarded for the next frame, but it may still be accessed during the same frame. Explicit MSAA are almost never intended to be memoryless. - Make implicit MSAA textures always memoryless - "WindowMemoryless" replaced with per-window setting memoryless_depth_buffer
20312d9
to
bf991d0
Compare
RSC_TILER + TextureFlags::Tiler[Depth]Memoryless => MTLStorageModeMemoryless and VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT