Start of spatio-temportal allocation for clipping #934
Conversation
This commit has a sketch of spatio-temporal allocation for clipping, but it is not fully wired up yet. Scenes without clipping should work, but there is a fair amount of TODO remaining for clipping. There's a fair amount of refactoring here. The biggest change is that draw calls and render passes can be issued from inside the scheduler, as opposed to separate "prepare" and "render" calls. The number of render passes needed will vary by the scene.
|
|
||
| // Polyfills `unpack4x8unorm`. | ||
| // | ||
| // Downlevel targets do not support native WGSL `unpack4x8unorm`. |
There was a problem hiding this comment.
We should make a note that this goes away when we move to wgpu 25.
| slot_ix: !0, | ||
| round: self.round, | ||
| }); | ||
| let bg = tile.bg.to_u32(); |
There was a problem hiding this comment.
Is bg going to be used outside of this alpha check and then the conditionalized draw?
| size: wgpu::Extent3d { | ||
| width: 256, // TODO: make configurable | ||
| height: 1024, | ||
| depth_or_array_layers: 1, |
There was a problem hiding this comment.
I think it would be valid to use a 2d texture array here, rather than an array of textures.
There was a problem hiding this comment.
I'm not sure it's going to be better. You're going to have an array of two texture views in any case, where one will be bound to sample from, and the other will be a render attachment. At the Vulkan level, there are going to be image barriers between the render passes. When it's bound as a render attachment, it's going to be VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL, and when sampled from, VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL (see the texture Vulkan example to see what that barrier looks like). I'm not sure having different layouts for different levels works; if not, I can imagine a smart driver using VK_IMAGE_LAYOUT_GENERAL, which might not be as efficient. I haven't investigated what wgpu actually does here. D3D12 has similar considerations.
In short, using a texture array gets you into tricky areas for the mapping to lower level APIs, while using two textures avoids that.
This commit has a sketch of spatio-temporal allocation for clipping, but it is not fully wired up yet. Scenes without clipping should work, but there is a fair amount of TODO remaining for clipping.
There's a fair amount of refactoring here. The biggest change is that draw calls and render passes can be issued from inside the scheduler, as opposed to separate "prepare" and "render" calls. The number of render passes needed will vary by the scene.