Closed LingMan closed 4 years ago
Does it still take 3 minutes if you relaunch ? It's possible it's shaders getting compiled, and the second time they are in cache.
That was my first thought as well. But no, it's the same on every launch.
Does it become fullscreen before or faster the 3 minutes ? Is cpu working ?
Well, once I hit play in the launcher there's a "shake" on the entire screen. From the looks of it, the window appears but is painted with what was behind it at the time. The same happens when starting Qt applications sometimes.
If that counts as "becomming fullscreen", then it goes fullscreen immediately. All four cores of my CPU are maxed until the character selection screen appears.
It compiles tons of shaders at start. With radeonsi's shaders cache it's faster on the next launch, like a few seconds. Is it possible to debug the shader cache and see hits/misses?
sorry to ask this here: but how do i enable this Gallium3D? i'm trying to play GW2 with nouveau but i'm getting only 3 fps and the image looks like software rendering.
im on manjaro cinnamon with wine-staging-nine (insalled from manjaro softwares) i'm not use to arch distros (or linux in general) but i wanted to give it a try to this nouveau/nine/mesa idea.
glxinfo | grep OpenGL OpenGL vendor string: nouveau OpenGL renderer string: NV124 OpenGL core profile version string: 4.3 (Core Profile) Mesa 18.3.4 OpenGL core profile shading language version string: 4.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 4.3 (Compatibility Profile) Mesa 18.3.4 OpenGL shading language version string: 4.30 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.3.4 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 OpenGL ES profile extensions:
i keep trying google but i can't find anything ive tried LIBGL_ALWAYS_SOFTWARE=1 but its even worse than before. $ LIBGL_ALWAYS_SOFTWARE=1 glxinfo | grep OpenGL OpenGL vendor string: VMware, Inc. OpenGL renderer string: llvmpipe (LLVM 7.0, 128 bits) OpenGL core profile version string: 3.3 (Core Profile) Mesa 18.3.4 OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.1 Mesa 18.3.4 OpenGL shading language version string: 1.40 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.0 Mesa 18.3.4 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00 OpenGL ES profile extensions:
@logan001 Please, in the future, don't post new bug or problem that are unrelated with the original bug (even if it's about the same game). Open new ones.
LIBGL_ALWAYS_SOFTWARE=1 means you want to run only using a software driver (on CPU).
You seem to have a Maxwell GPU [NV124 (GM204) chipset | GeForce GTX (970, 980)], which is under the NV110 family. According to Nouveau's feature matrix, engine and memory reclocking are still TODO. In other words, you are running with a low power state and you can't change it. https://nouveau.freedesktop.org/wiki/PowerManagement/
This should be fixed with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4993
Fixed in mesa, will be part of v20.2
When starting Guild Wars 2 with Nine enabled, it takes about two minutes from hitting "Play" in the launcher until the character selection screen is loaded. Using wined3d instead, this takes only about 10 seconds.
Once the game has started, the performance is as expected. FPS are decent and loading maps takes the normal amount of time.
Tested with: OS: Manjaro System Wine 4.2 and tkg-wine4.3 from Lutris AMD Radeon R9 390 Kernel 4.18 amdgpu Mesa 18.3.4 LLVM 7.0.1
Note that the GW2 base game is free to play, so you could try to reproduce the bug yourself if the 40GiB download is no problem for you. Otherwise let me know which other logs might be useful.
nine-gw2-start-hang.log