Xenia: gpu-gl4: glDrawArraysInstancedBaseInstance generates GL_INVALID_OPERATION on AMD GPUs

[sephiroth99]

Problem
When OpenGL debug logging is enabled, the following error is logged in pretty much any game:

!> 1390 GL4 OpenGL: error(high) 1000: glDrawArraysInstancedBaseInstance has generated an error (GL_INVALID_OPERATION)

Possible cause
It seems that the error occurs when the bound program pipeline has a Geometry Shader associated. For example, by removing the GS stage from the pipelines in CommandProcessor::UpdateShaders, the error is not generated anymore (but, of course, what is displayed on screen is not correct/is garbage).

Further analysis
_Error conditions_
According to the OpenGL wiki/manual, there are two cases when it can occur:

1. GL_INVALID_OPERATION is generated if a geometry shader is active and mode​ is incompatible with the input primitive type of the geometry shader in the currently installed program object.
   _I verified what mode is configured when glDraw... is called and it is correct, so that is not it._
2. GL_INVALID_OPERATION is generated if a non-zero buffer object name is bound to an enabled array and the buffer object's data store is currently mapped.
   _I don't know enough OpenGL to say if that happens or not._
3. I'm sure there are more undocumented cases...

_OpenGL debugger_
I also ran xenia under AMD CodeXL, and it detected the error before calling the function, but it did not give any more specific info on why it could happen

For reference, here is what it says:

OpenGL Error: glDrawArrays - GL_INVALID_OPERATION
Break
Reason
OpenGL Error
Break on
glDrawArrays(GL_TRIANGLES , 0 , 3)
Error Code
GL_INVALID_OPERATION
Error Description
The specified operation is not allowed in the current state. The offending function is ignored, having no side effect other than to set the error flag.
* Stopped before function execution

If it helps, I can also provide a function call history until the error (about 66 calls).

_Equivalent function_
As per the wiki, glDrawArraysInstancedBaseInstance behaves the same as glDrawArrays​. I replaced the call with the following:

        assert(cmd->instance_count == 1);
        assert_zero(cmd->base_instance);
        glDrawArrays(prim_type, cmd->first_index, cmd->count);

The error logged by the driver has one additional line:

!> 1CAC GL4 OpenGL: error(high) 1000: glDrawArrays has generated an error (GL_INVALID_OPERATION)
!> 1CAC GL4 OpenGL: error(high) 2003: glDrawArrays failed because the currently active shader combination is invalid (GL_INVALID_OPERATION)

TLDR
There is an OpenGL error and I have no real clue why it happens, so if you know OpenGL, please chime in!

[qeeg]

I applaud this issue report for being very informative and specific! Well
done!

On Thu, Sep 3, 2015 at 12:29 AM, sephiroth99 [email protected]
wrote:

_Problem_
When OpenGL debug logging is enabled, the following error is logged in
pretty much any game:

!> 1390 GL4 OpenGL: error(high) 1000: glDrawArraysInstancedBaseInstance
has generated an error (GL_INVALID_OPERATION)

_Possible cause_
It seems that the error occurs when the bound program pipeline has a
Geometry Shader associated. For example, by removing the GS stage from the
pipelines in CommandProcessor::UpdateShaders, the error is not generated
anymore (but, of course, what is displayed on screen is not correct/is
garbage).

_Further analysis_
_Error conditions_
According to the OpenGL wiki/manual
https://www.opengl.org/wiki/GLAPI/glDrawArraysInstancedBaseInstance,
there are two cases when it can occur:

1. GL_INVALID_OPERATION is generated if a geometry shader is active and
   mode​ is incompatible with the input primitive type of the geometry shader
   in the currently installed program object.
   _I verified what mode is configured when glDraw... is called and it is
   correct, so that is not it._
2. GL_INVALID_OPERATION is generated if a non-zero buffer object name is
   bound to an enabled array and the buffer object's data store is currently
   mapped.
   _I don't know enough OpenGL to say if that happens or not._
3. I'm sure there are more undocumented cases...

