GL_ARB_compatibility not supported when trying to run game

[.Striker.]

I've been trying to make Wine run Fate/Extella, a game available on Steam, for the past days. I tried searching for this game on the application database but it does not seem to have an entry yet. Therefore, I tried my own hand at testing it. However, after installing it and trying to run its executable, Wine just opens the game in a black screen, which remains open for some seconds while I can hear the audio of the game (specifically, a guy saying the name of the company who created the game, "Marvelous", which I suppose to happen when its logo appears). However, a little after that, the game simply crashes. Meanwhile, a lot of "fixmes" are printed to the console, and also a sole err message like this appears among them:

err:winediag:wined3d_adapter_init GL_ARB_compatibility not supported, requesting context with GL version 3.2.

I've already tried testing it at both Debian Stretch and Arch and the error is the same in both of them, and also tried activating and deactivating staging settings (I'm using 2.14-staging) to see whether it would work or not and absolutely nothing changes, so I'm guessing it may have something to do with the video drivers (amdgpu + mesa) or my GPU (Radeon R9 270), but I'd like to know what is causing it and whether it can be fixed or not, if possible. I also outputted the console messages to a file which content I've uploaded here.

Thanks in advance.

[Bob Wya]

@.Striker.

Depending on what the exact output of:

Code: Select all

glxinfo | egrep 'version[: ]'

is...

You could try overriding the advertised OpenGL profile that Mesa reports back...
See Freedesktop Bugzilla / Bug 96449 - Dying Light reports OpenGL version 3.0 with mesa-git...

Code: Select all

export MESA_GL_VERSION_OVERRIDE=4.5
...

Wine needs a Core GL profile ≥3.2 to be able to support DirectX 10/11 translations.

Bob

[.Striker.]

Running glxinfo | egrep 'version[: ]' gives me this:

Code: Select all

server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Max core profile version: 4.3
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL core profile version string: 4.3 (Core Profile) Mesa 13.0.6
OpenGL core profile shading language version string: 4.30
OpenGL version string: 3.0 Mesa 13.0.6
OpenGL shading language version string: 1.30
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 13.0.6
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

So I tried running both export MESA_GL_VERSION_OVERRIDE=4.3 and export MESA_GL_VERSION_OVERRIDE=3.2. Although the err line above doesn't appear anymore, the game does not even open (its launcher does, however) and throws an unhandled exception right at the start.

Code: Select all

wine: Unhandled page fault on read access to 0x00000000 at address 0x7fe303f3b646 (thread 0034), starting debugger... 

I've pasted the full log https://pastebin.com/Gesgery9 if anyone wants to see it.

[Bob Wya]

@.Striker.

Your Mesa version is months out-of-date.
You'd need to update to the latest stable release - Mesa 17.1.7 - at the time of posting.
Otherwise you'll be troubleshooting video driver issues - not Wine issues...

Bob

[.Striker.]

So, I upgraded mesa to the latest version available on Arch repositores (17.1.6). glxinfo gives me this now:

Code: Select all

server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.1.6
OpenGL core profile shading language version string: 4.50
OpenGL version string: 3.0 Mesa 17.1.6
OpenGL shading language version string: 1.30
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 17.1.6
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

The problem still occurs. I also tried mesa-git and no dice.

[Bob Wya]

Stick with:

Code: Select all

export MESA_GL_VERSION_OVERRIDE=4.5

In case Wine is still trying to use the compatibility GL version 3.0 that Mesa advertises...
Just a matter of the Mesa driver not having official Kronos Group certification I think...
I'd probably put this in a global system env variable, e.g.

Code: Select all

sudo sh -c 'echo "MESA_GL_VERSION_OVERRIDE=4.5" >> /etc/env.d/03opengl'

- makes life easier!

Then try some additional registry tweaks that Wine offers to force the use of a higher OpenGL profile:

Code: Select all

REGEDIT4

[HKEY_CURRENT_USER\Software\Wine\Direct3D]
"MaxShaderModelGS"=dword:00000005
"MaxShaderModelPS"=dword:00000005
"MaxShaderModelVS"=dword:00000005
"MaxVersionGL"=dword:00040005

See: WineHQ: Useful Registry Keys ...

Plus overrides for some (typically required) API extension libraries that aren't fully completed yet:

Code: Select all

winetricks -q d3dx9_42 d3dx10_42 d3dx11_42 d3dcompiler43

See: WineHQ: Win API Stats ...

These overrides are needed purely because the Wine DirectX 11 translation layer is very much in a state of partial completion at present.

Bob

[ls_boy]

I'm not really good with regular expressions. What is this?

Code: Select all

'version[: ]'

Nevermind.

[.Striker.]

Stick with:

Code: Select all

export MESA_GL_VERSION_OVERRIDE=4.5

In case Wine is still trying to use the compatibility GL version 3.0 that Mesa advertises...
Just a matter of the Mesa driver not having official Kronos Group certification I think...
I'd probably put this in a global system env variable, e.g.

