Concurrent SSBO readings failling in fragment shader









up vote
3
down vote

favorite












Major edit:



I have one shader setting the values of an SSBO:



#version 430

//Input variables
in vec3 f_pos;
in vec3 f_norm;
in vec3 f_uv;

struct Voxel_Node

vec4 color;
vec4 normal;
uint children[8];
;
//Buffer for the rest of the tree
layout(std430, binding = 0) buffer tree_buffer

uint t_index;
uint pad1;
uint pad2;
uint pad3;
Voxel_Node tree;
;

void main()

tree[0].children[7] = 1;
tree[1].children[0] = 2;
tree[2].children[7] = 3;
tree[3].children[0] = 4;
tree[4].children[7] = 5;

tree[0].normal = vec4(0,0,1,1);
tree[1].normal = vec4(0,1,0,1);
tree[2].normal = vec4(0,1,1,1);
tree[3].normal = vec4(1,0,0,1);
tree[4].normal = vec4(1,0,1,1);
tree[5].normal = vec4(1,1,0,1);



And one shader reading from the SSBO:



#version 430
#pragma optimize (off)

in vec2 f_coord;

out vec4 fragment_color;

struct Voxel_Node

vec4 color;
vec4 normal;
uint children[8];
;
//Buffer for the rest of the tree
layout(std430, binding = 0) buffer tree_buffer

uint t_index;
uint pad1;
uint pad2;
uint pad3;
Voxel_Node tree;
;


void main()

fragment_color = vec4(tree[1].children[0]);
int pls = int(tree[1].children[0]);
//set 1
fragment_color = vec4(pls); //white
//fragment_color = vec4(pls-1); //white
//fragment_color = vec4(pls-2); //black
//fragment_color = vec4(pls)/2.f; //grey

//Set 2
fragment_color = tree[pls].normal; //blue
//fragment_color = tree[pls+2].normal; //cyan
//fragment_color = tree[2].normal; //cyan



There are 2 sets of tests. first, comment out the tree[value].normal block.



So that the fragment color depends on the value of pls. Only one of the 2 blocks may be uncomented at a time and only one line within each block. The values on the right are the resulting color of the test.



The first block of tests is successful all of those are the expected outputs. For the second block of tests,the first output should be blue and the secddn output should not be cyan.



According to these tests the value of pls is 2 when read by the first set of tests but 0 when read by the second set.



There is no other logic than trying to read the contents of the SSBO, what could cause this kind of behaviour?



Edit:



I think it may be due to this but I am not sure:



https://www.khronos.org/opengl/wiki/Memory_Model#Incoherent_memory_access



Update:



Setting the SSBO to be of constant size "solved" the issue, however I'd rather be able to use varying size ssbo's.



coherent layout(std430, binding = 0) buffer tree_buffer

uint t_index;
uint pad1;
uint pad2;
uint pad3;
Voxel_Node tree[8];
;


Modifying the code to the above results in teh expected behaviour










share|improve this question























  • How do you even create the contents of the SSBO?
    – derhass
    Nov 11 at 16:26










  • Updated the question.
    – Makogan
    Nov 11 at 16:29










  • Do you have proper memory barriers between the execution of the two?
    – derhass
    Nov 11 at 16:30










  • I call ' glMemoryBarrier(GL_SHADER_STORAGE_BARRIER_BIT); ' in between the 2 calls, is that enough?
    – Makogan
    Nov 11 at 16:32











  • The contents are fine btw, I colored the screen with the values of tree[0].normal; tree[1].normal; ... And the colors matched initialization
    – Makogan
    Nov 11 at 16:36














up vote
3
down vote

favorite












Major edit:



I have one shader setting the values of an SSBO:



#version 430

//Input variables
in vec3 f_pos;
in vec3 f_norm;
in vec3 f_uv;

struct Voxel_Node

vec4 color;
vec4 normal;
uint children[8];
;
//Buffer for the rest of the tree
layout(std430, binding = 0) buffer tree_buffer

