WARNING: Could not find vertex shader attribute 'webgl_178fd81400000002' to match BindAttributeLocation request.

763 views
Skip to first unread message

LJA

unread,
Aug 12, 2016, 11:06:07 AM8/12/16
to emscripten-discuss
Hi,

I have a very simple pair of shaders. After creating a program with them, glGetProgramInfoLog gives this warning:
WARNING: Could not find vertex shader attribute 'webgl_178fd81400000002' to match BindAttributeLocation request.

Here are the shaders:


#version 100
precision mediump
float;
attribute vec3 in_position
;

void main() {
 gl_Position
= vec4(in_position, 1);
}




#version 100
precision mediump
float;

void main() {
 gl_FragColor
= vec4(0, 0, 1, 1);
}


This is how I load the shaders:


GLuint gr_loadShader(const char* filePath, GLenum shaderType) {
 FILE
* file = resources::openFile(filePath, "rb");
 
if (!file) {
 DLOG
("Failed to open shader %s\n", filePath);
 
return 0;
 
}
 fseek
(file, 0, SEEK_END);
 
long fileSize = ftell(file);
 fseek
(file, 0, SEEK_SET);
 
char* shaderSource = (char*)malloc(fileSize + 1);
 fread
(shaderSource, fileSize, 1, file);
 fclose
(file);
 shaderSource
[fileSize] = '\0';


 
GLuint shaderID = glCreateShader(shaderType);

 error
("glCreateShader");
 
GLint result = GL_FALSE;
 
int InfoLogLength;
 glShaderSource
(shaderID, 1, (const GLchar**)&shaderSource, NULL);

 glCompileShader
(shaderID);



 
// Check the shader
 glGetShaderiv
(shaderID, GL_COMPILE_STATUS, &result);
 glGetShaderiv
(shaderID, GL_INFO_LOG_LENGTH, &InfoLogLength);
 
char errorMessage[InfoLogLength];
 glGetShaderInfoLog
(shaderID, InfoLogLength, NULL, errorMessage);
 DLOG
("%s\n", errorMessage);


 
return shaderID;

}


GLuint gr_createProgram(const char* vs, const char* fs) {

 
char vsFilePath[128];
 
char fsFilePath[128];
 sprintf
(vsFilePath, "assets/shaders/gles1/%s.vs", vs);
 sprintf
(fsFilePath, "assets/shaders/gles1/%s.fs", fs);
 
GLuint vsID = gr_loadShader(vsFilePath, GL_VERTEX_SHADER);
 
GLuint fsID = gr_loadShader(fsFilePath, GL_FRAGMENT_SHADER);
 
GLuint programID = glCreateProgram();
 error
("glCreateProgran");
 glAttachShader
(programID, vsID);
 error
("glAttachShader vs");
 glAttachShader
(programID, fsID);
 error
("glAttachShader fs");
 glLinkProgram
(programID);
 error
("glLinkProgram");

 glDeleteShader
(vsID);
 glDeleteShader
(fsID);


 
GLint result = GL_FALSE;
 
int InfoLogLength;
 glGetProgramiv
(programID, GL_LINK_STATUS, &result);
  glGetProgramiv
(programID, GL_INFO_LOG_LENGTH, &InfoLogLength);
 
char errorMessage[512]{'\0'};
 glGetProgramInfoLog
(programID, InfoLogLength, NULL, errorMessage);
 DLOG
("Program Info: %s\n", errorMessage);
 
return programID;
}


Same code doesn't cause issues on desktop (OpenGL 2 at least)

Why am I seeing this warning?

キャロウ マーク

unread,
Aug 12, 2016, 1:56:07 PM8/12/16
to emscripte...@googlegroups.com
On Aug 12, 2016, at 8:06 AM, LJA <jahv...@gmail.com> wrote:

Hi,

I have a very simple pair of shaders. After creating a program with them, glGetProgramInfoLog gives this warning:
WARNING: Could not find vertex shader attribute 'webgl_178fd81400000002' to match BindAttributeLocation request.


Same code doesn't cause issues on desktop (OpenGL 2 at least)

Why am I seeing this warning?


You need to show us your code that calls glBindAttributeLocation, if we are to help you. The code fragment, that I elided above, does not contain that call.

Regards

    -Mark

--

Mark Callow
President
www.edgewise-consulting.com

LJA

unread,
Aug 13, 2016, 5:28:56 AM8/13/16
to emscripten-discuss, git...@callow.im
Well the weird part is that I get the warning from the part of code I showed you:  DLOG("Program Info: %s\n", errorMessage);
I get it without making calls to glBindAttributeLocation.

キャロウ マーク

unread,
Aug 14, 2016, 3:07:10 PM8/14/16
to emscripte...@googlegroups.com

On Aug 13, 2016, at 2:28 AM, LJA <jahv...@gmail.com> wrote:

