Bug 104490 - [radeonsi/290x] Dota2 fails to start (can't create opengl context)
Summary: [radeonsi/290x] Dota2 fails to start (can't create opengl context)
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
: 104627 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-01-04 12:14 UTC by Sebastian Parborg
Modified: 2018-04-25 03:56 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
glxinfo (105.69 KB, text/plain)
2018-01-04 12:14 UTC, Sebastian Parborg
Details

Description Sebastian Parborg 2018-01-04 12:14:58 UTC
Created attachment 136546 [details]
glxinfo

I've been trying to figure out the cause for this bug for quite some time now. Here is the bug ticket on the dota2 github page:
https://github.com/ValveSoftware/Dota-2/issues/1368

Since about one week ago, I have been unable to start dota2 on my machine. This happened after I updated my llvm and mesa git version.

If I downgrade to mesa 17.3.1 it works again (without reboot). But it seems to be really hard to track down the commit that broke it as there seems to be some kind of cached behaviour (not the mesa shader cache as I removed the directory and rebooted several times).

For example I downgraded mesa to a commit from 2017-11-17 and it worked. The next day I tried to figure out the commit that broke it. But I could then use the git master version and it seemed to work fine again.

Then the next day I'm back to the same problem and I downgraded again and now it won't start again even if I use mesa from 11-17 (and rebooted). But 17.3.1 still works if I downgrade to that... (no reboot)

I really do not know how to debug this further as I don't know when I'm on the commit that broke it or not. However it seems to always break if I'm on a commit that is newer than 1-2 weeks (after a reboot that is). However it will not fix itself with reboots with commits older than that either...
Comment 1 Sebastian Parborg 2018-01-04 12:16:19 UTC
Forgot to mention:
As I stated in the github issue, only dota seems to have this problem. No other program/game fails to create a opengl context for me. So I'm quite unsure why it is just dota2 that has problem now.
Comment 2 Michel Dänzer 2018-01-04 16:29:45 UTC
(In reply to Sebastian Parborg from comment #0)
> [...] there seems to be some kind of cached behaviour (not the mesa shader
> cache as I removed the directory [...]

Which directory exactly did you remove? Have you tried setting the environment variable MESA_GLSL_CACHE_DISABLE=true to see if that avoids the problem?
Comment 3 Mike Lothian 2018-01-04 16:46:01 UTC
I'm wondering if this has been the issue I've been seeing on Bioshock

Will let out an older Mesa when I get home and bisect if that's the case
Comment 4 Sebastian Parborg 2018-01-04 23:41:48 UTC
(In reply to Michel Dänzer from comment #2)
> (In reply to Sebastian Parborg from comment #0)
> > [...] there seems to be some kind of cached behaviour (not the mesa shader
> > cache as I removed the directory [...]
> 
> Which directory exactly did you remove? Have you tried setting the
> environment variable MESA_GLSL_CACHE_DISABLE=true to see if that avoids the
> problem?

I removed "~/.cache/mesa_shader_cache". I tried that environment variable now and it doesn't seem to solve it either for me (with mesa from 2017-12-01)...

I really do not know how I should try to bisect this...
Comment 5 Sebastian Parborg 2018-01-05 03:29:27 UTC
I spoke too soon. It seems like I needed to go back a bit further. And with MESA_GLSL_CACHE_DISABLE=true, it seems like I could pinpoint the commit.

This is the commit that breaks dota2 for me:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=0d044351b7043cd0bc94c1cb9b7a2213f8054414

I reverted that one and tried the master branch and now it works. I'm guessing that there is some implementation bugs or something as that commit only seems to switch on already implemented stuff.
Comment 6 Mike Lothian 2018-01-05 07:52:55 UTC
I think this also affects i965 too

6ce9006d76c050663af0be61cc88c3215d6f8cea is the first bad commit                                                                                                                                                                                              
commit 6ce9006d76c050663af0be61cc88c3215d6f8cea                                                                                                                                                                                                               
Author: Neil Roberts <neil@linux.intel.com>                                                                                                                                                                                                                   
Date:   Wed Oct 1 20:00:50 2014 +0100                                                                                                                                                                                                                         
                                                                                                                                                                                                                                                              
    i965: Enable flush control                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                              
    Reviewed-by: Adam Jackson <ajax@redhat.com>                                                                                                                                                                                                               
    Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>                                                                                                                                                                                                     
    Reviewed-by: Emil Velikov <emil.velikov@collabora.com>                                                                                                                                                                                                    
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>                                                                                                                                                                                                      
    Signed-off-by: Neil Roberts <neil@linux.intel.com>
Comment 7 Mike Lothian 2018-01-05 08:11:06 UTC
I can confirm reverting both those commits, allows me to launch BioShock Infinite on both radeonsi and i965 on master
Comment 8 Michel Dänzer 2018-01-05 09:05:16 UTC
Adam, any ideas?
Comment 9 Mike Lothian 2018-01-14 13:44:10 UTC
Has there been any progress on this bug?
Comment 10 Christian Inci 2018-01-15 03:42:49 UTC
*** Bug 104627 has been marked as a duplicate of this bug. ***
Comment 11 Adam Jackson 2018-01-15 19:51:35 UTC
I've reverted these for now. I'm reasonably sure that the issue is a skew between X server and Mesa, such that the app thinks it can create a no-flush context but either the server or libGL disagrees and throws an error. This shouldn't be terribly hard to track down for someone with the time and motivation; at the moment I lack the time.
Comment 12 Sebastian Parborg 2018-01-29 07:24:44 UTC
Adam, is there anything I can do to help you figure out what goes wrong?
Comment 13 Timothy Arceri 2018-04-25 03:56:35 UTC
The original issue is fixed so closing.


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.