uint t_index;
uint pad1;
uint pad2;
uint pad3;
Voxel_Node tree;
;

void main()

tree[0].children[7] = 1;
tree[1].children[0] = 2;
tree[2].children[7] = 3;
tree[3].children[0] = 4;
tree[4].children[7] = 5;

tree[0].normal = vec4(0,0,1,1);
tree[1].normal = vec4(0,1,0,1);
tree[2].normal = vec4(0,1,1,1);
tree[3].normal = vec4(1,0,0,1);
tree[4].normal = vec4(1,0,1,1);
tree[5].normal = vec4(1,1,0,1);



And one shader reading from the SSBO:



#version 430
#pragma optimize (off)

in vec2 f_coord;

out vec4 fragment_color;

struct Voxel_Node

vec4 color;
vec4 normal;
uint children[8];
;
//Buffer for the rest of the tree
layout(std430, binding = 0) buffer tree_buffer

uint t_index;
uint pad1;
uint pad2;
uint pad3;
Voxel_Node tree;
;


void main()

fragment_color = vec4(tree[1].children[0]);
int pls = int(tree[1].children[0]);
//set 1
fragment_color = vec4(pls); //white
//fragment_color = vec4(pls-1); //white
//fragment_color = vec4(pls-2); //black
//fragment_color = vec4(pls)/2.f; //grey

//Set 2
fragment_color = tree[pls].normal; //blue
//fragment_color = tree[pls+2].normal; //cyan
//fragment_color = tree[2].normal; //cyan



There are 2 sets of tests. first, comment out the tree[value].normal block.



So that the fragment color depends on the value of pls. Only one of the 2 blocks may be uncomented at a time and only one line within each block. The values on the right are the resulting color of the test.



The first block of tests is successful all of those are the expected outputs. For the second block of tests,the first output should be blue and the secddn output should not be cyan.



According to these tests the value of pls is 2 when read by the first set of tests but 0 when read by the second set.



There is no other logic than trying to read the contents of the SSBO, what could cause this kind of behaviour?



Edit:



I think it may be due to this but I am not sure:



https://www.khronos.org/opengl/wiki/Memory_Model#Incoherent_memory_access



Update:



Setting the SSBO to be of constant size "solved" the issue, however I'd rather be able to use varying size ssbo's.



coherent layout(std430, binding = 0) buffer tree_buffer

uint t_index;
uint pad1;
uint pad2;
uint pad3;
Voxel_Node tree[8];
;


Modifying the code to the above results in teh expected behaviour










share|improve this question























  • How do you even create the contents of the SSBO?
    – derhass
    Nov 11 at 16:26










  • Updated the question.
    – Makogan
    Nov 11 at 16:29










  • Do you have proper memory barriers between the execution of the two?
    – derhass
    Nov 11 at 16:30










  • I call ' glMemoryBarrier(GL_SHADER_STORAGE_BARRIER_BIT); ' in between the 2 calls, is that enough?
    – Makogan
    Nov 11 at 16:32











  • The contents are fine btw, I colored the screen with the values of tree[0].normal; tree[1].normal; ... And the colors matched initialization
    – Makogan
    Nov 11 at 16:36












up vote
3
down vote

favorite









up vote
3
down vote

favorite











Major edit:



I have one shader setting the values of an SSBO:



#version 430

//Input variables
in vec3 f_pos;
in vec3 f_norm;
in vec3 f_uv;

struct Voxel_Node

vec4 color;
vec4 normal;
uint children[8];
;
//Buffer for the rest of the tree
layout(std430, binding = 0) buffer tree_buffer

uint t_index;
uint pad1;
uint pad2;
uint pad3;
Voxel_Node tree;
;

void main()

tree[0].children[7] = 1;
tree[1].children[0] = 2;
tree[2].children[7] = 3;
tree[3].children[0] = 4;
tree[4].children[7] = 5;

tree[0].normal = vec4(0,0,1,1);
tree[1].normal = vec4(0,1,0,1);
tree[2].normal = vec4(0,1,1,1);
tree[3].normal = vec4(1,0,0,1);
tree[4].normal = vec4(1,0,1,1);
tree[5].normal = vec4(1,1,0,1);



