Can you bisect?

Probably this is a known bug with GL_EXT_TEXTURE_ARRAY in Unigine engines and glsl < 1.30. IIRR they are using the extension without enabling it in the shaders.

Disabling the extension completely with the environment variable should help:

MESA_EXTENSION_OVERRIDE=-GL_EXT_texture_array

(In reply to comment #2)
> Probably this is a known bug with GL_EXT_TEXTURE_ARRAY in Unigine engines and
> glsl < 1.30. IIRR they are using the extension without enabling it in the
> shaders.
> 
> Disabling the extension completely with the environment variable should help:
> 
> MESA_EXTENSION_OVERRIDE=-GL_EXT_texture_array

Yes, disabling that extension fixes the problem. Is it so rare that an opengl implementation supports GL_EXT_TEXTURE_ARRAY but not glsl 1.30? The extension spec is written against glsl 1.10.

BTW, how far is r600g from supporting glsl 1.30? AFAIK the intel driver already advertises glsl 1.30 support.

same result with Intel GMA 4500 with Mesa 8-series and Mesa 8.1-devel from git

This still happens on nouveau, despite OpenGL 3.0 advertised.

This is a bug in Unigine's engine.  It's supposed to request that functionality by one of these options:

1. Specifying #version 130 (it doesn't, so it gets 110, which is mandatory spec behavior)
2. Specifying #extension GL_EXT_texture_array : require

Since it does neither of those, we don't offer the functionality.  Which is correct behavior, and not a problem with any other applications.

That said, we did put in a workaround for their apps (our first ever).  You simply need to install a drirc.  This should happen on 'make install', but you can also copy src/mesa/drivers/dri/common/drirc to either /etc/drirc or ~/.drirc.  That automatically detects Unigine binary names and applies the two necessary workarounds:

1. force_glsl_extensions_warn - let them use extensions without asking, but warn on use
2. disable_blend_func_extended - disable the ARB_blend_func_extended extension, which at least Heaven completely misuses in a way that can't possibly work.

You can also set those two items as environment variables if you prefer that to installing a drirc.  The drirc just makes it automatic.

The point is that I do have a drirc.

I also did this before running the demo:

export force_glsl_extensions_warn=true
export disable_blend_func_extended=true

And yet, I am getting this:

GLShader::loadFragment(): error in "core/shaders/meshes/fragment_base_light_omni.shader" file
defines: UNKNOWN,QUALITY_LOW,QUALITY_MEDIUM,QUALITY_HIGH,MULTISAMPLE_0,USE_INSTANCING,USE_TEXTURE_ARRAY,USE_DEFERRED,USE_OCCLUSION,USE_REFLECTION,OPENGL,USE_PSEUDO_INSTANCING,USE_PSEUDO_TRANSFORM,USE_ARB_BLEND_FUNC_EXTENDED,BASE_LIGHT_OMNI,OMNI,SHADOW,PHONG_RIM
0:460(18): error: syntax error, unexpected NEW_IDENTIFIER
GLShader::loadFragment(): error in "core/shaders/meshes/fragment_base_light_omni.shader" file
defines: UNKNOWN,QUALITY_LOW,QUALITY_MEDIUM,QUALITY_HIGH,MULTISAMPLE_0,USE_INSTANCING,USE_TEXTURE_ARRAY,USE_DEFERRED,USE_OCCLUSION,USE_REFLECTION,OPENGL,USE_PSEUDO_INSTANCING,USE_PSEUDO_TRANSFORM,USE_ARB_BLEND_FUNC_EXTENDED,BASE_LIGHT_OMNI,OMNI,SHADOW,PHONG_RIM,MESH_SKINNED
0:460(18): error: syntax error, unexpected NEW_IDENTIFIER
....

So, a quick glance at gallium code reveals that this workaround is not wired up in Gallum.

And disable_blend_func_extended doesn't exist in recent mesa at all.

I understand that it's not Mesa3D's fault, but r600g doesn't seem to adhere to those drirc settings (yes, I changed the name of the driver to r600 in .drirc).

If I run Tropics as
ESA_EXTENSION_OVERRIDE=-GL_ARB_draw_instanced ./1024x768_windowed.sh
it renders normally at daylight, but the night scenes are totally wrong. It prints lots of these:
GLShader::loadFragment(): error in "core/shaders/grass/fragment_base_light_omni.shader" file
defines: UNKNOWN,QUALITY_LOW,QUALITY_MEDIUM,QUALITY_HIGH,MULTISAMPLE_0,USE_INSTANCING,USE_TEXTURE_ARRAY,USE_DEFERRED,USE_OCCLUSION,USE_REFLECTION,OPENGL,USE_PSEUDO_INSTANCING,USE_PSEUDO_TRANSFORM,USE_ARB_BLEND_FUNC_EXTENDED,BASE_LIGHT_OMNI,OMNI,SHADOW,NOISE
0:460(18): error: syntax error, unexpected NEW_IDENTIFIER

If I run without that override, only the textures at the root ot the trees are shown, and it prints lots of these:
GLShader::loadVertex(): error in "core/shaders/meshes/vertex_base.shader" file
defines: UNKNOWN,QUALITY_LOW,QUALITY_MEDIUM,QUALITY_HIGH,MULTISAMPLE_0,USE_INSTANCING,USE_TEXTURE_ARRAY,USE_DEFERRED,USE_OCCLUSION,USE_REFLECTION,OPENGL,USE_PSEUDO_INSTANCING,USE_PSEUDO_TRANSFORM,USE_ARB_BLEND_FUNC_EXTENDED,HAS_ARB_DRAW_INSTANCED,BASE_DEFERRED,ALPHA,MESH_SKINNED
0:171(53): error: `gl_InstanceID' undeclared
0:171(76): error: Operands to arithmetic operators must be numeric
0:171(76): error: Operands to arithmetic operators must be numeric
0:199(39): error: `gl_InstanceID' undeclared
0:199(42): error: Operands to arithmetic operators must be numeric
0:199(19): error: cannot construct `ivec3' from a non-numeric data type
0:199(58): error: Operands to arithmetic operators must be numeric

I'm not an expert on driver development, but IMHO this has to be fixed somehow. Either persuade unigine devs to fix their code, or implement a proper workaround.

Yep, because Gallium ignores this setting as I said.
It very easy to fix, so I'll send a patch in a hour

Created attachment 65577 [details] [review]
quick fix

This patch adds support for this via environment variable, like this:
export force_glsl_extensions_warn=true

Doing same via driconf would involve interface changes because of abstraction.

Support for drirc configs and 'force_glsl_extensions_warn' option for gallium drivers added by commits:

6547733593f137e5e6e024a6084d4c04ca2abc34
..
68d6441930fa19e2414a4c273ddce15e0c71de99

So I think this bug may be closed.