# Shader compile log depending on hardware

I'm done with the core of my graphics engine and I'm testing it on every platform I can get my hands on. Now, what I noticed is that different drivers return different shader and program compile log content.

For example, on my friend's laptop if you successfuly compile a shader then the log is simply empty. However on my PC I get some useful information along with it.

So if I compile a vertex shader, I'll get:

Vertex shader was successfully compiled to run on hardware.

Which isn't that impressive, but is what happens when I compile a program. On my friend's computer the log is empty, since the program compiles. However on my own computer I get:

Which is awesome, because I'm attaching a geometry shader with 0 (I have a geometry shader file with trash, so it doesn't compile and the pointer is set to 0), and the compiler just tells me which shaders linked.

Now it got me thinking, if I was going to buy a graphics card, is there a way for me to get the information about whether or not I'll get this "extended" compile information? Maybe it's vendor specific? Now I don't expect an answer TBH, this seems a bit obscure, but maybe somebody has any experience with this and could post it.

Well, what I do in my engine is write the contents of the shader log to my own log, regardless of whether the compile failed or not. Then I check whether the compile actually failed. Here's what that looks like:

    // compile vertex shader

const char* code_vert = m_CodeVertex.c_str();

if (bufflen > 1)
{
GLchar* log_string = new char[bufflen + 1];
LOG_TRACE("Log found when compiling '%s.vert':\n%s", m_Name.GetData(), log_string);

delete log_string;
}

if (success != GL_TRUE)
{
return false;
}



So, to answer our question: I don't think there's a way to detect whether a vendor returns an empty string on success or a string with "No errors". The best you can do is output the log when you have one, but also check whether it actually compiled.

With OpenGL the hardware vendor must provide the full GLSL compiler as part of their driver, so you're always going to get different results for different vendors, and may even get different results for different revisions of the same vendor's driver.

The textual output in the logs is useful for helping with errors, but I honestly wouldn't rely on it for much else. For the specific case you mentioned - which shaders are attached post-link - try glGetAttachedShaders instead. There are other glGets which will also give the kind of useful info you're looking for but won't be hardware-dependent, so that's the way to go (plus you can programmatically respond to unwanted conditions without having to parse textual output).

The shader is compiled by your graphics driver. As far as I am aware, it is done on the CPU but cannot be done without the GPU because it needs to know the target platform's features and limitations (although that's not entirely true... there are some compilers that can compile offline but just like our C/C++ compilers, they must have a target platform).

Anyway, the point of the above paragraph was to conclude that the compile errors you will get (or won't get) depend directly on the vendor and their drivers for the graphics card.

So is there any way to get the information before hand? That is a very good question and unfortunately I could not find any documentation with the drivers that would allow us to assess what the compiler features are (and perhaps a list of error/success codes which will in turn let us know the errors it is capable of handling).

As others have said, the output depends on vendor and driver version since that's where the compilation occurs.

I wrote an offline command-line app that compiles the shaders and just spits the log back to stdout and stderr. I run that as a compilation step within Visual Studio, which parses the output (which most drivers report in a standard format with line/col numbers, etc.) and reports it to the error and warning list as appropriate. It's nice to be able to see and navigate to errors at compile time, and the tool was very simple to create.