Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

glDrawElements fails with GL_INVALID_OPERATION on Intel Corporation Iris Plus Graphics G7 (laptop GPU) #132

Closed
j0zzz opened this issue Sep 4, 2023 · 2 comments · Fixed by #134
Labels
bug Something isn't working

Comments

@j0zzz
Copy link
Owner

j0zzz commented Sep 4, 2023

Issue occurs when the alias model drawing shaders are executed. The shader compiler does not show any errors.

JoeQuake uses a texture buffer object (TBO) to upload a 64K byte array to GLSL. This array contains precomputed lighting information, which is sufficient for vertex lighting. In the vertex shader, an item from this array is obtained with the texelFetch() method call. If I remove this call, the GL_INVALID_OPERATION error is not returned any more and the alias models are drawn - obviously with incorrect lighting.

Is there any way to query if the GPU is capable to serve the texelFetch() call? Or what else can I try?
The only additional OpenGL method required for TBOs is glTexBuffer, but its availability is checked at startup and is usually found in the opengl32.dll, so that doesn't help.

I had this issue for more than 2 years when I was trying to fix this for many weeks until I ended up using shader storage buffer object (SSBO) instead, but the problem with that solution is that it required GLSL version 4.3 which turned out to be a major performance death sentence if you combine with regular OpenGL calls to due querying and feeding the ModelView and Projection matrices before every shader execution.

@sezero, @ericw, @andrei-drexler you guys have any tips, ideas?

@j0zzz j0zzz added the bug Something isn't working label Sep 4, 2023
@matthewearl
Copy link
Contributor

matthewearl commented Sep 5, 2023

Edit: ignore the below, the shader wasn't compiling due to layout(binding=0) not being compatible with the specified opengl version, so it switched to the non-GLSL render path.


Hello, this is affecting my graphics card which is the same model as in the issue title. The following diff appears to fix it:

diff --git a/trunk/gl_rmain.c b/trunk/gl_rmain.c
index a3c74f4..f458a12 100644
--- a/trunk/gl_rmain.c
+++ b/trunk/gl_rmain.c
@@ -729,7 +729,7 @@ void GLAlias_CreateShaders(void)
                "       int AnormPitch[NUMVERTEXNORMALS];\n"
                "       int AnormYaw[NUMVERTEXNORMALS];\n"
                "};\n"
-               "uniform usamplerBuffer VlightTable;\n"
+               "layout(binding=0) uniform usamplerBuffer VlightTable;\n"
                "attribute vec4 TexCoords; // only xy are used \n"
                "attribute vec4 Pose1Vert;\n"
                "attribute vec3 Pose1Normal;\n"

I have no idea if this is the right fix or not. Note I'm running on Linux with this branch: https://github.com/matthewearl/joequake-1/tree/sdl-linux

@Flecked42
Copy link

Flecked42 commented Sep 7, 2023

I put in that change and GLSL is enabled for me, no errors.

I have an AMD GPU though.

matthewearl added a commit to matthewearl/JoeQuake-1 that referenced this issue Sep 17, 2023
This was apparently causing j0zzz#132 --- with this change vertex lighting in
the GLSL path works fine for me on my Iris Plus Graphics G7.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants