How update multiply descriptorSets at once












2















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










share|improve this question























  • 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
















2















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










share|improve this question























  • 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














2












2








2








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










share|improve this question














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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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



















  • 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












1 Answer
1






active

oldest

votes


















2














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.






share|improve this answer
























  • 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











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
});


}
});














draft saved

draft discarded


















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









2














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.






share|improve this answer
























  • 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
















2














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.






share|improve this answer
























  • 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














2












2








2







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.






share|improve this answer













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.







share|improve this answer












share|improve this answer



share|improve this answer










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



















  • 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


















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

Berounka

Sphinx de Gizeh

Different font size/position of beamer's navigation symbols template's content depending on regular/plain...