Some games work while others run up to main menu & don't load to in-game

[hotcapy]

Nowdays latest versions of Wine's forks already includes patch that should fix Nine. I tested few random and different DirectX 9 games on my old laptop. It has no Vulkan support (and so can't run DXVK at all) and perfomance with default WINED3D is not playable or acceptable for most games. Dedicated GPU is AMD/ATI. All of the above are reasons why I need to use Nine but not something else.

Some old games like SPORE and WALL-E work perfectly (at least in aspects that I already tested in-game). Others like Need for Speed: Hot Pursuit 2010 and Divinity II: Developer's Cut don't with similar symptomps (but maybe for different reasons - it is unknown for me).

They run, main menu and various options are visible and have no visual problems, but as soon as you choose to load your save game, screen becomes black for some time and then game just closes.

I do not have enough knowledge to understand what is wrong from logs myself - I see no messages that could be related to issue - but it is just me. Maybe you could properly read them and then tell me where is the problem hides?

Some context: NFS has no special dependencies, while Divinity strictly requires Physx to run. Winetricks provides latest Physx and it works with default WINED3D. Game successfully loads and plays. With Nine Physx helps only up to main menu - game can't load save file. Istalling Physx legacy version which comes with game itself not helps in both cases (game not opens at all w/o Winetricks's Physx). Without Nine perfomance for Divinity is sad, and extremely sad for NFS (unplayable).

I tried many things on my side to fix the issue. Using system-wide Wine-tkg from terminal or Wine-GE from Lutris (to make use of it's runtime), changing Wine's versions and various options like Windows versions & x32/x64 prefix bit, game's graphics settings, using or not ESYNC/FSYNC, and many other thing that I can't remember anymore. Nothing changes anything.

Nine in logs is active. Please note, that Divinity has some problems with video playback (fixed in latest GE using WINED3D), so many messages in log could be related to that problem and not the crash itself. NFS log says sth about FS but if I remember right it says the same with WINED3D so probably not related too.

My system and all software including Wine-related are fully up-to-date. FS is BTRFS, OS is EndeavourOS (Arch), desktop is KDE, GPU driver is AUR mesa-git. Modules for Intel (intel_agp i915) and ATI (radeon) preloaded on boot. And, of course, using dedicated AMD card to run games from both terminal and Lutris. laptop-specs.txt nfs-log.txt divinity-log.txt

[lorn10]

For the record, this topic belongs to the r600 (and alternatively the crocus) driver in conjunction with Mesa devel 22.2.0. The hardware specs are:

model NP350V5C-S1ERU
screen 15.6" - 1366x768
cpu Intel Core i3 3120M 2.5GHz (2 cores, 4 threads)
code-name Gen7 - Ivy Bridge
ram 6GB - DDR3 - 1600MHz
integrated-gpu Intel HD Graphics 4000
dedicated-gpu AMD Radeon HD 7670M
family AMD Thames [Radeon HD 7500M/7600M Series] - TURKS - Northern Islands
camera Microdia WebCam SC-13HDL12639P - 1.3 MP
ethernet RJ-45 - 10/100/1000 MiB/s - Gigabit
wireless 802.11 b/g/n
bluetooth 4.0
hdd 1000 GB - 5400 RPM
odd DVD-RW
card-reader SD/SDHC/SDXC
input 19V = 3.16A (60W)
battery Li-Ion - 6 cell - 4400 mAh - 48 Wh - 11.1 V
release-date Jan.2013
bios-version P09ABE
micom-version P09ABE

@hotcapy Thanks for your report. It looks that you got a somewhat bad timing for your testing. The r600 driver is currently under a super heavy refactoring. The old TGSI path will be fully ditched and replaced by a new NIR backend. More information can be found here. This means that you have to use from now on the R600_DEBUG=nir option which will be most likely the new default in Mesa 22.2.0 final.

And if you notice any further errors, then please try to produce an apitrace so that the devs have the chance to reproduce the problem. :wink:

[hotcapy]

@lorn10 Hi! Thank you very much for your really fast answer.

Unfortunately, when I set "R600_DEBUG=nir" option, my games do not start at all: same way and all of them, including SPORE and WALL-E, which worked with Nine fine before.

I used "apitrace" tool on SPORE as example since SPORE is working without "nir" option for both Nine and just Wine. I hope I did it in right way. Just in case it can be useful someway I also saved trace and log of working SPORE with Nine without "nir" option.

Link to MEGA cloud folder with traces and logs: https://mega.nz/folder/FQtCXZgA#CzplU8iNWsInpAqVx5pFHQ

I tried to use obvious filenames but here is detailed explanation:

with-nir_not-working - "nir" option used, SPORE is not starting anymore; without-nir_working - "nir" option not used, Nine is enabled, SPORE is working and fully playable; *.log - just output from Lutris for both cases with "Output debugging info" option set to "Enabled".

If I can provide any additional info about my configuration that might help someway please let me know :-)

