Bug 92278

Summary:	Black screen in War Thunder
Product:	Mesa	Reporter:	Sven Arvidsson <sa>
Component:	Mesa core	Assignee:	mesa-dev
Status:	RESOLVED WORKSFORME	QA Contact:	mesa-dev
Severity:	normal
Priority:	medium	CC:	kai.huuhko, lemody
Version:	11.0
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	Apitrace warnings hack that fixes issue hack that fixes issue

Description Sven Arvidsson 2015-10-04 19:04:03 UTC

Created attachment 118658 [details]
Apitrace warnings

The game "War Thunder" doesn't seem to be working with Mesa.

I get a green screen instead of what I'm guessing is an intro video, and a black screen in the menu. Happens on i965 and with software rendering, reported to be the same on radeon.

Same behavior on 10.6.7 and 11.0.2. 

The game is free to play:
https://warthunder.com/


I created an apitrace, that results in a lot of logged warnings:

469: message: api issue 1: FBO incomplete: no attachments and default width or height is 0 [-1]
469: message: shader compiler issue 2: FS SIMD8 shader: 5 inst, 0 loops, 0:0 spills:fills, Promoted 0 constants, compacted 80 to 48 bytes.
469: message: shader compiler issue 3: FS SIMD16 shader: 5 inst, 0 loops, 0:0 spills:fills, Promoted 0 constants, compacted 80 to 48 bytes.
483: message: shader compiler issue 4: FS SIMD16 shader: 2 inst, 0 loops, 0:0 spills:fills, Promoted 0 constants, compacted 32 to 32 bytes.
483: message: shader compiler issue 5: VS vec4 shader: 6 inst, 0 loops, compacted 96 to 96 bytes.
509: message: shader compiler issue 6: FS SIMD8 shader: 5 inst, 0 loops, 0:0 spills:fills, Promoted 0 constants, compacted 80 to 48 bytes.
509: message: shader compiler issue 7: FS SIMD16 shader: 5 inst, 0 loops, 0:0 spills:fills, Promoted 0 constants, compacted 80 to 48 bytes.
561: message: api performance issue 8: Falling back to plain clear because 16x16 buffer is untiled
561: message: shader compiler issue 9: FS SIMD8 shader: 5 inst, 0 loops, 0:0 spills:fills, Promoted 0 constants, compacted 80 to 48 bytes.
561: message: shader compiler issue 10: FS SIMD16 shader: 5 inst, 0 loops, 0:0 spills:fills, Promoted 0 constants, compacted 80 to 48 bytes.
561: message: shader compiler issue 11: VS vec4 shader: 6 inst, 0 loops, compacted 96 to 96 bytes.
561: message: shader compiler issue 12: FS SIMD8 shader: 5 inst, 0 loops, 0:0 spills:fills, Promoted 0 constants, compacted 80 to 48 bytes.
561: message: shader compiler issue 13: FS SIMD16 shader: 5 inst, 0 loops, 0:0 spills:fills, Promoted 0 constants, compacted 80 to 48 bytes.
561: message: shader compiler issue 14: VS vec4 shader: 6 inst, 0 loops, compacted 96 to 96 bytes.
743: message: api performance issue 8: Falling back to plain clear because 16x16 buffer is untiled

Full log is attached.

Comment 1 Sven Arvidsson 2015-10-04 19:04:32 UTC

Trace: https://www.dropbox.com/s/7zvvfe25ye46jrl/aces.trace?dl=0

Comment 2 Tapani Pälli 2015-10-16 06:13:02 UTC

On quick glance at the trace it looks like one issue here is that Mesa does not expose EXT variants for TextureParameteri and TextureParameterfv but exposing those won't fix this as there are other major issues.

Comment 3 Tapani Pälli 2015-10-26 06:46:42 UTC

Created attachment 119191 [details] [review]
hack that fixes issue

OK, looks like exposing EXT_direct_state_access would be enough after all, with attached patch game works and renders just fine (tested on HSW desktop). I'm not sure if there is enough interest to expose EXT variants, instead someone could pursue game vendor to use the ARB functions?