_OpenGL debugger_
I also ran xenia under AMD CodeXL, and it detected the error before
calling the function, but it did not give any more specific info on why it
could happen

For reference, here is what it says:

OpenGL Error: glDrawArrays - GL_INVALID_OPERATION
Break
Reason
OpenGL Error
Break on
glDrawArrays(GL_TRIANGLES , 0 , 3)
Error Code
GL_INVALID_OPERATION
Error Description
The specified operation is not allowed in the current state. The offending function is ignored, having no side effect other than to set the error flag.

• Stopped before function execution

If it helps, I can also provide a function call history until the error
(about 66 calls).

_Equivalent function_
As per the wiki, glDrawArraysInstancedBaseInstance behaves the same as
glDrawArrays​. I replaced the call
https://github.com/benvanik/xenia/blob/master/src/xenia/gpu/gl4/draw_batcher.cc#L321
with the following:

    assert(cmd->instance_count == 1);
    assert_zero(cmd->base_instance);
    glDrawArrays(prim_type, cmd->first_index, cmd->count);

The error logged by the driver has one additional line:

!> 1CAC GL4 OpenGL: error(high) 1000: glDrawArrays has generated an error (GL_INVALID_OPERATION)
!> 1CAC GL4 OpenGL: error(high) 2003: glDrawArrays failed because the currently active shader combination is invalid (GL_INVALID_OPERATION)

In the end, I have no real clue why it happens, so if you know OpenGL,
please chime in!

—
Reply to this email directly or view it on GitHub
https://github.com/benvanik/xenia/issues/416.

[sephiroth99]

Quick update, still happens with Catalyst Beta 15.11.1. Let's hope Catalyst Crimson will fix things!

Does any one else with an AMD GPU see this error? It should appear in the logs with the following flags:

--debug=true
--gl_debug=true
--gl_debug_output=true

Also, as a reference, my setup is Windows 10 and a Radeon HD7950.

[sephiroth99]

Updated with Radeon Software 15.11 "Crimson", still happens.

GLSL version still reported in Xenia log as 4.40.

i> 00001A84 Successfully created OpenGL context:
i> 00001A84   GL_VENDOR: ATI Technologies Inc.
i> 00001A84   GL_VERSION: 4.5.13416 Compatibility Profile/Debug Context 15.300.1025.0
i> 00001A84   GL_RENDERER: AMD Radeon HD 7900 Series
i> 00001A84   GL_SHADING_LANGUAGE_VERSION: 4.40
w> 00001A84 GLSL version reported as 4.40; you may have a bad time!

[DrChat]

Any shader compilation errors reported in the log? Search for "Unable to link program:".

[sephiroth99]

@DrChat Nope, no shader compilation errors.

My current guess is that the interface between the VS and GS and/or GS and FS is invalid. Because Xenia uses program pipelines, the interface matching can't be checked at link time, it is checked at runtime. (see: https://www.opengl.org/wiki/Shader_Compilation#Validation). The _glDrawArrays​_ error message does reference an "invalid shader combination".

But then, I remembered that the reported GLSL level is 4.40. So until AMD supports 4.50, I guess we can only wait.

[sephiroth99]

A new version of CodeXL (1.9) released recently, and now it can compile GLSL code, so I had a go at it.

It compiles all four geom shaders without errors. I threw a bunch of vert and frag shaders dumped from running some games, and while it compiled the vert shaders, it failed on all frag shaders with the following error:

Link Shader failed: Fragment shader(s) failed to link.
Fragment link error: INVALID_OPERATION.
ERROR: error(#380) Too many inputs are used in: fragment shader

Going to investigate this further.

Also, updated to Crimson 15.12 WHQL, no change on GLSL feature level (still 4.40).

[sephiroth99]

Crimson 16.3 finally brings GLSL 4.50. The error has disappeared. Still nothing is shown on screen but there are no errors anymore!

Edit: Yeah I think they simply silenced the error. The same behaviour as before happens. Black screen always, but if you remove the geometry shaders from the program pipelines, you see something, same as before... oh well

[DrChat]

GL is deprecated! Yay!