[axeldavy]

Divinity II definitely used to work here, as well as Hot Pursuit. This is unrelated to PhysX, we don't interact with it. I have found at least one regression leading to a crash that I fixed on this branch (https://gitlab.freedesktop.org/axeldavy/mesa/-/tree/unsupported_features_emulation). In the following weeks, I plan to check for more regressions running all my previous traces.

[gerddie]

I'd like to chime in that R600_DEBUG=nir will not become the default with Mesa 22.2.0, it's simply not there yet. More helpful logs with R600 nir can be obtained by setting R600_NIR_DEBUG=instr,ass,steps

BTW: the log of the failure shows an assertion failure with std::array<bool,4>, the r600 nir backend doesn't use this specific array declaration, at least not directly.

[gerddie]

What is true however, is the code path glsl-to-tgsi will be replaced by glsl-to-nir + nir-to-tgsi.

[hotcapy]

@gerddie Hi! I uploaded .log and .trace files with R600_NIR_DEBUG=instr,ass,steps option set to the same cloud folder.

[gerddie]

Your using an old version of mesa - the reworked nir code landed just recently (and that's why I couldn't find the std::array<bool,4> because in the new code it is gone). You should re-test with mesa-22.2.0-rc1

[hotcapy]

Oh, I see. As I mentioned before, I have no special knowledge for drivers and that kind of things, unfortunately. So I'm just using "mesa-git" package from AUR. Since I don't know how to install new version by myself, I think I have to wait when AUR's package maintainer will make an update. I'm sorry for that. Actually the only thing I know here is how to run games using Wine. But if it is not super-hard and someone will explain me in details what exactly should I do - I can give it a try of course.

[gerddie]

I see, well then just wait until 22.2.0-rc1 is packaged there, and retest with that (I myself are not that familiar with arch Linux)

[lorn10]

@hotcapy By the way, you should be able to test all your games also on your Intel "Ivy Bridge" iGPU via parameter DRI_PRIME=0 or DRI_PRIME=1. I think those old DX9 games will run fine on the Intel HD 4000 GPU which is in fact DX11 class hardware.

With this you can effectively check if a problem is more Gallium Nine or Mesa driver related. So if a problem exist with both GPUs then it is more Gallium Nine related while otherwise it is most likely a Mesa driver thing. :+1:

[hotcapy]

Today I did few more tests and results were interesting and... Unpredictable a bit. It will be long post and lot of letters, I'm sorry for that! :c

As @lorn10 suggested, I tried to run all of my installed games on integrated GPU "Intel HD Graphics 4000" instead of dedicated one "AMD Radeon HD 7670M". Nine is active in all cases.

"Divinity II: Developer's Cut" didn't crashed after loading screen and successfully loaded my save file, but in-game everything is black: I see no textures or models - just black screen. The only thing that is working is user interface. I can even open character's inventory, see items in it, their pictures and descriptions, maybe do something with them, access skills page and all that sort of UI thing. I can also access pause menu and exit from game as usual.

"Need for Speed: Hot Pursuit 2010" showed me even better results: instead of crash at the moment of race select or world freedrive select game successfully loads though all loading screens and car selection window to the game world. But perfomance is pretty bad. It is already playable, but not very enjoyable that way - FPS feels low. As I mentioned before, without Nine on Radeon GPU perfomance feeled like 1 FPS and was absolutely unplayable.

"SPORE" gave me a little surprise and... did not start at all. Just closes few seconds after I starting it. Don't know why.

"WALL-E" successfully starts and plays. Perfomance is good and game is playable. But on Radeon GPU perfomance is perfect. On Intel GPU I feel something like little input lag that is not present on Radeon GPU, so FPS is probably a bit lower, but still good.