And one shader reading from the SSBO:



#version 430
#pragma optimize (off)

in vec2 f_coord;

out vec4 fragment_color;

struct Voxel_Node

vec4 color;
vec4 normal;
uint children[8];
;
//Buffer for the rest of the tree
layout(std430, binding = 0) buffer tree_buffer

uint t_index;
uint pad1;
uint pad2;
uint pad3;
Voxel_Node tree;
;


void main()

fragment_color = vec4(tree[1].children[0]);
int pls = int(tree[1].children[0]);
//set 1
fragment_color = vec4(pls); //white
//fragment_color = vec4(pls-1); //white
//fragment_color = vec4(pls-2); //black
//fragment_color = vec4(pls)/2.f; //grey

//Set 2
fragment_color = tree[pls].normal; //blue
//fragment_color = tree[pls+2].normal; //cyan
//fragment_color = tree[2].normal; //cyan



There are 2 sets of tests. first, comment out the tree[value].normal block.



So that the fragment color depends on the value of pls. Only one of the 2 blocks may be uncomented at a time and only one line within each block. The values on the right are the resulting color of the test.



The first block of tests is successful all of those are the expected outputs. For the second block of tests,the first output should be blue and the secddn output should not be cyan.



According to these tests the value of pls is 2 when read by the first set of tests but 0 when read by the second set.



There is no other logic than trying to read the contents of the SSBO, what could cause this kind of behaviour?



Edit:



I think it may be due to this but I am not sure:



https://www.khronos.org/opengl/wiki/Memory_Model#Incoherent_memory_access



Update:



Setting the SSBO to be of constant size "solved" the issue, however I'd rather be able to use varying size ssbo's.



coherent layout(std430, binding = 0) buffer tree_buffer

uint t_index;
uint pad1;
uint pad2;
uint pad3;
Voxel_Node tree[8];
;


Modifying the code to the above results in teh expected behaviour










share|improve this question















Major edit:



I have one shader setting the values of an SSBO:



#version 430

//Input variables
in vec3 f_pos;
in vec3 f_norm;
in vec3 f_uv;

struct Voxel_Node

vec4 color;
vec4 normal;
uint children[8];
;
//Buffer for the rest of the tree
layout(std430, binding = 0) buffer tree_buffer

uint t_index;
uint pad1;
uint pad2;
uint pad3;
Voxel_Node tree;
;

void main()

tree[0].children[7] = 1;
tree[1].children[0] = 2;
tree[2].children[7] = 3;
tree[3].children[0] = 4;
tree[4].children[7] = 5;

tree[0].normal = vec4(0,0,1,1);
tree[1].normal = vec4(0,1,0,1);
tree[2].normal = vec4(0,1,1,1);
tree[3].normal = vec4(1,0,0,1);
tree[4].normal = vec4(1,0,1,1);
tree[5].normal = vec4(1,1,0,1);



And one shader reading from the SSBO:



#version 430
#pragma optimize (off)

in vec2 f_coord;

out vec4 fragment_color;

struct Voxel_Node

vec4 color;
vec4 normal;
uint children[8];
;
//Buffer for the rest of the tree
layout(std430, binding = 0) buffer tree_buffer

uint t_index;
uint pad1;
uint pad2;
uint pad3;
Voxel_Node tree;
;


void main()

fragment_color = vec4(tree[1].children[0]);
int pls = int(tree[1].children[0]);
//set 1
fragment_color = vec4(pls); //white
//fragment_color = vec4(pls-1); //white
//fragment_color = vec4(pls-2); //black
//fragment_color = vec4(pls)/2.f; //grey

//Set 2
fragment_color = tree[pls].normal; //blue
//fragment_color = tree[pls+2].normal; //cyan
//fragment_color = tree[2].normal; //cyan



There are 2 sets of tests. first, comment out the tree[value].normal block.



So that the fragment color depends on the value of pls. Only one of the 2 blocks may be uncomented at a time and only one line within each block. The values on the right are the resulting color of the test.



