Destruction of Algorithm that is presently running violates Vulkan spec - (Presently theoretical) #214
Comments
|
Ok it seems that this test: TEST(TestAsyncOperations, TestManagerAsyncExecutionDestroyDescriptors)
{
{
uint32_t size = 10;
std::string shader(R"(
#version 450
layout (local_size_x = 1) in;
layout(set = 0, binding = 0) buffer b { float pb[]; };
shared uint sharedTotal[1];
void main() {
uint index = gl_GlobalInvocationID.x;
sharedTotal[0] = 0;
for (int i = 0; i < 100000000; i++)
{
atomicAdd(sharedTotal[0], 1);
}
pb[index] = sharedTotal[0];
}
)");
std::vector<uint32_t> spirv = kp::Shader::compileSource(shader);
std::vector<float> data(size, 0.0);
std::vector<float> resultAsync(size, 100000000);
kp::Manager mgr;
std::shared_ptr<kp::TensorT<float>> tensorA = mgr.tensor(data);
std::shared_ptr<kp::TensorT<float>> tensorB = mgr.tensor(data);
std::shared_ptr<kp::Sequence> sq1 = mgr.sequence();
std::shared_ptr<kp::Sequence> sq2 = mgr.sequence();
sq1->eval<kp::OpTensorSyncLocal>({ tensorA, tensorB });
std::shared_ptr<kp::Algorithm> algo1 = mgr.algorithm({ tensorA }, spirv);
std::shared_ptr<kp::Algorithm> algo2 = mgr.algorithm({ tensorB }, spirv);
// AMD Drivers in Windows may see an error in this line due to timeout.
// In order to fix this, it requires a change on Windows registries.
// More details on this can be found here: https://docs.substance3d.com/spdoc/gpu-drivers-crash-with-long-computations-128745489.html
// Context on solution discussed in github: https://github.com/EthicalML/vulkan-kompute/issues/196#issuecomment-808866505
sq1->evalAsync<kp::OpAlgoDispatch>(algo1);
sq2->evalAsync<kp::OpAlgoDispatch>(algo2);
}
}
Can recreate the following validation violations: |
|
Yes, |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Algorithm's destroy function destroys:
without waiting for completion.
There are other objects destroyed which may also cause errors in similar ways.
vkDestroyPipeline: VUID-vkDestroyPipeline-pipeline-00765: All submitted commands that refer to pipeline must have completed executionvkDestroyDescriptorPool: VUID-vkDestroyDescriptorPool-descriptorPool-00303: All submitted commands that refer to descriptorPool (via any allocated descriptor sets) must have completed executionThere is also the theoretical potential for:
vkDestroyPipelineLayout: VUID-vkDestroyPipelineLayout-pipelineLayout-02004: pipelineLayout must not have been passed to any vkCmd* command for any command buffers that are still in the recording state when vkDestroyPipelineLayout is calledThe text was updated successfully, but these errors were encountered: