Yay! I'm fixing more and more bugs and it feels like it's coming together
The D3D11/Metal-style layer should be done now. I'll now focus on DescriptorSetTexture and co.
Root Layouts have changed slightly:
Code: Select all
## ROOT LAYOUT BEGIN
"has_params" : ["vs", "ps"],
"samplers" : [0, 1],
"textures" : [0, 1]
## ROOT LAYOUT END
layout(ogre_P0) uniform Params
layout(OGRE_POSITION) in vec3 position;
layout(OGRE_TEXCOORD0) in vec2 inUv0;
layout(location = 0) out vec2 uv0;
has_params is no longer a boolean, but rather must specify which stages will use ogre_P0 (i.e. parameters updated via the old Material interface). One can specify each stage or use "all" (not recommended) for all stages (including geometry, hull and domain shaders; or compute in case of compute)
I'm thinking of probably defining conservatively small default root layouts for low level material to avoid having to deal with this (unless e.g. you use too many textures).
Another issue I detected is that we have calls to vkDestroySampler/vkDestroyImage/vkDestroy* which are unsafe. According to spec any command submitted to the GPU using that handle must have completed by the time vkDestroy* is called.
We need to schedule/queue the destruction of those handles for later (i.e. N frames later). Fortunately this is easy to do.
Note that we don't have to delay the memory management.
For example when we do:
Code: Select all
void VulkanTextureGpu::destroyInternalResourcesImpl( void )
vkDestroyImage( device->mDevice, mFinalTextureName, 0 ); // Needs to be delayed
vaoManager->deallocateTexture( mTexMemIdx, mVboPoolIdx, mInternalBufferStart,
memRequirements.size ); // Does not have to be delayed
The reason for this is that even if the memory range released by deallocateTexture gets immediately recycled into another buffer/texture; we won't immediately change its content (not even its layout). We will schedule commands to operate on it.
Thus by the time those commands get executed, the GPU is already finished working on that memory range when it was originally a texture.
The only exception are dynamic buffers (BT_DYNAMIC_*), staging buffers and staging textures; as they can immediately be overwritten from CPU after being recycled while the GPU could still be using that memory region.
However these 3 are already delayed (by VaoManager and TextureGpuManager) so we don't have to worry about those.