Since "Divinity II: Developer's Cut" and "SPORE" do not work this way, I uploaded their logs and traces to the cloud. If it will help someway, I can do the same for the working games too.

I have few thoughts. First is about "SPORE": maybe game is just too register sensitive or something like that? Mostly unlikely, but Wine prefixes are not clean in all cases, since it takes too much time to test all possible settings and configurations. At least it is something that we can keep in mind.

Second thought is about my laptop's GPUs. I knew that information already before all tests with Nine, but I just forgot about it. It seems that on software level Linux GPU drivers do not support/provide Radeon's actual OpenGL hardware version. In my case Intel GPU shows me OpenGL 4.2 version while Radeon GPU shows only OpenGL 3.3.

Here are some outputs from "inxi -G" terminal command:

[sexy-owl@shady-forest ~]$ inxi -G
Graphics:
  Device-1: Intel 3rd Gen Core processor Graphics driver: i915 v: kernel
  Device-2: AMD Thames [Radeon HD 7500M/7600M Series] driver: radeon
    v: kernel
  Device-3: Microdia WebCam SC-13HDL12639P type: USB driver: uvcvideo
  Display: x11 server: X.Org v: 21.1.4 driver: X:
    loaded: modesetting,radeon gpu: i915 resolution: 1366x768~60Hz
  OpenGL: renderer: Mesa Intel HD Graphics 4000 (IVB GT2) v: 4.2 Mesa
    22.2.0-devel (git-184ae84a0a)

[sexy-owl@shady-forest ~]$ DRI_PRIME=1 inxi -G
Graphics:
  Device-1: Intel 3rd Gen Core processor Graphics driver: i915 v: kernel
  Device-2: AMD Thames [Radeon HD 7500M/7600M Series] driver: radeon
    v: kernel
  Device-3: Microdia WebCam SC-13HDL12639P type: USB driver: uvcvideo
  Display: x11 server: X.Org v: 21.1.4 driver: X:
    loaded: modesetting,radeon gpu: i915 resolution: 1366x768~60Hz
  OpenGL: renderer: AMD TURKS (DRM 2.50.0 / 5.18.16-zen1-1-zen LLVM 14.0.6)
    v: 3.3 Mesa 22.2.0-devel (git-184ae84a0a)

And also from Lutris hardware information window:

[Graphics]
Vendor:          Intel
OpenGL Renderer: Mesa Intel(R) HD Graphics 4000 (IVB GT2)
OpenGL Version:  4.2 (Compatibility Profile) Mesa 22.2.0-devel (git-184ae84a0a)
OpenGL Core:     4.2 (Core Profile) Mesa 22.2.0-devel (git-184ae84a0a)
OpenGL ES:       OpenGL ES 3.0 Mesa 22.2.0-devel (git-184ae84a0a)
Vulkan:          Supported

[Graphics]
Vendor:          X.Org
OpenGL Renderer: AMD TURKS (DRM 2.50.0 / 5.18.16-zen1-1-zen, LLVM 14.0.6)
OpenGL Version:  3.1 Mesa 22.2.0-devel (git-184ae84a0a)
OpenGL Core:     3.3 (Core Profile) Mesa 22.2.0-devel (git-184ae84a0a)
OpenGL ES:       OpenGL ES 3.1 Mesa 22.2.0-devel (git-184ae84a0a)
Vulkan:          Supported

Please note that despite what Lutris says about Vulkan, my Radeon GPU does not support it while Intel GPU has limited support. I tried before to use Intel GPU + DXVK, but perfomance is much worse then without any DXVK/Nine and just with Wine on Radeon GPU.

Different websites says slightly different info, but if believe them, my Radeon GPU should support at least OpenGL 4.1 and up to 4.4 on hardware level. Can it be related to my issues? I don't know anything about it actually, but as I understand, OpenGL is used by Wine/Nine, right?

First time I noticed that was when I was interested in which games that I play on my desktop will also work on my laptop and I tried to run "Divinity: Original Sin" which is native on Linux but requires OpenGL 4.x support. I remember that I was not able to make it work and integrated Intel GPU failed it too. I searched a lot on internet and found lot of info about bug in Mesa which prevented game start on Radeon GPU, but it seemed it was fixed already at the moment. I believe it should work on Windows OS and maybe it even worked once on very-old Catalyst proprietary GPU drivers by AMD, but who knows? It can not be installed easy these days.