The first block of tests is successful all of those are the expected outputs. For the second block of tests,the first output should be blue and the secddn output should not be cyan.



According to these tests the value of pls is 2 when read by the first set of tests but 0 when read by the second set.



There is no other logic than trying to read the contents of the SSBO, what could cause this kind of behaviour?



Edit:



I think it may be due to this but I am not sure:



https://www.khronos.org/opengl/wiki/Memory_Model#Incoherent_memory_access



Update:



Setting the SSBO to be of constant size "solved" the issue, however I'd rather be able to use varying size ssbo's.



coherent layout(std430, binding = 0) buffer tree_buffer

uint t_index;
uint pad1;
uint pad2;
uint pad3;
Voxel_Node tree[8];
;


Modifying the code to the above results in teh expected behaviour







multithreading opengl graphics glsl gpu






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 11 at 21:01

























asked Nov 11 at 16:17









Makogan

1,6291728




1,6291728











  • How do you even create the contents of the SSBO?
    – derhass
    Nov 11 at 16:26










  • Updated the question.
    – Makogan
    Nov 11 at 16:29










  • Do you have proper memory barriers between the execution of the two?
    – derhass
    Nov 11 at 16:30










  • I call ' glMemoryBarrier(GL_SHADER_STORAGE_BARRIER_BIT); ' in between the 2 calls, is that enough?
    – Makogan
    Nov 11 at 16:32











  • The contents are fine btw, I colored the screen with the values of tree[0].normal; tree[1].normal; ... And the colors matched initialization
    – Makogan
    Nov 11 at 16:36
















  • How do you even create the contents of the SSBO?
    – derhass
    Nov 11 at 16:26










  • Updated the question.
    – Makogan
    Nov 11 at 16:29










  • Do you have proper memory barriers between the execution of the two?
    – derhass
    Nov 11 at 16:30










  • I call ' glMemoryBarrier(GL_SHADER_STORAGE_BARRIER_BIT); ' in between the 2 calls, is that enough?
    – Makogan
    Nov 11 at 16:32











  • The contents are fine btw, I colored the screen with the values of tree[0].normal; tree[1].normal; ... And the colors matched initialization
    – Makogan
    Nov 11 at 16:36















How do you even create the contents of the SSBO?
– derhass
Nov 11 at 16:26




How do you even create the contents of the SSBO?
– derhass
Nov 11 at 16:26












Updated the question.
– Makogan
Nov 11 at 16:29




Updated the question.
– Makogan
Nov 11 at 16:29












Do you have proper memory barriers between the execution of the two?
– derhass
Nov 11 at 16:30




Do you have proper memory barriers between the execution of the two?
– derhass
Nov 11 at 16:30












I call ' glMemoryBarrier(GL_SHADER_STORAGE_BARRIER_BIT); ' in between the 2 calls, is that enough?
– Makogan
Nov 11 at 16:32





I call ' glMemoryBarrier(GL_SHADER_STORAGE_BARRIER_BIT); ' in between the 2 calls, is that enough?
– Makogan
Nov 11 at 16:32













The contents are fine btw, I colored the screen with the values of tree[0].normal; tree[1].normal; ... And the colors matched initialization
– Makogan
Nov 11 at 16:36




The contents are fine btw, I colored the screen with the values of tree[0].normal; tree[1].normal; ... And the colors matched initialization
– Makogan
Nov 11 at 16:36

















active

oldest

votes











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',
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%2f53250665%2fconcurrent-ssbo-readings-failling-in-fragment-shader%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown






























active

oldest

votes













active

oldest

votes









active

oldest

votes






active

oldest

votes















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.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • 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%2f53250665%2fconcurrent-ssbo-readings-failling-in-fragment-shader%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







這個網誌中的熱門文章

How to read a connectionString WITH PROVIDER in .NET Core?

In R, how to develop a multiplot heatmap.2 figure showing key labels successfully

Museum of Modern and Contemporary Art of Trento and Rovereto