Bug 96449 - Dying Light reports OpenGL version 3.0 with mesa-git
Summary: Dying Light reports OpenGL version 3.0 with mesa-git
Status: RESOLVED WONTFIX
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: All Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-09 09:42 UTC by Jan Ziak
Modified: 2017-05-21 05:50 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
DyingLight-OpenGL-version (7.85 KB, image/png)
2016-06-09 09:43 UTC, Jan Ziak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Ziak 2016-06-09 09:42:15 UTC
$ glxinfo | grep git
OpenGL core profile version string: 4.3 ... Mesa 12.1.0-devel (git-26b69ad)
OpenGL version string: 3.0 Mesa 12.1.0-devel (git-26b69ad)

The attached screenshot shows the first window that appears after starting Dying Light from Steam.
Comment 1 Jan Ziak 2016-06-09 09:43:05 UTC
Created attachment 124411 [details]
DyingLight-OpenGL-version
Comment 2 Vladimir Usikov 2016-06-09 10:53:49 UTC
Version of game that you use, want compatibility profile 3.3. In mesa compatibility profile 3.0. You may try force compatibility profile with:
MESA_GL_VERSION_OVERRIDE=3.3COMPAT

AFAIK Steam demo version of Dying Light use core profile.

Anyway i think this is not mesa bug.
Comment 3 Jan Ziak 2016-06-09 12:39:25 UTC
(In reply to Vladimir Usikov from comment #2)
> Anyway i think this is not mesa bug.

That's a mistake.
Comment 4 Vladimir Usikov 2016-06-09 13:34:26 UTC
>That's a mistake.

Why you think so?
Comment 5 Nicolai Hähnle 2016-06-10 10:09:56 UTC
Vladimir already told you how to work around this issue.

A long time ago, a decision was made for Mesa not to increase the advertised compatibility profile version. It is rather unlikely that you would be able to change people's mind on this - and in any case, this bug report (which is realyl more of a feature request) is not the correct forum to attempt to do so, so I'm closing it.
Comment 6 Jan Ziak 2016-06-10 12:34:53 UTC
(In reply to Nicolai Hähnle from comment #5)
> Vladimir already told you how to work around this issue.
> 
> A long time ago, a decision was made for Mesa not to increase the advertised
> compatibility profile version. It is rather unlikely that you would be able
> to change people's mind on this - and in any case, this bug report (which is
> realyl more of a feature request) is not the correct forum to attempt to do
> so, so I'm closing it.

Ok. We need to wait some time to see which prediction is correct.
Comment 7 Adam Bolte 2016-09-18 23:40:18 UTC
MESA_GL_VERSION_OVERRIDE=3.3COMPAT does not work for me. Jan, did it work for you? All I get is either a crash (after the loading screen), or a blank screen with sound playing in the background. The warning about a lack of support for 3.3 compatibility profiles does not go away.

I've tried launching steam with "export MESA_GL_VERSION_OVERRIDE=3.3COMPAT" ran in the xterm prior, and I've tried using MESA_GL_VERSION_OVERRIDE=3.3COMPAT as an argument to the game from within the Steam launch options. No difference either way.

Is this a different issue? Should I open a separate bug?

Also, can we get a link to where the decision was made to not support the compatibility profile, or a quick explanation as to why this is the case? Thanks.
Comment 8 Jan Ziak 2016-09-19 11:40:02 UTC
(In reply to Adam Bolte from comment #7)
> MESA_GL_VERSION_OVERRIDE=3.3COMPAT does not work for me. Jan, did it work
> for you? All I get is either a crash (after the loading screen), or a blank
> screen with sound playing in the background. The warning about a lack of
> support for 3.3 compatibility profiles does not go away.
> 
> I've tried launching steam with "export MESA_GL_VERSION_OVERRIDE=3.3COMPAT"
> ran in the xterm prior, and I've tried using
> MESA_GL_VERSION_OVERRIDE=3.3COMPAT as an argument to the game from within
> the Steam launch options. No difference either way.
> 
> Is this a different issue? Should I open a separate bug?

The game needs OpenGL 4.4.
Comment 9 Adam Bolte 2016-09-20 00:37:11 UTC
Ahh... nice. Thanks for pointing that out. Seems it should be working soon enough then.
Comment 10 Jan Ziak 2016-10-14 09:38:34 UTC
Quote from [https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/904490-another-fun-day-in-mesa-git-radv-nvc0-radeonsi?p=904568#post904568]:

The first 2 frames contain:

[code]
1063 @0 glMatrixMode(mode = GL_MODELVIEW)
1064 @0 glLoadIdentity()
1065 @0 glViewport(x = 0, y = 0, width = 512, height = 256)
1066 @0 glMatrixMode(mode = GL_PROJECTION)
1067 @0 glLoadIdentity()
....
1090 @0 glBegin(mode = GL_TRIANGLE_STRIP)
1091 @0 glTexCoord2f(s = 0, t = 0)
1092 @0 glVertex2f(x = 0, y = 0)
1093 @0 glTexCoord2f(s = 1, t = 0)
1094 @0 glVertex2f(x = 512, y = 0)
1095 @0 glTexCoord2f(s = 0, t = 1)
1096 @0 glVertex2f(x = 0, y = 256)
1097 @0 glTexCoord2f(s = 1, t = 1)
1098 @0 glVertex2f(x = 512, y = 256)
1099 @0 glEnd()
[/code]

For reference: https://www.opengl.org/wiki/Legacy_OpenGL

Although the 3rd and subsequent frames are missing from qapitrace, it can be assumed that Dying Light is most likely using the compatibility mode.
Comment 11 Adam Bolte 2016-10-17 22:24:44 UTC
Confirming this game does not work without compatibility profiles. Can we get a link to the discussion on why compatibility profiles will not be supported?

Overrides do not work, so am I to understand that Dying Light will never be supported by Mesa due to the OpenGL feature set it uses? Or can this bug be reopened (or perhaps a new bug)?
Comment 12 Adam Bolte 2016-10-17 22:27:48 UTC
To be more accurate, I should instead write "confirming this game does not work, which is presumably due to a lack of compatibility profile support".
Comment 13 Jan Ziak 2016-10-17 22:48:43 UTC
(In reply to Adam Bolte from comment #11)
> Overrides do not work, so am I to understand that Dying Light will never be
> supported by Mesa due to the OpenGL feature set it uses? Or can this bug be
> reopened (or perhaps a new bug)?

In my opinion (which might differ from the opinion of a number of Mesa developers), the case isn't that Dying Light will never be supported. Currently, Mesa developers are investing their time into "OpenGL core profile" features and performance (and into Vulkan support). After they are done with this work, which will happen in year 2018 or later, the topic of supporting compatibility profiles in Mesa can be brought up again.

(This isn't a place for discussing Mesa's future, so this is my last comment on this topic here.)
Comment 14 Adam Bolte 2016-10-17 22:52:13 UTC
Thanks for your thoughts. Much appreciated.
Comment 15 Samuel Pitoiset 2017-05-20 15:34:45 UTC
The following commit should fix Dying Light:

https://cgit.freedesktop.org/mesa/mesa/commit/?id=2b878cb8fdb99dd84602553c2e95ef47747f4529
Comment 16 Adam Bolte 2017-05-21 05:50:25 UTC
Confirming, it works now - provided I set the MESA_GL_VERSION_OVERRIDE first. Failure to set this causes a blank screen (but audio can be heard from the intro video).

The following game launch option can be set in Steam:
MESA_GL_VERSION_OVERRIDE=4.1 %command%

4.1 is the minimum that works and does not throw the warning box (shown in Jan's attached image). Setting the override to 3.3 also gets the game to run (I didn't bother testing any lower than that), but with the warning.

The game still runs too slow to be enjoyable - it's borderline unplayable. I was never able to hit 30 FPS (quite bad for this type of game), but at least it's running.

Having said that, using MESA_GL_VERSION_OVERRIDE=4.5 seems to give me a few extra in-game FPS. My overclocked i7-6700k and Fury X at 2560x1440 with high detail settings and maximum draw depth (but no AA and motion blur) was giving me on average around 26 FPS in the camp where I restored my save point from (running back and forth), whereas I was never able to get past 23 FPS in the same area by setting the override to 4.1. I tested that twice to be sure.

Would be great if there were a way to take care of these overrides automatically in drirc - which is what this bug was originally about. Are we certain this is still WONTFIX?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.