Run your program like this:
WINEDEBUG=+wgl wine your_3d_app.exe &> wine.log
It will save the log to wine.log.
There you should see which version and why it is reported.
Upload the log or post it here as code.
Just a thought: Maybe for some reason it fallback to software rendering?
i executed the command:
winedebug=+wgl wine Vital.exe &> wine.log
MESA-INTEL: warning: Haswell Vulkan support is incomplete
Application could not be started, or no application associated with the specified file.
ShellExecuteEx failed: File not found.wine: Unhandled page fault on write access to 0000000000000000 at address 00007FAA5262E9BB (thread 0070), starting debugger…
0070:err:seh:start_debugger Couldn’t start debugger L"winedbg --auto 96 64" (1115)
Read the Wine Developers Guide on how to set up winedbg or another debugger
I’ve been searching around and found that to fix that vulkan error you need DRI3 enabled.
To enable DRI3, you need to create a config for the integrated card adding the DRI3 option:
Section “Device”
Identifier “Intel Graphics”
Driver “intel”
Option “DRI” “3”
EndSection
So the problem was not OpenGL, but Vulkan? 
this is the error that the program gives me, along with a black window where graphics should be:
and wine.log makes no mention of OpenGL at all. There is a native Linux version that works, as well as Windows and OSX. But I need the Windows version to run in WINE for reasons.
I’m pretty sure the problem is related to the Haswell-Vulkan thing, going by the output in wine.log
I tried to go into xorg.conf (i know, scary) and it appears to be blank and I don’t want to create anything in there because I’d like there to be a Manjaro-y way to ‘enable DRI3’
That clearly says, that there is no file called “Vital.exe”. Vital.exe must be in your working dir.
Nope sorry. It is not. Have you installed DXVK? If not, then not related.
So, come on. If you want to solve you problem with that app yourself, then go for it, but if you want help, then let us not poke in the dark.
How did you install that program?
Which program?
The program has a windows, linux, and OSX installer and is found at:
I used the windows installer thru WINE on a fresh installation of Manjaro, (which does not work) in addition to the Linux native installer, which does work no problem. Which is why I’m leaning towards this being a WINE configuration issue but I can’t see anything in WINE about which OpenGL version it thinks it is using other than the strange error message that says this:
wine taskmgr:
the debugger code I’m using:
winedebug=+wgl wine Vital.exe &> wine.log
the contents of wine.log is now the following, regardless if Vital.exe is already running or if it is being instantiated by the winedebug command:
Application could not be started, or no application associated with the specified file.
ShellExecuteEx failed: File not found.
and yes, it does feel like I am shooting in the dark over here, but I’ve been around long enough to not lash out and get angry at folks trying to help me so never fear!
here’s a screeny of the WINE window where the GUI ought to be:
I just saw it. WINEDEBUG in uppercase is important. Type it just as I wrote.
I run this program myself… this part is important:
00fc:trace:wgl:X11DRV_WineGL_InitOpenglInfo GL version : 4.6.0 NVIDIA 470.63.01.
00fc:trace:wgl:X11DRV_WineGL_InitOpenglInfo GL renderer : NVIDIA GeForce GTX 1050 T
i/PCIe/SSE2.
00fc:trace:wgl:X11DRV_WineGL_InitOpenglInfo GLX version : 1.4.
00fc:trace:wgl:X11DRV_WineGL_InitOpenglInfo Server GLX version : 1.4.
00fc:trace:wgl:X11DRV_WineGL_InitOpenglInfo Server GLX vendor: : NVIDIA Corporation.
00fc:trace:wgl:X11DRV_WineGL_InitOpenglInfo Client GLX version : 1.4.
00fc:trace:wgl:X11DRV_WineGL_InitOpenglInfo Client GLX vendor: : NVIDIA Corporation.
00fc:trace:wgl:X11DRV_WineGL_InitOpenglInfo Direct rendering enabled: True
So it looks for the GLX Version, which is 1.4 for me. But yours have to be 1.3 then. I guess this is not upgrade-able since it is fixed version for the GPU and you are on a bleeding edge mesa driver. It is hardcoded into the code and ensures that only GPUs, which are capable with the additional features of the next version, will work.
To unlock that, you have to hack the mesa code and compile it yourself. But don’t expect it will work flawless.
At least you know it asks for the GLX Version and not for GL Version.
glxinfo | grep "GLX version"
Why does it work on Windows on the computer? I guess the driver is here to blame. But indeed changing DRI2 to DRI3 could probably solve this problem.
/etc/X11/xorg.conf.d/20-intel.conf
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "DRI" "3"
EndSection
Possible it will not work and you end with a black screen. It is good to have a Manjaro Boot Disk ready, just in case. To revert it, just delete this file on a Live Session.
I’ve done the WINEDEBUG thing a few times, no wonder I got different results in subsequent tries after having forgotten to write it rude.
but the plot thickens: (this is before writing any conf file. a true mystery why WINE is confus.)
I’ve written the conf file to the directory you specified. battening down the hatches and got my trusty bootable USB stick with Manjaro KDE in tow. See you on the flip side 
edit:
Ok I’m back, and there was a bit of jitter happening on reboot, and WINE needed to do some reconfiguring, but the GUI of Vital is still black. Now however the ‘exception’ messages are gone. I’ll have to see if I will leave that conf file in place, maybe it’s useful but not sure.
[edited] First you can open wine regedit, create a new registry key named Direct3D in HKEY_CURRENT_USER\Software\Wine if it’s not already there, create a new DWORD string in Direct3D, name it MaxVersionGL and add 10004 as the value. That will/may force wine to report higher opengl (and direct3d) support up to v1.4 to the apps. But it’ll comeback to your actual hardware capabilities and driver. If by any chance mesa is the one that doesn’t report correctly, then you can force it by environment variable MESA_GL_VERSION_OVERRIDE=1.4
Good luck.
I’ll try that suggestion with Regedit in WINE and see what happens. I have no idea what to think after searching this topic and getting results that only deepened the waters.
If I may ask, why using WINE if the app have native linux version?
because coming from windows only days ago, i have a large project that uses windows based plugins that don’t work in Linux natively, as far as I can tell at least. My intention originally was to dual boot but since I don’t actually own Windows, and I don’t want to purchase a license, and I have experience with Linux, and I was willing to cut my losses, and so on… one thing led to another. I fully get there’s some chores involved figuring out the mountains of RTFM that are inherent to the deal, but maybe someone else out there has already been on that RTFM trail. Also, new to arch and it’s fun. Manjaro seems to be a pretty cool bunch as far as I can tell.
I see. I never use Vital before and I don’t have the same hardware as the one you’re using with. So I can only guess a workaround for your problem. You may also ask Vital’s developer and users about this on their forums. Again, good luck.
The developer, Matt Tytel, has stated he doesn’t support for WINE, but I’m sharing my findings on a thread at his website just for the sake of science.
Is this your output from glxinfo? (edit: I took that from the link you gave)
Blockquote
glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel® HD Graphics 4600 (HSW GT2)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 21.2.1
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 21.2.1
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 21.2.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:
Have you tried using environment variable to force mesa to use compatibility context? Run MESA_GL_VERSION_OVERRIDE=4.5 wine 'path/to/your/app.exe' (or just use explorer instead of path to the app. I use that a lot.) and test that app again.
For science, lol, you can run MESA_GL_VERSION_OVERRIDE=4.5 glxinfo | grep OpenGL and look at your shading language version again.
BINGO!
This fixes it! i repeat, this works!
MESA_GL_VERSION_OVERRIDE=4.5 wine ‘/home/username/.wine/drive_c/Program Files/REAPER (x64)/reaper.exe’
Now all I need is to make persistent “MESA_GL_VERSION_OVERRIDE=4.5”
Good to know. I don’t recommend to pass that environment variable widely on your system, but if you really want to, you can set that per user only or make a shortcut to the wine app with that env on.
Here’s the thread someone started at the Vital forum and I gave you a mention in.
I’m the only user of my system, so where would I set the variable for whenever WINE is started? Otherwise I guess I could build it into a symlink for my Digital Audio Workstation software?
Oops, turns out you won’t be able to pass env on a symlink, but you’re free to try. Anyway, this arch wiki mention about how you can set env globaly, per user, or per session. Maybe worth checking: Environment variables - ArchWiki
Edit: If you’re using KDE desktop, you can pass env by making a .sh file (ie; glcompat.sh) in /Home/User/.config/plasma-workspace/env/, add export MESA_GL_VERSION_OVERRIDE=4.5 to that file and make it executable. Again, this is only works in KDE desktop. I’m KDE user, btw. 
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.