Code: Select all

sudo sh -c 'echo "MESA_GL_VERSION_OVERRIDE=4.5" >> /etc/env.d/03opengl'

- makes life easier!

Then try some additional registry tweaks that Wine offers to force the use of a higher OpenGL profile:

Code: Select all

REGEDIT4

[HKEY_CURRENT_USER\Software\Wine\Direct3D]
"MaxShaderModelGS"=dword:00000005
"MaxShaderModelPS"=dword:00000005
"MaxShaderModelVS"=dword:00000005
"MaxVersionGL"=dword:00040005

See: WineHQ: Useful Registry Keys ...

Plus overrides for some (typically required) API extension libraries that aren't fully completed yet:

Code: Select all

winetricks -q d3dx9_42 d3dx10_42 d3dx11_42 d3dcompiler43

See: WineHQ: Win API Stats ...

These overrides are needed purely because the Wine DirectX 11 translation layer is very much in a state of partial completion at present.

Bob

Took me some time, but I tried all of this and no dice. Game throws an unhandled exception right after I launch it if I run "export MESA_GL_VERSION_OVERRIDE=4.5" just like before. If I don't do it, it opens but still has the same black screen problem, and produces the same errors of before, the only difference being that it doesn't crash by itself anymore and I have to terminate it with Ctrl+C in the terminal. Also, adding MaxVersionGL to the registry with 00040005 as value seemed to produce an err in both attempts:

Code: Select all

err:winediag:wined3d_dll_init Setting maximum allowed wined3d GL version to 4.5.

Which seems to be the only difference in result between my past attempts and this one. The rest of the errors is still the same.

I suppose there's no way to run this then?

[Bob Wya]

@.Striker.

If games do start in DirectX 10/11 mode they tend do so with lots of graphical/visual defects and poor performance.
That's fine for testing purposes - but not great if you want to play them!
I just re-check out my DirectX 10/11 games - with each Wine Staging release...

Btw:

Code: Select all

glxinfo | egrep 'version[: ]'

egrep='grep --extended-regexp' (BASH alias)
version[: ] is just a regular expression that matches: { "version " "version:" }
So the command pipes the output of glxinfo into grep to pattern match against lines with the above 2 patterns.

Bob

[.Striker.]

Just updating this. I was finally able to get the game to work in a fresh prefix with just CSMT activated in wine-staging 2.16. However, performance is very, very slow. It takes minutes just to get past the initial loading screens and FPS is just horrible. It's simply impossible to be played at the moment.

I also created a page for this in the App DB: https://appdb.winehq.org/objectManager. ... &iId=35750

[Bob Wya]

@.Striker.,

That's good... OK, it doesn't sound so good...
But at least you can track Wine's DirectX 10/11 implementation progress!

Wine Staging CSMT doesn't support the DirectX 10/11 APIs - which kills performance at present.

Bob

[DarkPlayer]

The support for Direct3D10/11 is not affected by the CSMT, neither in Wine nor Wine Staging. Only old versions of Staging (<= 2.0) contained optimizations for d3d9 that were not compatible with D3D10/11. See https://wine-staging.com/news/2017-02-0 ... e-2.1.html for more information. Wine is not bug free, but in general it should be safe to enable the CSMT for all Direct3D versions.

[Bob Wya]

The support for Direct3D10/11 is not affected by the CSMT, neither in Wine nor Wine Staging. Only old versions of Staging (<= 2.0) contained optimizations for d3d9 that were not compatible with D3D10/11. See https://wine-staging.com/news/2017-02-0 ... e-2.1.html for more information. Wine is not bug free, but in general it should be safe to enable the CSMT for all Direct3D versions.

I should read your blogs and commits more closely! Hah hah! Takes foot out of mouth...

I was under the impression that the Wine Staging implementation of CSMT wouldn't yet do much to help performance for the Direct3D10/11 pathways...
Is that the case?

Thanks for the clarification.

Bob

[DarkPlayer]

The ideas behind Direct3D9 / 10 / 11 aren't that different and the drawing works basically in the same way. They all call wined3d_device_draw_[index_]primitive[_instanced] and wined3d does not make a difference whether it is called from d3d9 or d3d11. The same also applies for most other wined3d functions. All OpenGL calls must go through the CSMT code anyway, otherwise you would run the commands in the wrong order and get graphic glichtes (which often happens when a game uses d3d from different threads without CSMT). I would therefore say the CSMT affects d3d9 and d3d11 in the same way.

It is possible that there are some speed differences, but they are not directly caused by the CSMT. Direct3D11 tends to move more work to the GPU (e.g. compute shaders), so maybe the generated GLSL shaders are inefficient or there is some other bad OpenGL usage. From my experience the CPU bottleneck for D3D11 games is the mapping of vertex and constant buffers. They are usually updated before each draw call and require a synchronization between the CSMT thread and the caller. There are ways to work around this problem, but they add a lot of complexity and can lead to bugs.