Comment 4 Tapani Pälli 2015-10-26 13:10:43 UTC

Created attachment 119200 [details] [review]
hack that fixes issue

This is slightly cleaner but still just a hack, it looks like we would need full GL_EXT_direct_state_access and also GL_EXT_depth_bounds_test extension.

Comment 5 Sven Arvidsson 2015-10-26 21:20:54 UTC

The patch works fine here, awesome work! Fantastic to have it fixed so quickly!

The developer of the game is Gaijin Entertainment, http://gaijinent.com

I could probably open a support ticket with them, but chances are they're not interested. The FAQ for Linux only mentions "install proprietary drivers" which is quite hard to do on Intel.

Comment 6 Ian Romanick 2015-10-28 00:23:39 UTC

(In reply to Sven Arvidsson from comment #5)
> The patch works fine here, awesome work! Fantastic to have it fixed so
> quickly!
> 
> The developer of the game is Gaijin Entertainment, http://gaijinent.com
> 
> I could probably open a support ticket with them, but chances are they're
> not interested. The FAQ for Linux only mentions "install proprietary
> drivers" which is quite hard to do on Intel.

I will attempt to make contact with the developer.

Comment 7 Ian Romanick 2015-10-28 00:32:33 UTC

(In reply to Tapani Pälli from comment #4)
> Created attachment 119200 [details] [review] [review]
> hack that fixes issue
> 
> This is slightly cleaner but still just a hack, it looks like we would need
> full GL_EXT_direct_state_access and also GL_EXT_depth_bounds_test extension.

Why do you think GL_EXT_depth_bounds_test is necessary?

Either way... we're absolutely not going to do EXT_dsa.  We have ARB_dsa in core profile, and that's what applications should use.  Spending a bunch of time to implement the backward-looking extension, at the expense of other features, when we already support the forward-looking functionality doesn't help anyone in the long run.

Comment 8 Tapani Pälli 2015-10-28 04:57:56 UTC

(In reply to Ian Romanick from comment #7)
> (In reply to Tapani Pälli from comment #4)
> > Created attachment 119200 [details] [review] [review] [review]
> > hack that fixes issue
> > 
> > This is slightly cleaner but still just a hack, it looks like we would need
> > full GL_EXT_direct_state_access and also GL_EXT_depth_bounds_test extension.
> 
> Why do you think GL_EXT_depth_bounds_test is necessary?

There's calls to glEnable and glDisable with DEPTH_BOUNDS_TEST_EXT, not sure if it is really needed as I haven't spotted any graphical glitches during those scenes.
 
> Either way... we're absolutely not going to do EXT_dsa.  We have ARB_dsa in
> core profile, and that's what applications should use.  Spending a bunch of
> time to implement the backward-looking extension, at the expense of other
> features, when we already support the forward-looking functionality doesn't
> help anyone in the long run.

Yep I agree.

Comment 9 kominato 2015-11-09 10:45:08 UTC

(In reply to Sven Arvidsson from comment #5)
> The patch works fine here, awesome work! Fantastic to have it fixed so
> quickly!
> 
> The developer of the game is Gaijin Entertainment, http://gaijinent.com
> 
> I could probably open a support ticket with them, but chances are they're
> not interested. The FAQ for Linux only mentions "install proprietary
> drivers" which is quite hard to do on Intel.

hi,
same problem here, for intel 6000. Green screen after war thunder launcher.
how do you apply the patch ?

Comment 10 kominato 2015-11-09 11:19:41 UTC

worked with
MESA_GL_VERSION_OVERRIDE=4.1COMPAT ~/.steam/steam/steamapps/common/War\ Thunder/launcher

Comment 11 Tapani Pälli 2015-11-10 08:06:50 UTC

(In reply to kominato from comment #10)
> worked with
> MESA_GL_VERSION_OVERRIDE=4.1COMPAT ~/.steam/steam/steamapps/common/War\
> Thunder/launcher

Sweet, I've confirmed this works fine. Now we can just forget about the patch. I'll resolve this bug as WORKSFORME and real fix in the future will happen when we reach OpenGL 4.1 support. Until then, a context version override is required.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.