I'm using attributeless rendering in a portion of my application. This spawns a error in logcat about it.
I/Adreno-ES20(26777): <validate_vertex_attrib_state:55>: validate_vertex_attrib_state: No vertex attrib is enabled in a draw call!
I'm developing using the development drivers on my Nexus 5.
Figured I would let you know that attributeless rendering is being used and one should expect it to happen.
Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries (“Qualcomm”). The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.
Seems this delves deeper than I thought.
I thought the drivers were just throwing a warning, not straight out dying due to this.
I created a test case to test this since I couldn't test the driver to be doing the correct thing.
The test case should create a red gradient on a 1280x720 resolution display. Should still show something on any other resolution.
This isn't near as complicated as my application does it, but it is simple enough to show wtf is happening.
https://drive.google.com/file/d/0B2mTNE31f5JTRTBHRUl6QUxFYVU/edit?usp=sh...
Woop, different link to the example source
https://drive.google.com/file/d/0B2mTNE31f5JTS2pra2dxZVE0UTg/edit?usp=sh...
In my blind rage I couldn't even upload the correct source.
This is finally it.
https://drive.google.com/file/d/0B2mTNE31f5JTa3hqSi1qNmdUcFE/edit?usp=sh...
1) What exactly is the error you are seeing?
2) Why can you test the driver to be doing the correct thing?
3) Which device and driver are you running on? (you can get the driver information by searching the logcat for "adreno")
4) Looking at the source, you have both gl3 an gl2 versions. Are you getting errors with both version?
5) Thanks for providing the source code, but could you provide apks for us to test with?
thanks...
The error is that the application output is black.
This works on all other devices(Mali-Txx, Tegra K1, Intel HD, desktop Nvidia)
I'm testing it on the Nexus 5 with the latest April 17th development drivers.
It's only a GLES30 version, must be mistaken thinking there is a gles2 one.
Here is an apk https://drive.google.com/file/d/0B2mTNE31f5JTaTFuV0tRc1IzUDA/edit?usp=sh...
Thanks for providing the apk. With the latest drivers on newer development hardware I'm seeing a black to red gradiant, going left to right, however I'm also able to duplicate the black screen on similar hardware to the Nexus 5.
1) Could you verifiy the Adreno strings that shows up in logcat on your Nexus 5? Will like to see the driver version number that's displayed.
2) Could you enable network access in the apk, so that we can profile the app.with our tools?
Strings:
Thanks, looks like a current driver build...
Noticing that the app doesn't see to have any obvious frame delimiters (e.g. no call to glClear, glFinish, glFlush, eglSwapBuffers). Are you able to add one?
Here's an APK that adds a glFinish at the end of the frame.
https://drive.google.com/file/d/0B2mTNE31f5JTR2dYdGdMNS1zMjA/edit?usp=sh...
I think I found the issue with this is that gl_VertexID doesn't contain real values, but it is exceedingly hard to test on my end.
gl_VertexID is suppose to be an integer value, but I'm not seeing it used in your shaders. Could you explain more?
What. I'm using it in Square.java within my vertex shader to determine what location to give gl_Position.
I'm not seeing a Square.java in the source drop you sent last week. The only Java code is GLES3JNIActivity.java, GLESJNILib.java, GLESJNIView.java
Also could you please provide more details about this comment: "I think I found the issue with this is that gl_VertexID doesn't contain real values"? Is this problem solved, or is there more investigation needed.
thanks
I think you've got the wrong source drop somewhere along the way. If you look at this output from tree in the directory http://hastebin.com/ayajolekaw.avrasm
The only java files I have are:
Is this suppose to be a gl2 or gl3 program?
I'm seeing import android.opengl.GLES20;
but also #version 300 es in the shaders.
Also our driver team has mentioned that the No vertex attrib message that shows up in the log, comes from gl2.
It's a OpenGL ES 3.0 application, it should be creating a OpenGL ES 3.0 context(not like it matters since the drivers auto promote to a GLES 3.0 context). It's using GLSL ES 3.0 shaders.
Changing over from using the GLES20 java functions to the GLES30 java functions don't cause a change in behavior.
Got some feedback from our compiler team who are questioning the mixing of GLES2.0..
I may be wrong, but GLES20.glLinkProgram will probably invoke the ES 2.0 linker, not the ES 3.0 linker. The shaders, however, are version 300. This is not ok.
I know that the linker will refuse to link if one shader is version 100 and the other is version 300, but I’m not sure whether the 2.0 linker will fail if it sees version 300 shaders.
The linker should notice this discrepancy and refuse to link, but I’m not sure about what it actually does. One of these things may be happening:
- The ES2.0 linker silently ignores the fact that these are ES3.0 shaders, but completes without an error, in which case the output most certainly will be damaged.
- The ES2.0 linker silently ignores the fact that these are ES3.0 shaders, but linking fails because of some ES3.0 functionality that the ES 2.0 linker cannot handle.
- The linker notices that it’s handling ES3.0 shaders and refuses to link.
If an error is not issued, the user program will probably be running on a defective GPU shader. If an error is issued, the user app is ignoring it, and chances are it’s not running on the shader that the user intended. Either way, the InfoLog will tell whether the linking completely successfully or not, and if the wind blows in the right direction, there will be messages in there telling the reasons of the failure. Also, if a very recent version of the parser/linker is being used, failures to compile or to link will be jotted down in the logcat.
I would do several things here,
- Use GLES30 instead of GLES20 everywhere.
- Check for GL errors from the compile and link calls.
- Fetch the InfoLog by calling glGetShaderInfoLog and display it if a GL error is detected.
After some more discussion, our driver team will be taking a closer look at the problem. Will probably take a few days to analyze
Our driver team wa able to track down the bug and summit a change for it. It did involve having no attribute data in the shader. We're not able to predict when the fix will make it's way into builds for commercial devices.
I know there's been some performance improvements with these functions, but not aware of an issue with it stalling the driver. Can you point me to an existing thread in this forum, or feel free to start a new one?
thanks...
I think this issue is related to my issue :
https://developer.qualcomm.com/forum/qdn-forums/maximize-hardware/mobile...
Initially I thought it's because I bind a buffer that's not large enough for a supposed draw call of 1014 vertices but the truth is, it crashes when fetching the link log or prior.