Well the weird part is that I get the warning from the part of code I showed you:  DLOG("Program Info: %s\n", errorMessage);
I get it without making calls to glBindAttributeLocation.


The attribute name is coming from WebGL. Which browser and OS are you using? This is most likely happening when ANGLE rewrites your shader. I think some browsers have a way to look at the rewritten shader. Doing that will likely help.

LJA

unread,
Aug 15, 2016, 7:48:32 AM8/15/16
to emscripten-discuss, git...@callow.im
I'm using osx and safari. Haven't had time to test other setups. Could ANGLE still be causing this?

LJA

unread,
Aug 15, 2016, 11:21:26 AM8/15/16
to emscripten-discuss, git...@callow.im
I now tested the same code in chrome. The attribute in question is "a_position". It's nothing I'm using in my shaders, but doing a search in my project reveals that SDL has some built in shader using it.
Why am I seeing errors from a SDL shader after compiling my own shaders?

キャロウ マーク

unread,
Aug 15, 2016, 5:53:59 PM8/15/16
to emscripte...@googlegroups.com

On Aug 15, 2016, at 4:48 AM, LJA <jahv...@gmail.com> wrote:

I'm using osx and safari. Haven't had time to test other setups. Could ANGLE still be causing this?

I have found one reference that says Safari uses ANGLE for shader validation but have not been able to find a definitive answer to your question.

キャロウ マーク

unread,
Aug 15, 2016, 6:11:18 PM8/15/16
to emscripte...@googlegroups.com
On Aug 15, 2016, at 8:21 AM, LJA <jahv...@gmail.com> wrote:

I now tested the same code in chrome. The attribute in question is "a_position". It's nothing I'm using in my shaders, but doing a search in my project reveals that SDL has some built in shader using it.
Why am I seeing errors from a SDL shader after compiling my own shaders?

Are you saying Chrome gives you the same error but with the attribute name "a_position”?

“a_position” is a very common attribute name so it may not be SDL’s that you are seeing. For it to be SDL’s you would have to be using the same “programID” value as SDL when you call glLinkProgram and SDL would have had to call BindAttribLocation before your call your gr_createProgram function. It is possible that Emscripten’s OpenGL ES to WebGL wrapper could have such a problem but I am unaware of any previous reports like this. The presence of “webgl” in the name in the initial error certainly looks like WebGL shader validation name mangling but perhaps Emscripten does name mangling as well.

LJA

unread,
Aug 16, 2016, 3:20:38 AM8/16/16
to emscripten-discuss, git...@callow.im
Yes, the error is the same but now the attribute is called "a_position". SDL's shader is the only reference to "a_position" I can find in my project. I doubt it can be hidden anywhere else so that my search wouldn't find it.

Anyways, seems like the warning disappears when I remove the flag -s LEGACY_GL_EMULATION=1. I don't think I will need this flag so this issue isn't blocking me for now. I'll report back if I can find something else about this issue.

キャロウ マーク

unread,
Aug 16, 2016, 12:06:29 PM8/16/16
to emscripte...@googlegroups.com

On Aug 16, 2016, at 12:20 AM, LJA <jahv...@gmail.com> wrote:

Anyways, seems like the warning disappears when I remove the flag -s LEGACY_GL_EMULATION=1. I don't think I will need this flag so this issue isn't blocking me for now. I'll report back if I can find something else about this issue.


Then it is most likely an issue in Emscripten's emulation layer. Are you using client-side attribute arrays in your app? This is one reason for using the emulation layer and emulation of this requires a copy into a buffer object and setting up a VertexAttribPointer to that buffer object, an obvious place for such a problem to arise.

Jukka Jylänki

unread,
Aug 16, 2016, 1:18:35 PM8/16/16
to emscripte...@googlegroups.com
As part of its validation and shader transform pipeline, ANGLE replaces all variables in shaders with hashes versions of their names to ensure that it can compile the shaders on different GLSL compilers that might have differring reserved names from WebGL GLSL ES or different max variable length limitations compared to WebGL. These hashed names have the form "webgl_longhexstring".

Seeing an error of a missing shader variable name coming from after this hashing has been done is a clear browser bug - those hashed names should never be seen in the browser side, so you can report the issue up to Safari. At minimum if the shader being compiled indeed is problematic, the browser should be reporting the missing shader variables in their original unhashed forms. Safari might have a bug in shader compilation, or it might just have a bug in printing out a bad warning (after an initial problem first occurring elsewhere).

WebGL offers the https://www.khronos.org/registry/webgl/extensions/WEBGL_debug_shaders/ extension which allows you to peek at the internal transformed shaders. If you are interested, you could try checking it out with that to see what kind of shaders it spewed. In any case, if the page works correctly in Firefox and Edge and Chrome, it is very likely that the root cause is on Safari's end.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages