How update multiply descriptorSets at once
I have multiply render targets from my swapchain and create a descriptorSet per target. The idea ist to create one commandBuffer per renderTarget und bind the equivalent descriptor. Now I want to update the descriptorSets with one single call of updateDescriptorSets and used:
std::vector<vk::WriteDescriptorSet> writes;
for( UINT32 index = 0; index < descriptorSets.size(); ++index )
{
writes.push_back(
vk::WriteDescriptorSet( descriptorSets[index], 0, 0, 1,
vk::DescriptorType::eStorageImage,
&vk::DescriptorImageInfo( vk::Sampler(), imageViews[index], vk::ImageLayout::eGeneral ),
nullptr,
nullptr ) );
}
device.updateDescriptorSets( writes.size(), writes.data(), 0, nullptr );
With this approach only the last renderTarget in the queue presents the wanted result. The others produce just black screens.
But when i call updateDescriptorSets multiply times all works like expected:
std::vector<vk::WriteDescriptorSet> writes;
for( UINT32 index = 0; index < descriptorSets.size(); ++index )
{
writes.push_back(
vk::WriteDescriptorSet( descriptorSets[index], 0, 0, 1,
vk::DescriptorType::eStorageImage,
&vk::DescriptorImageInfo( vk::Sampler(), imageViews[index], vk::ImageLayout::eGeneral ),
nullptr,
nullptr ) );
device.updateDescriptorSets( writes.size(), writes.data(), 0, nullptr );
writes.clear();
}
I thought that i can update multiply descriptorSets at once. So it is not possible or what else could be my error.
PS: I use the c++ Header frome the vulkan SDK
c++ c++11 vulkan
add a comment |
I have multiply render targets from my swapchain and create a descriptorSet per target. The idea ist to create one commandBuffer per renderTarget und bind the equivalent descriptor. Now I want to update the descriptorSets with one single call of updateDescriptorSets and used:
std::vector<vk::WriteDescriptorSet> writes;
for( UINT32 index = 0; index < descriptorSets.size(); ++index )
{
writes.push_back(
vk::WriteDescriptorSet( descriptorSets[index], 0, 0, 1,
vk::DescriptorType::eStorageImage,
&vk::DescriptorImageInfo( vk::Sampler(), imageViews[index], vk::ImageLayout::eGeneral ),
nullptr,
nullptr ) );
}
device.updateDescriptorSets( writes.size(), writes.data(), 0, nullptr );
With this approach only the last renderTarget in the queue presents the wanted result. The others produce just black screens.
But when i call updateDescriptorSets multiply times all works like expected:
std::vector<vk::WriteDescriptorSet> writes;
for( UINT32 index = 0; index < descriptorSets.size(); ++index )
{
writes.push_back(
vk::WriteDescriptorSet( descriptorSets[index], 0, 0, 1,
vk::DescriptorType::eStorageImage,
&vk::DescriptorImageInfo( vk::Sampler(), imageViews[index], vk::ImageLayout::eGeneral ),
nullptr,
nullptr ) );
device.updateDescriptorSets( writes.size(), writes.data(), 0, nullptr );
writes.clear();
}
I thought that i can update multiply descriptorSets at once. So it is not possible or what else could be my error.
PS: I use the c++ Header frome the vulkan SDK
c++ c++11 vulkan
You can update multiple descriptors sets in a single call. This looks like a bug somewhere else in Your code or like a bug in a driver.
– Ekzuzy
Nov 23 '18 at 14:41
add a comment |
I have multiply render targets from my swapchain and create a descriptorSet per target. The idea ist to create one commandBuffer per renderTarget und bind the equivalent descriptor. Now I want to update the descriptorSets with one single call of updateDescriptorSets and used:
std::vector<vk::WriteDescriptorSet> writes;
for( UINT32 index = 0; index < descriptorSets.size(); ++index )
{
writes.push_back(
vk::WriteDescriptorSet( descriptorSets[index], 0, 0, 1,
vk::DescriptorType::eStorageImage,
&vk::DescriptorImageInfo( vk::Sampler(), imageViews[index], vk::ImageLayout::eGeneral ),
nullptr,
nullptr ) );
}
device.updateDescriptorSets( writes.size(), writes.data(), 0, nullptr );
With this approach only the last renderTarget in the queue presents the wanted result. The others produce just black screens.
But when i call updateDescriptorSets multiply times all works like expected:
std::vector<vk::WriteDescriptorSet> writes;
for( UINT32 index = 0; index < descriptorSets.size(); ++index )
{
writes.push_back(
vk::WriteDescriptorSet( descriptorSets[index], 0, 0, 1,
vk::DescriptorType::eStorageImage,
&vk::DescriptorImageInfo( vk::Sampler(), imageViews[index], vk::ImageLayout::eGeneral ),
nullptr,
nullptr ) );
device.updateDescriptorSets( writes.size(), writes.data(), 0, nullptr );
writes.clear();
}
I thought that i can update multiply descriptorSets at once. So it is not possible or what else could be my error.
PS: I use the c++ Header frome the vulkan SDK
c++ c++11 vulkan
I have multiply render targets from my swapchain and create a descriptorSet per target. The idea ist to create one commandBuffer per renderTarget und bind the equivalent descriptor. Now I want to update the descriptorSets with one single call of updateDescriptorSets and used:
std::vector<vk::WriteDescriptorSet> writes;
for( UINT32 index = 0; index < descriptorSets.size(); ++index )
{
writes.push_back(
vk::WriteDescriptorSet( descriptorSets[index], 0, 0, 1,
vk::DescriptorType::eStorageImage,
&vk::DescriptorImageInfo( vk::Sampler(), imageViews[index], vk::ImageLayout::eGeneral ),
nullptr,
nullptr ) );
}
device.updateDescriptorSets( writes.size(), writes.data(), 0, nullptr );
With this approach only the last renderTarget in the queue presents the wanted result. The others produce just black screens.
But when i call updateDescriptorSets multiply times all works like expected:
std::vector<vk::WriteDescriptorSet> writes;
for( UINT32 index = 0; index < descriptorSets.size(); ++index )
{
writes.push_back(
vk::WriteDescriptorSet( descriptorSets[index], 0, 0, 1,
vk::DescriptorType::eStorageImage,
&vk::DescriptorImageInfo( vk::Sampler(), imageViews[index], vk::ImageLayout::eGeneral ),
nullptr,
nullptr ) );
device.updateDescriptorSets( writes.size(), writes.data(), 0, nullptr );
writes.clear();
}
I thought that i can update multiply descriptorSets at once. So it is not possible or what else could be my error.
PS: I use the c++ Header frome the vulkan SDK
c++ c++11 vulkan
c++ c++11 vulkan
asked Nov 23 '18 at 10:57
DanielDaniel
344
344
You can update multiple descriptors sets in a single call. This looks like a bug somewhere else in Your code or like a bug in a driver.
– Ekzuzy
Nov 23 '18 at 14:41
add a comment |
You can update multiple descriptors sets in a single call. This looks like a bug somewhere else in Your code or like a bug in a driver.
– Ekzuzy
Nov 23 '18 at 14:41
You can update multiple descriptors sets in a single call. This looks like a bug somewhere else in Your code or like a bug in a driver.
– Ekzuzy
Nov 23 '18 at 14:41
You can update multiple descriptors sets in a single call. This looks like a bug somewhere else in Your code or like a bug in a driver.
– Ekzuzy
Nov 23 '18 at 14:41
add a comment |
1 Answer
1
active
oldest
votes
The Bug is indeed in the application code.
The problem lies in the creation of the vk::DescriptorImageInfo. In both code examples the struct only exits in the scope of the for-loop but than only a pointer to the struct is copied in the vk::WriteDescriptorSet struct.
When the updateDescriptorSets in the first example processes the data in the structs, the relevant data is out of scope and the pointers are invalid. Coincidentally the application uses always the same memory space in every iteration of the loop and so the pointers points to the same invalid space where the data of the last loop iteration still exits. This is why the last render target shows the expected result.
Indeed, You create a temporary objects which get destroyed immediately after the loop. It's very easy to miss such mistakes. But validation layers should catch that.
– Ekzuzy
Nov 24 '18 at 18:00
1
@Ekzuzy The validation layers didnt catch that. I think because the data used for the updates was in itself valid. Only the read of the data was illegal but i believe there is no chance for the validation layer to know that.
– Daniel
Nov 24 '18 at 21:27
2
@Ekzuzy the validation layer couldn't catch that because the pointer is not null and the data looks valid because the compiler most likely reused the stackspace of previous iterations.
– ratchet freak
Nov 25 '18 at 8:57
@ratchetfreak Yeah, I understand that. In such cases step-by-step debugging should show valid, though undesired values. Another thing may be to try App Verifier.
– Ekzuzy
Nov 25 '18 at 14:36
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53445372%2fhow-update-multiply-descriptorsets-at-once%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The Bug is indeed in the application code.
The problem lies in the creation of the vk::DescriptorImageInfo. In both code examples the struct only exits in the scope of the for-loop but than only a pointer to the struct is copied in the vk::WriteDescriptorSet struct.
When the updateDescriptorSets in the first example processes the data in the structs, the relevant data is out of scope and the pointers are invalid. Coincidentally the application uses always the same memory space in every iteration of the loop and so the pointers points to the same invalid space where the data of the last loop iteration still exits. This is why the last render target shows the expected result.
Indeed, You create a temporary objects which get destroyed immediately after the loop. It's very easy to miss such mistakes. But validation layers should catch that.
– Ekzuzy
Nov 24 '18 at 18:00
1
@Ekzuzy The validation layers didnt catch that. I think because the data used for the updates was in itself valid. Only the read of the data was illegal but i believe there is no chance for the validation layer to know that.
– Daniel
Nov 24 '18 at 21:27
2
@Ekzuzy the validation layer couldn't catch that because the pointer is not null and the data looks valid because the compiler most likely reused the stackspace of previous iterations.
– ratchet freak
Nov 25 '18 at 8:57
@ratchetfreak Yeah, I understand that. In such cases step-by-step debugging should show valid, though undesired values. Another thing may be to try App Verifier.
– Ekzuzy
Nov 25 '18 at 14:36
add a comment |
The Bug is indeed in the application code.
The problem lies in the creation of the vk::DescriptorImageInfo. In both code examples the struct only exits in the scope of the for-loop but than only a pointer to the struct is copied in the vk::WriteDescriptorSet struct.
When the updateDescriptorSets in the first example processes the data in the structs, the relevant data is out of scope and the pointers are invalid. Coincidentally the application uses always the same memory space in every iteration of the loop and so the pointers points to the same invalid space where the data of the last loop iteration still exits. This is why the last render target shows the expected result.
Indeed, You create a temporary objects which get destroyed immediately after the loop. It's very easy to miss such mistakes. But validation layers should catch that.
– Ekzuzy
Nov 24 '18 at 18:00
1
@Ekzuzy The validation layers didnt catch that. I think because the data used for the updates was in itself valid. Only the read of the data was illegal but i believe there is no chance for the validation layer to know that.
– Daniel
Nov 24 '18 at 21:27
2
@Ekzuzy the validation layer couldn't catch that because the pointer is not null and the data looks valid because the compiler most likely reused the stackspace of previous iterations.
– ratchet freak
Nov 25 '18 at 8:57
@ratchetfreak Yeah, I understand that. In such cases step-by-step debugging should show valid, though undesired values. Another thing may be to try App Verifier.
– Ekzuzy
Nov 25 '18 at 14:36
add a comment |
The Bug is indeed in the application code.
The problem lies in the creation of the vk::DescriptorImageInfo. In both code examples the struct only exits in the scope of the for-loop but than only a pointer to the struct is copied in the vk::WriteDescriptorSet struct.
When the updateDescriptorSets in the first example processes the data in the structs, the relevant data is out of scope and the pointers are invalid. Coincidentally the application uses always the same memory space in every iteration of the loop and so the pointers points to the same invalid space where the data of the last loop iteration still exits. This is why the last render target shows the expected result.
The Bug is indeed in the application code.
The problem lies in the creation of the vk::DescriptorImageInfo. In both code examples the struct only exits in the scope of the for-loop but than only a pointer to the struct is copied in the vk::WriteDescriptorSet struct.
When the updateDescriptorSets in the first example processes the data in the structs, the relevant data is out of scope and the pointers are invalid. Coincidentally the application uses always the same memory space in every iteration of the loop and so the pointers points to the same invalid space where the data of the last loop iteration still exits. This is why the last render target shows the expected result.
answered Nov 24 '18 at 8:39
DanielDaniel
344
344
Indeed, You create a temporary objects which get destroyed immediately after the loop. It's very easy to miss such mistakes. But validation layers should catch that.
– Ekzuzy
Nov 24 '18 at 18:00
1
@Ekzuzy The validation layers didnt catch that. I think because the data used for the updates was in itself valid. Only the read of the data was illegal but i believe there is no chance for the validation layer to know that.
– Daniel
Nov 24 '18 at 21:27
2
@Ekzuzy the validation layer couldn't catch that because the pointer is not null and the data looks valid because the compiler most likely reused the stackspace of previous iterations.
– ratchet freak
Nov 25 '18 at 8:57
@ratchetfreak Yeah, I understand that. In such cases step-by-step debugging should show valid, though undesired values. Another thing may be to try App Verifier.
– Ekzuzy
Nov 25 '18 at 14:36
add a comment |
Indeed, You create a temporary objects which get destroyed immediately after the loop. It's very easy to miss such mistakes. But validation layers should catch that.
– Ekzuzy
Nov 24 '18 at 18:00
1
@Ekzuzy The validation layers didnt catch that. I think because the data used for the updates was in itself valid. Only the read of the data was illegal but i believe there is no chance for the validation layer to know that.
– Daniel
Nov 24 '18 at 21:27
2
@Ekzuzy the validation layer couldn't catch that because the pointer is not null and the data looks valid because the compiler most likely reused the stackspace of previous iterations.
– ratchet freak
Nov 25 '18 at 8:57
@ratchetfreak Yeah, I understand that. In such cases step-by-step debugging should show valid, though undesired values. Another thing may be to try App Verifier.
– Ekzuzy
Nov 25 '18 at 14:36
Indeed, You create a temporary objects which get destroyed immediately after the loop. It's very easy to miss such mistakes. But validation layers should catch that.
– Ekzuzy
Nov 24 '18 at 18:00
Indeed, You create a temporary objects which get destroyed immediately after the loop. It's very easy to miss such mistakes. But validation layers should catch that.
– Ekzuzy
Nov 24 '18 at 18:00
1
1
@Ekzuzy The validation layers didnt catch that. I think because the data used for the updates was in itself valid. Only the read of the data was illegal but i believe there is no chance for the validation layer to know that.
– Daniel
Nov 24 '18 at 21:27
@Ekzuzy The validation layers didnt catch that. I think because the data used for the updates was in itself valid. Only the read of the data was illegal but i believe there is no chance for the validation layer to know that.
– Daniel
Nov 24 '18 at 21:27
2
2
@Ekzuzy the validation layer couldn't catch that because the pointer is not null and the data looks valid because the compiler most likely reused the stackspace of previous iterations.
– ratchet freak
Nov 25 '18 at 8:57
@Ekzuzy the validation layer couldn't catch that because the pointer is not null and the data looks valid because the compiler most likely reused the stackspace of previous iterations.
– ratchet freak
Nov 25 '18 at 8:57
@ratchetfreak Yeah, I understand that. In such cases step-by-step debugging should show valid, though undesired values. Another thing may be to try App Verifier.
– Ekzuzy
Nov 25 '18 at 14:36
@ratchetfreak Yeah, I understand that. In such cases step-by-step debugging should show valid, though undesired values. Another thing may be to try App Verifier.
– Ekzuzy
Nov 25 '18 at 14:36
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53445372%2fhow-update-multiply-descriptorsets-at-once%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
You can update multiple descriptors sets in a single call. This looks like a bug somewhere else in Your code or like a bug in a driver.
– Ekzuzy
Nov 23 '18 at 14:41