[gerddie]

The reason AMD TURKS graphics cards only expose OpenGL 3.3 when using the default setting is that these cards don't support ARB_gpu_shader_fp64 (i.e. 64bit floating point) in hardware. The old propriety frglx driver provided a software emulation of that feature and was, therefore, able to advertise OpenGL 4.4. With the new NIR back-end AMD TURKS also gets a software emulation of that feature and exposes OpenGL 4.5.

In any case, fp64 is a feature that is rarely used, and especially in games it was probably never required. At most some game developers were lazy, and instead of testing the actual features they might have just tested whether OpenGL >= 4.0 is supported and didn't start the game if it doesn't.

[lorn10]

@hotcapy Most likely the situation becomes better also for the Intel iGPU when a new AUR mesa-git release is available. The current version is one month old (2022-07-03). So the best is to wait for a newer release and then make one issue report per game. :wink:

[hotcapy]

Hi everyone! Quick update on the issue.

I updated both lib32-mesa & mesa from AUR, "clean" build for all, now version is 2022-08-17 22.3.0-devel. R600_DEBUG=nir env var is now working in most games, but it is unfortunately not helps.

Everything below are Radeon GPU & Nine enabled.

"SPORE" and "WALL-E" games, which worked without nir, continue to work good with nir as well. "NFS Hot Pursuit 2010" does not start when nir is enabled (similar to behavior of all games with nir before mesa update). "Divinity II: Developer's Cut" behavior with nir is absolutely identical - game starts, but closes at black screen which follows save loading screen. With Intel GPU, also just like without nir, save loads but everything in-game is black except UI. Intel GPU plays game intro videos (just dev logo) while Radeon GPU shows only flickering black screen during them.

I didn't took any logs & traces for now since issues are identical to previous ones, but if it can help somehow, please let me know for which games I should upload. Also if needed I can try to download & test some other games on my configuration if my set is not very helpful for issue investigating.

P.S. OpenGL version still detects as 3.3 for Radeon GPU and 4.2 for Intel GPU.

[lorn10]

Hi again & thanks for the feedback!

So two games are fixed, they now also work normally with the NIR path. :+1:

Regarding "Divinity II: Developer's Cut", that issue might be related to bug #143, a black rendering in the game "Prince of Persia Warrior Within".

When ever possible please make a new bug report only for that game which contains one AMD GPU trace (including R600_DEBUG=nir option) and one other for the Intel iGPU.

Addition: When you use DRI_PRIME=1 R600_DEBUG=nir inxi -G then you will be on OpenGL 4.5 level on the AMD GPU. :wink:

[gerddie]

@hotcapy The default OpenGL version is still 3.3, because to get a higher version reported you have to force the NIR backend when running whatever program you use to print that info.

[lorn10]

@hotcapy There were again some r600 driver related changes during the last 14 days. Can you perhaps retest all the mentioned games with option R600_DEBUG=nir,nosb? This will set it to NIR and it will disable on the same time the buggy r600 shader backend optimization.

Maybe I will find over the weekend some free time to test some of the latest r600 changes but on even older Radeon hardware. :+1:

PS Sorry I forget, you are not using the oibaf PPA (latest Ubuntu Mesa GIT builds). But maybe the R600_DEBUG=nir,nosb option will still have some effect in some games even when you are on an older Mesa build. :wink:

[hotcapy]

@lorn10 Hi! Thank you for letting me know! Sure, I'll test my games as soon as I can with new options. Right now my laptop at service, trying to fix it's overheat issues that I experiencing even without games. It should be ready in few days :)

[hotcapy]

My laptop is ready now, and it's overheating issues are finally fixed. I was able to update Mesa to version "22.3.0_devel.159254.a03ce740bbb-1" thanks to mesa-tkg-git installer.

I tried to run all my games with R600_DEBUG=nir,nosb option. Results are very different from each other :)

"WALL-E" works as great as before Mesa update, maybe even a bit more great.

"Need for Speed: Hot Pursuit 2010" now works and even plays with acceptable performance on Radeon GPU. However, it has serious issues with colors. Textures of pretty everything not at main racing road are white, rocks are green-blue for some reason, but roads and cars are ok. Game seems to be stable, I haven't noticed any crashes during gameplay, but I noticed more important thing: setting shadows level in graphics setting to any value higher then "none" (low, medium or high) leads to crash similar to one which I always had previously before Mesa update (few seconds black screen instead of loading to car select menu when entering race or game world). Setting or not setting nosb option has no visible affect on game and not fixes textures colors & shadow level crash.

