cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

djee
Journeyman III

OpenGL 3.3 / GLSL 3.30 GPU / Linux x86_64 : Program linking stalls

glLinkProgram() stalls when inserting only a vertex shader, eating some memory

Hello! I have been developing a software for a few years under Linux (x86_64) using a custom library which encapsulates OpenGL calls. Until today, I used to insert each shader code (vertex, geometry, fragment) one at a time, compile, link, and if no error occurred process the next one. However earlier today I ran into what looks like a stalling bug. After compiling successfully a vertex shader, and attaching it to an empty program, I tried to link the program (glLinkProgram). While I never had any problem in the past with a vertex-shader-only program, this time the glLinkProgram just stalls, eating a good amount of memory, until I interrupt (CTRL+C) my software. As for today, possible sources of change include:

  1. Upgraded from Catalyst 10.6 to 10.12
  2. Started using instancing (gl_InstanceID with glDrawElementsInstanced) after I read a workaround for another bug (see this post)

Earlier today it went up to eating all the memory of the system, leaving me with no other solution but to reboot. This seems to have vanished, and now the stall just consumes a few hundreds of megs (visible on system monitor in task bar). Interrupting the software releases the memory though.

I didn't manage to find whether it is an error to use a vertex-shader-only GPU program in the OpenGL 3.3 and GLSL 3.30 specs, but in any case if it is I guess the glLinkProgram() should simply return with an error, not stalls the software.

As for the "standard" way of doing, I just switched to an approach where I first compile and attach all the shaders, then finally perform a single link on the completed program. This seems to work the "bug" around.

 

0 Likes
9 Replies
nou
Exemplar

it is valid to use vertex shader only as it is only shader from pipeline which is mandatory. and i use vertex shader only programs without issue on my ATI card.

try use only simple vertex shader.

0 Likes
djee
Journeyman III

Thanks for the reply. My vertex shader is all the more simple. It consists in copying all attributes for further stages (geometry and fragment), and setting the gl_Position as the product of a 4x4 matrix with a vec4 position vector (input attribute). Nothing more.

// Shader
void main()
{
    // int inst = gl_InstanceID;
    int inst = 1;
   
    // Copy attributes
    geo.pos   = ipos;
    geo.tex   = itex;
    geo.col   = icol;
   
    // Fetch primitive infos; TEMP: fixed value
    vec4 pos_size = vec4(100.0 + inst * 30.0, 200.0 + inst * 20.0, 200.0, 150.0);
   
    // Compute position of vertex
    gl_Position = mat.proj * mat.tran * vec4(ipos * pos_size.ba + pos_size.xy, 0.0, 1.0);
}

0 Likes

The spec now allows there is no attribute 0 bound, but the driver requires the 0 attribute. This is a known bug. It will be fixed soon.

0 Likes
djee
Journeyman III

Hello. Thanks for your reply to this post.

However, in my opinion this does not explains why the glLinkProgram() stalls, eating part or all of my RAM, leaving me with no other solution but to interrupt my program. In short, when the "bug" occurs, I cannot go past the glLinkProgram() in the following pseudo-code:

vrt = glCreateShader(GL_VERTEX_SHADER);
glShaderSource(vrt, 1, my_vrt_txt, 0);
glCompileShader(vrt);
GLint ret;
glGetShaderiv(vrt, GL_COMPILE_STATUS, &ret);
if ( ret == GL_TRUE )
{
    glAttachShader(program, vrt);
    glLinkProgram(program); <------------- Stalls here
    GLint linkstatus = GL_FALSE;  <-------- never reached when bug occurs
    glGetProgramiv(program, GL_LINK_STATUS, &linkstatus);
    [...]
}

0 Likes

I don't see any problems in your pseudo-code. The attribute zero issue has been complained about by some users, but they never say there is some memory leak issues. Could you please narrow down your project and send it to me by frank.li@amd.com? We will take a look at it.

Thanks
Frank 

0 Likes
djee
Journeyman III

I just spent 2 hours removing useless code, making frequent archives for the case the bug suddenly disappear...

It disappeared after some removals. So I extracted the archive of the previous version where it was here. Oh surprise... now it disappeared from this archive version also! I'm totally lost...

Note the bug was 100% reproductible (>50 successive runs with RAM eating) until it dissapeared sunddenly after moving/deleting some code. Also note that my OpenGL wrapper was removed at some point, and the bug still occured while I was calling directly the OpenGL library functions (static link -lGL).

I'll give a try next time if I get motived to lost another couple of hours...

0 Likes
djee
Journeyman III

It was bugging me so I removed the directory of the project completely and un-archived the old version. The bug is back!

I need some more time to remove useless stuffs and narrow down further the project. I'll send you Frank the code when it's light and understandable.

Thanks

0 Likes

djee recomend using some VCS like git,mercurial or svn.

0 Likes
djee
Journeyman III

I use git. It's really nice.

But I was not sure whether I can copy a project directory containing a git repository without messing with the original. If there are some absolute path I could blow down my project. So for safety reasons I just made a copy of my project and worked on that copy. I'm not finished yet though.

0 Likes