Created attachment 123034[details]
Shader
The attached shader is used by the Elemental Demo, extracted with apitrace. It gets the following compilation error:
0:9(31): error: struct 'TEXCOORD0' previously defined
After some discussion on #dri-devel, we think this is invalid GLSL.
However, given the large number of games using the engine we might still want to support it. (TODO: is it really the engine or just multiple demos?)
I think adding a drirc quick is going to be infeasible given that the engine seems to be used by many games.

glslang produces
Warning, version 430 is not yet complete; most version-specific features are present, but some are missing.
ERROR: 0:9: '' : syntax error
ERROR: 1 compilation errors. No code generated.
for me. (No flags, just glslangValidator elemental.geom)
No very informative, but it seems to refer to line 9, which was also the location of the mesa error.

Hmm... I think the shader may be correct. Section 4.1.8 (Structures) of the GLSL 1.40 and later specs say (emphasis mine):
"...where name becomes the user-defined type, and can be used to declare
variables to be of this new type. The name shares the same name space as
other variables, types, and functions. *All previously visible variables,
types, constructors, or functions with that name are hidden.*"
Based on this, the second TEXCOORD0 should "shadow" the first.
It's worth noting that the GLSL 1.30 spec says:
"...where name becomes the user-defined type, and can be used to declare
variables to be of this new type. The name shares the same name space as
other variables, types, and functions, with the same scoping rules."
I have no recollection why this change was made. I could find nothing in the 1.40 spec to explain the change. I believe Mesa implements the GLSL 1.30 rule in all GLSL versions.
Curiously, all versions of GLSL ES contain the GLSL 1.40 language.

That created confusion on IRC too. I think that it isn't allowed based on
"All variable names, structure type names, and function names in a given scope share the same name space. Function names can be redeclared in the same scope, with the same or different parameters, without error. An implicitly sized array can be re-declared in the same scope as an array of the same base type. Otherwise, within one compilation unit, a declared name cannot be redeclared in the same scope; doing so results in a redeclaration compile-time error."
(4.2 Scoping, GLSL 4.30 spec)
So I'm not entirely sure if you quoted patch conflicts with this, or that it should be interpreted as hiding things on declaration, but not specifiying when the declaration is allowed.

Just FYI: the patch from comment 1 helps for the (very) old unreal demos that can be downloaded from the unreal wiki, but the current unreal engine has a similar (something with TEXCOORD0 again), but different problem.
For demos with the current engine I only know of the unreal tournament alpha that can be downloaded free of cost from here after registering at the forums:
https://www.epicgames.com/unrealtournament/forums/showthread.php?12011-Unreal-Tournament-Pre-Alpha-Playable-Build
Here is an apitrace, 78 megabytes:
http://haagch.frickel.club/files/UE4-Linux-Shipping.trace
apitrace replay shows this error message:
32283 @2 glLinkProgram(program = 3071)
32283: warning: link failed
32283: warning: error: vertex shader output `out_TEXCOORD0' declared as type `#anon_struct_0001', but geometry shader input declared as type `#anon_struct_0003[3]'
error: vertex shader output `out_TEXCOORD1' declared as type `#anon_struct_0002', but geometry shader input declared as type `#anon_struct_0004[3]'
32284: message: major api error 3: GL_INVALID_OPERATION in glUseProgram(program 3071 not linked)
32284 @2 glUseProgram(program = 3071)

The fix for this bug (pushed on master) regresses a piglit test:
piglit.spec.glsl-1_50.compiler.interface-blocks-name-reused-globally-4.vert
Is the test wrong, or is there a real regression here? No dEQP or CTS tests were affected.

(In reply to Shawn Starr from comment #12)
> neither patch fixes UE4 4.5.1 based games, get a dialog box (with nothing
> inside it) and crashes sadly.
Which patches are you refering to? You need the three of them for your test. If you are using latest mesa code, all three patches (1 from Mark and 2 from Ian) are included.

Since both patches were pushed (and the piglit test fixed) and since nouveau driver is now enabling OpenGL 4.3 by default (for nvc0), what's preventing us from exposing OpenGL 4.3 for radeonsi also? Both drivers are concerned by the pushed patches, isn't it?
Was somebody able to test against a UE4 4.5.1 based game with the latest git code since Shawn's comment?

Running this on Skylake doesn't seem to render anything for me, I just see what was behind the window previously - the music plays.
On Tonga the demo loads but it seems some of the textures aren't working properly, it's really noticeable on the running lava which looks like grey squares glued together

(In reply to Mike Lothian from comment #17)
> Running this on Skylake doesn't seem to render anything for me, I just see
> what was behind the window previously - the music plays.
Odd. It used to work earlier on, but now I get one frame of rendering (same as when nouveau was avoiding writing to images with the wrong number of components declared), and then black and then it dies with
intel_batchbuffer.c:421: _intel_batchbuffer_flush: Assertion `!brw->no_batch_wrap' failed.
I think this might need jljusten's series among other things, not sure.
>
> On Tonga the demo loads but it seems some of the textures aren't working
> properly, it's really noticeable on the running lava which looks like grey
> squares glued together
The grayish lava instead of orange/red is something I saw on nouveau as well.

(In reply to Ilia Mirkin from comment #19)
> The grayish lava instead of orange/red is something I saw on nouveau as well.
Could be a UE4 bug (could be one of the reasons why UE4 doesn't seem to use the 4.3 path with the proprietary drivers).
Anyway, the bug this report is about is clearly fixed, any remaining issues should be tracked separately.