Why is it necessary to separate and remove shaders after they are created, on OpenGL?

Question

I follow this tutorial (link) , which says that after linking it, you need to separate the shaders from the program, and that you should delete them after that.

Performing a parallel with C ++ compilation, I believe that “binding” is the act of actually creating a program (such as creating an executable file), this disabling means somehow deleting the pointer to the shader object (which I assume that it similar to .o ), in a program (which is still not very clear) - is it not a program compiled at the moment? How does she still hold the pointer to something?) - and this removal is similar to actually deleting these .o from the folder.

But this is all speculation, so what is really going on there?

Answer 1

From an OpenGL document in glDeleteShader :

If the shader object to be deleted is attached to the program object, it will be marked for deletion, but it will not be deleted until it is no longer attached to any program object, for any rendering context (i.e. it should be detached from the place where it was attached before it is removed)

So, this is more like a decrement of the link counter than the actual deletion.

Answer 2

This can help if you understand that several programs can use the same shader. If just disconnecting it from the program forced it to be deleted, then things like separate shader objects in OpenGL 4.1 would have been implemented much earlier.

You should also be aware that the link does refer to more or less validation. When the shaders are connected to create the program, the input / output variables are all connected, and the identifiers are assigned to the forms used. When the program starts, it fills each stage of the graphics pipeline with a shader. Thus, all the program does is encapsulate several stages of the shader.

This is much clearer if you examine the specification of the ARB_separate_shader_objects extension, which introduces the concept of program pipeline objects. Instead of having one program with a shader for each stage, you can have one program for each stage. The entire program of the GLSL program has always been a bit dumb, in most other APIs you have separate shaders for each stage, and none of these programs binds non-sense.

Use the analogy with an executable program. GLSL shaders are actual executable files, GLSL programs are powerful job management scripts. Your program is responsible for ensuring that each of your shaders works at its own stage in the pipeline and serves as an interface for passing variables (uniforms) to them.