"SPORE" sadly not playable anymore, no matter is nosb option used or not: in most cases game starts and loads to game world, but very few minutes after immediately crashes for some reason. It can crash from main menu too (galaxy with planet choiсe screen) if you just wait a little there. Game worked perfect on previous Mesa versions without single crash during pretty long gameplays, even when laptop at overheat. Now seems broken :(

"Divinity II: Developer's Cut" not starts anymore at all, with & without nosb option. Just black screen and no automatic crash, I have to stop game's process manually. Log says that 32-bit gstreamer "base" plugins needed for intro videos might be not installed in my system, which is not true since they are installed. Before Mesa update these intro videos were just skipped when Nine is enabled, and main menu appeared. Now no progress.

Conditions that changed since previous tests were Mesa version AUR mesa-git -> mesa-tkg-git, Wine-GE vesion 7-26 -> 7-27 (which most likely is unrelated since no serious changes were maid in these builds as soon as I know) and thermal paste replace in laptop (which helped a lot with temperatures and shut-downs due to components overheat).

Also some good news: Linux native OpenGL 4.x game "Divinity: Original Sin - Enhanced Edition" works and plays with nir,nosb option. ~45 FPS at start location at minimal graphics settings. However, I didn't test it properly yet, only few minutes of gameplay, so can't say about stability for sure. Before latest Mesa update it also worked with nir option, but previously it crashed my laptop due to overheat even before loading to in-game, at character creation menu.

By the way, most of my apps that are not games are working normally with nir on Radeon GPU, like LibreWolf, Discord, Telegram and many others, but I didn't tried to pass it systemwide yet.

[hotcapy]

"Need for Speed: Hot Pursuit 2010" wrong world colors demonstration.

EDIT: Little update. Mesa 22.3.0_devel.159379.28a69b72d8e-1.

1. "Divinity II: Developer's Cut" behavior is actually the same and intro videos black screen issue appears most likely due to Wine or another system library update. I used old trick with renaming video files in game's folder to circumvent this, and in-game nothing changed: everything is black on Intel GPU and crash on save loading on Radeon GPU. I'm sorry for wrong info in previous post :c
2. "Need for Speed: Hot Pursuit 2010" issue with world's colors exists only for Radeon GPU! On Intel GPU game runs with acceptable performance (but a little bit slower than on Radeon GPU) and with natural game's colors. Changing "Shadows Level" value in graphics settings still results in crash on entering game's world, but on Intel GPU it happens a bit later than on Radeon GPU (on other loading screen). I'm not sure if problem the same in both cases or not.
3. "SPORE" always crashes on both Intel and Radeon GPUs. It can not even start with immediate crash, or start & crash after less then a minute of gameplay. Again, this behavior never took place before, not a single time. Log has this line on Radeon GPU, in case it is related: radeon: mmap failed, errno: 12
4. "WALL-E" just works :)
5. "Divinity: Original Sin" actual FPS seems to be ~30 in the beginning, I hurried up to say about 45.

[lorn10]

Thanks for the additional testing.:+1: Maybe the problem in "SPORE" is Wine related, it looks that Wine 7.16 was quite flawed for several applications. Whatever, Wine 7.17 landed recently and it fixed again different things. Maybe you give it a try. And there was also again a change in the R600 driver, se Mesa MR !18518.

Keep in mind that when you are testing with Gallium Nine, you have to force every game to DirectX 9 mode. So maybe it helps something when you change the "Windows Version" in wine to Windows XP through winecfg. However, this could also stop some other games from working...

[hotcapy]

You are totally right about Wine, thank you! "SPORE" working normal again with 7.17, issue really was related only to Wine update and not Mesa. Regarding latest Mesa update, all my games work (or not work) in the same way as before =) If PCGamingWiki website tells the true, all my games (excluding native OpenGL ones) can use only DirectX 9. It is the reason I chose them for our tests (to work with Nine since DXVK is not an option on my Radeon GPU). But you are right, sometimes I use Windows XP option with 32-bit Wine prefixes for 32-bit only games.