-
Notifications
You must be signed in to change notification settings - Fork 147
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
Destruction of Algorithm that is presently running violates Vulkan spec - (Presently theoretical) #214
Labels
bug
Something isn't working
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: