OpenGL: cannot link SPIR-V shaders

[kirill146]

Hello! I was redirected to this forum from Intel's graphics product support one.

When I try to link SPIR-V binaries using glLinkProgram(), it works fine, but only for the first pair of shaders. With the next one it fails with an empty info log and weird message in OpenGL's debug callback:

SHADER_ID_LINK error has been generated. GLSL link failed for program 5, "":

I've added a minimal repro on GitHub.

It's tested on ASUS ROG Strix G16 laptop with i7-13650HX and on a desktop computer with i5-7400 integrated graphics.

If it's not the right place to file a bug, please let me know where it is. Thanks

[VarshaS_Intel]

Hi,

Thanks for posting in Intel Communities.

Could you please let us know the details of your OS, hardware, and Intel Products /Tools being used?

Also, Could you please let us know what steps you followed and which analysis are you trying to perform?

Could you please provide us with the complete log or error you are facing?

Thanks & Regards,

Varsha

[VarshaS_Intel]

Hi,

When moving the shader creation lines into the loop makes things work so is this what you are supposed to do in OpenGL?

Or, Are you supposed to be able to reuse the same ones over and over? If it is the former, then you can change your code and let us know so we can close the issue on our end.

If it is the latter, could you please let us know, as it is a driver issue where we need to contact the driver team to make changes?

Thanks & Regards,

Varsha

[kirill146]

Hello,

It's definitely allowed to reuse the same shader objects in different program objects. OpenGL specification says

It is also permissible to attach a shader object to more than one program object.

 Also I've just added a second example of shaders, which fail to link unconditionally (on the very first call to CreateProgram()).

So yeah, please contact the driver team.

Thanks.

[VarshaS_Intel]

Hi,

Thanks for your reply.

We are working on your issue internally. We will get back to you soon.

Thanks & Regards,

Varsha

[VarshaS_Intel]

Hi,

Thanks for your patience. Apologies, for the delay in the response.

There seems to be a problem in your code, please check this link for more details

uint32_t CreateProgram(uint32_t vs, uint32_t ps) {

  uint32_t program = glCreateProgram();

  program = glCreateProgram();  <-- just stepped on program variable. 

You are attempting to destroy the program, which doesn't check if it's really done before re-using things that may not have been detached, See https://registry.khronos.org/OpenGL-Refpages/gl4/html/glDeleteProgram.xhtml for 

glCreateProgram

glCreateProgram (trashing the first one)

glAttachShadder

glAttachShader

glLInkProgram

glDeleteProgram(no check or wait...)

glCreateProgram

glClreateProgram

glAttachShader (no check !)

glAttachShader (no check!)

glLinkProgram (fails..... )

Thanks & Regards,

Varsha

[kirill146]

Hello,

Thanks for your investigation.

First of all, there is indeed a problem in my code: extra glCreateProgram() should be removed. Technically it's not an error from OpenGL's point of view, it's just about leaked resource. No idea how I didn't catch that, my bad, now it's fixed.

However, the real problem is still there. I'm not sure if I understood you though: what do you mean by "not checking if it's really done before re-using things that may not have been detached"? As I said earlier, shader objects and program objects are kinda independent of one another. Correct me if I'm wrong, but

1. I can reuse the same shader objects in different program objects;
2. Shader objects are not deleted during deletion of program objects;
3. I don't have to manually detach shader objects before deleting a program object; glDeleteProgram() does it automatically;
4. There's no way to check if glDeleteProgram(progId) has actually finished since progId is invalid right after this call. If we called glUseProgram(progId) before, we would be able to request something like GL_DELETE_STATUS, but it also wouldn't tell much, since it's just indication whether or not glDeleteProgram() was called. So in this case, from the user's point of view, the program is deleted and shaders are detached at the moment when glDeleteProgram() returns;
5. In modern APIs like Vulkan I actually have to make sure that pipeline is not in use by any submitted commands when vkDestroyPipeline() is called. In OpenGL such things are in driver's responsibility.

Also I've tried to insert

glFlush();
std::this_thread::sleep_for(std::chrono::seconds(1));

after every GL call. It didn't change anything, so waiting isn't an option.

And what about the second example? It fails even before any of glDelete*() functions is called.

Thanks

[Filoippo]

Any new on this topic? This seems a problem of the Intel drivers with Spir-V

[Pamela_H_Intel]

Kirill - which Graphics Driver are you using?

[Pamela_H_Intel]

and did this work before for you? Or have you not tried using SPIRV shaders in this way before? If you did, which driver were you using?

I ask because I assume it's a regression . . . I have tracked down the correct driver team to address this issue to and their bug report app asks for very specific info. I can't submit the ticket without the info.

[kirill146]

Hello,

I'm using driver 31.0.101.4900 which is the latest driver for the time being.

I haven't tried using SPIR-V shaders before July 2023 (when this issue was created), so I can't say anything about the older drivers.

[shawnhatori]

I want to follow up here that I've been experiencing this same issue with OpenGL 4.6 support for over a year across various Intel driver versions. I only have one vertex shader and one fragment shader. I read in both SPIR-V shader binaries, but on `glLinkProgram()`, I get

SHADER_ID_LINK error has been generated. GLSL link failed for program 3, "":

I am currently testing this on Intel Arc integrated graphics on an Intel Core Ultra 7 155H, but I have also tested this on Intel Iris graphics on a Core i5-12400 with the exact same issue.

Current Driver Version: 31.0.101.5334

It is important to note that I have also tested this exact same codebase and project on AMD hardware and it does not exhibit this issue.