https://bugs.winehq.org/show_bug.cgi?id=43277
Bug ID: 43277 Summary: Far Cry 3 requires Multithreaded Wineserver Product: Wine-staging Version: 2.10 Hardware: x86-64 OS: FreeBSD Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: shitman71@hotmail.com CC: erich.e.hoover@wine-staging.com, michael@fds-team.de, sebastian@fds-team.de
This game runs only on one cpu-core, causing it to run very slow and not being able to play. Reducing CPU-Load via(hidden) settings enables partially multithreading to this game, running fast enough to be played. It seems like its the conversions which are made to process graphics are slowing it down, redirecting them to a second cpu-core would enable this game and many other games to run much faster.
With a Ryzen 1700x this game can barely played with the following settings in GamerProfile.xml(set file to read only): <GamerProfile> <SoundProfile MusicEnabled="1" MasterVolume="100" MicEnabled="1" IncomingVoiceEnabled="1" Language="German" /> <RenderProfile MSAALevel="0" AlphaToCoverage="0" SSAOLevel="0" SDSM="0" ResolutionX="2560" ResolutionY="1080" Quality="custom" QualityEditor="editor_ps3" Fullscreen="1" Borderless="0" UseD3D11="1" D3D11MultithreadedRendering="1" WidescreenLetterbox="0" UseWidescreenFOV="1" FOVScaleFactor="0.75" EnableSubResolution="0" SubResolutionX="1280" SubResolutionY="540" VSync="1" RefreshRate="144" DisableMip0Loading="0" GPUMaxBufferedFrames="0" ShowFPS="0" Brightness="1" Contrast="1" GammaRamp="1" AllowAsynchShaderLoading="1" MaxFPS="40"> <CustomQuality> <quality ResolutionX="2560" ResolutionY="1080" EnvironmentQuality="low" AntiPortalQuality="low" PortalQuality="low" PostFxQuality="low" TextureQuality="high" TextureResolutionQuality="low" WaterQuality="low" DepthPassQuality="low" VegetationQuality="low" TerrainQuality="low" GeometryQuality="low" AmbientQuality="low" DeferredAmbientQuality="low" ShadowQuality="low" EditorQuality="" Hdr="0" HdrFP32="0" ReflectionHdr="0" EnableVertexBinding="1" id="custom" /> </CustomQuality> <Environment> <quality RainNumSplashesPerSecond="15" id="low" /> </Environment> <Post> <quality GameDepthOfField="0" CinematicDepthOfField="0" MotionBlur="0" SSAO="0" FXAALevel="0" CloudShadows="0" SSAOMaxDistance="0" id="low" /> </Post> <Water> <quality WaterRefraction="1" OceanShoreEffect="1" ReflectionTextureSizeX="1024" ReflectionTextureSizeY="1024" ProtoDisplacement="1" OceanRealReflection="0" NumWaterReflectionPlanes="4" id="low" /> </Water> <Vegetation> <quality UseRealTreeHD="0" UsePixelLeafNormals="0" id="low" /> </Vegetation> <Terrain> <quality TerrainLodScale="1.4" TerrainDetailViewDistance="0" TerrainDetailBlendViewDistance="0" id="low" /> </Terrain> <Geometry> <quality KillLodScale="1.4" LodScale="1.4" RealTreesLodScale="1.4" RealTreesVistaMinViewDistanceScale="1.4" ClustersLodScale="1.4" TerrainLodScale="1.4" MaxDecalCount="400" MaxDecalCountPerType="50" id="low" /> </Geometry> <Ambient> <quality ShadowMapSize="128" SectorTextureSize="128" id="low" /> </Ambient> <Shadow> <quality ShadowMapSize="8" CascadedShadowMapSize="8" RainShadowMapSize="8" SoftShadows="1" EnablePCSS="0" DisableShadow="1" DisableShadowGeneration="0" DisableShadowGenTerrain="1" SpotsCastShadows="0" id="low" /> </Shadow> <DeferredShadows> <quality EnableDeferredShadows="0" id="pc" /> </DeferredShadows> </RenderProfile> <NetworkProfile VoiceChatEnabled="1" CustomMapMaxUploadRateInBitsOnline="10240000" OnlineEnginePort="9000" OnlineServicePort="9001" FileTransferHostPort="9002" FileTransferClientPort="9003" LanHostBroadcastPort="9004" LanClientBroadcastPort="9005" ScanFreePorts="1" ScanPortRange="1000" ScanPortStart="9000" SessionProvider="" MaxUploadInbpsOnline="10240000"> <Accounts /> </NetworkProfile> <GameProfile /> <ProfileSpecificGameProfile Sensitivity="0.2" Invert_x="0" Invert_y="0" DefaultFlickFireDirection_y="0" UseMouseSmooth="0" Smoothness="0" Smoothness_Ironsight="0.2" HelpCrosshair="1" Gamepad_vibration="0" UseRoadSignHilight="1" UseSubtitles="4" TaggingEnabled="1" WikiUpdatedEnabled="1" CollectibleUpdatedEnabled="1" TutorialUpdatedEnabled="0" ObjectiveReminderEnabled="1" CraftingTipsEnabled="0" DisplayXPEnabled="1" DetectionIndicatorEnabled="1" HitIndicatorEnabled="1" GrenadeIndicatorEnabled="1" UseAmbx="0" UseGamePad="0" GamepadAnswered="0" Autosave="1" Machete="0" IronsightToggleMode="0"> <FireConfig QualitySetting="low" /> </ProfileSpecificGameProfile> <RealTreeProfile Quality="low" /> <EngineProfile> <PhysicConfig QualitySetting="low" /> <QcConfig GatherFPS="1" GatherAICnt="1" GatherDialogs="0" IsQcTester="0" /> <InputConfig /> <ZoneConfig /> </EngineProfile> <UplayProfile LockString="1k0dbwX1rhTh2lZcKcdtH+xURp/WKI9sAryTxfGtclE=" /> </GamerProfile>
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #1 from SF shitman71@hotmail.com --- Created attachment 58615 --> https://bugs.winehq.org/attachment.cgi?id=58615 GamerProfile.xml
https://bugs.winehq.org/show_bug.cgi?id=43277
SF shitman71@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Far Cry 3 requires |Far Cry 3 requires |Multithreaded Wineserver |Multithreaded | |graphics-processing
https://bugs.winehq.org/show_bug.cgi?id=43277
SF shitman71@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Far Cry 3 requires |Far Cry 3 requires |Multithreaded |multithreaded |graphics-processing |graphics-processing
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #2 from Michael Müller michael@fds-team.de --- Did you activate the CSMT option in the winecfg Staging tab to enable multithreaded rendering?
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #3 from SF shitman71@hotmail.com --- Sure, csmt is enabled. This problem has something with too much cpu-load because there are not only cpu-intensive graphic-calculations.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #4 from SF shitman71@hotmail.com --- I must say i dont know for sure if adding multithreading to it by redirecting the graphics-processing to a second processor will speed it much up becaue farcry 3 has large outdoor-areas to render. Besides this there is also alot of other ai-things and processing going on.
What i did and meaned with partial multithreading is i did activate d11-multithreading from within hidden gamesettings, this made the game run faster. Process-view shows farcry 3 is only running at one single core at 100%, activating the D3D11MultithreadedRendering does but a bit of load on all other causes. The maincore is still running at high load but it gives some fps to play it.
I guess redirecting graphics on another core might help with such games.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #5 from SF shitman71@hotmail.com --- *does put a bit of load on all other cores (soory, bad english)
https://bugs.winehq.org/show_bug.cgi?id=43277
SF shitman71@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |-unknown Product|Wine-staging |Wine
https://bugs.winehq.org/show_bug.cgi?id=43277
Paul Bredbury brebs@sent.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brebs@sent.com
--- Comment #6 from Paul Bredbury brebs@sent.com --- The game-specific option "D3D11MultithreadedRendering" improving framerate, is not a bug in Wine. What is Wine supposed to do about it? It is a bug, or an issue, in the game itself.
For a much better framerate, use Nouveau with Gallium Nine, rather than Nvidia's proprietary driver. I have added a note about this, at e.g. https://appdb.winehq.org/objectManager.php?sClass=version&iId=31279
I reckon this bug should be closed as invalid.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #7 from SF shitman71@hotmail.com --- There is nothing invalid about it, the problem is wine is too slow to do the processing on one core.
Adding multithreading to solve it might be too much i realised short after because there is alot you need to count in to avoid processing things that relay on each other.
It might be more usefull to do some tracking onto such games which have a high cpu-load to find out which commands are mostly used to do the comparisoning and transforming into the true unix-command faster. This might be enough and is easyer to do.
Sorry, i might been a bit confusing about whats the problem here.
Activating D3D11MultithreadedRendering was an example to show that farcry3 runs much faster with less load onto a single core.
Wine doesn't need multithreading, it needs some improvements within its conversions. Fitting more to high demanding games like this and this should be possible.
https://bugs.winehq.org/show_bug.cgi?id=43277
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #8 from joaopa jeremielapuree@yahoo.fr --- Still a bug in current wine?
https://bugs.winehq.org/show_bug.cgi?id=43277
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=43277
Berillions berillions@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |berillions@gmail.com
--- Comment #9 from Berillions berillions@gmail.com --- (In reply to joaopa from comment #8)
Still a bug in current wine?
I confirm this bug. With a Ryzen 1600 + AMD Rx560, i have very bad performance.
- With wined3d with or without csmt + DX9 mode, i have between 10-15FPS for graphic settings from Medium to Ultra. I can expect 20FPS with Low graphic settings. On Windows 10 on DX9 mode, i have ~45FPS with Ultra setting.
- With Gallium-nine (DX9), it's the same thing, i have the same bad performance = 10-15FPS. But the goal to Nine is to have ~ the same perf than Windows and with this game, it's not the case.
And even with DXVK without/with D3D11MultithreadedRendering="1", i have very bad perf = 10-15 FPS
I don't expect to have the same performance than on Windows 10 but have this performance with Wine is problematic. There is really an issue.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #10 from Berillions berillions@gmail.com --- I confirm too that only AMD CPUs have this issue. On the DXVK Discord, all users with an Intel CPU have not not these bad performance. Only one other guy with a Ryzen has the same issue than me and SF.
Please wine's dev, take a look in the bug report.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #11 from Berillions berillions@gmail.com --- I add the link to the gallium-nine bug report : https://github.com/iXit/Mesa-3D/issues/313
You will see screenshot and others tests that i did to understand where come from the issue.
https://bugs.winehq.org/show_bug.cgi?id=43277
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OS|FreeBSD |other Summary|Far Cry 3 requires |Far Cry 3 has poor |multithreaded |performance (Ryzen |graphics-processing |CPU-specific issue?) See Also| |https://github.com/iXit/Mes | |a-3D/issues/313
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #12 from Berillions berillions@gmail.com --- Created attachment 61018 --> https://bugs.winehq.org/attachment.cgi?id=61018 WineD3D without workaround
Hello guys,
I can confirm that it's an issue with Ryzen CPU unfortunately. A workaround has been found on the DXVK discord and the solution is to disable the half of all cores.
For me with my Ryzen 1600 and her 12 cpus, i must to disable the 6 last cpus by these commands :
echo 0 > /sys/devices/system/cpu/cpu6/online echo 0 > /sys/devices/system/cpu/cpu7/online echo 0 > /sys/devices/system/cpu/cpu8/online echo 0 > /sys/devices/system/cpu/cpu9/online echo 0 > /sys/devices/system/cpu/cpu10/online echo 0 > /sys/devices/system/cpu/cpu11/online
Now, i attach all screenshots with Wined3d, Gallium-Nine, DXVK with and without the workaround.
The difference is not great with wined3d but with Nine and DXVK, it's very good
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #13 from Berillions berillions@gmail.com --- Created attachment 61019 --> https://bugs.winehq.org/attachment.cgi?id=61019 WineD3D with workaround
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #14 from Berillions berillions@gmail.com --- Created attachment 61020 --> https://bugs.winehq.org/attachment.cgi?id=61020 Gallium-Nine without workaround
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #15 from Berillions berillions@gmail.com --- Created attachment 61021 --> https://bugs.winehq.org/attachment.cgi?id=61021 Gallium-Nine with workaround
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #16 from Berillions berillions@gmail.com --- Created attachment 61022 --> https://bugs.winehq.org/attachment.cgi?id=61022 DXVK without workaround
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #17 from Berillions berillions@gmail.com --- Created attachment 61023 --> https://bugs.winehq.org/attachment.cgi?id=61023 DXVK with workaround
https://bugs.winehq.org/show_bug.cgi?id=43277
Berillions berillions@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |matteo.mystral@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=43277
Berillions berillions@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thunderbird2k@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #18 from Roderick Colenbrander thunderbird2k@gmail.com --- Can you run your game using WINEDEBUG=+process? I'm curious about some of the cpu related calls the game makes. I think you provided a log like this maybe on IRC, but I don't have access to it.
I did a quick audit on the Wine code and there are definitely some missing things, which look a little suspicious, but I don't know if the game uses it.
For example ntdll/nt.c has TODOs in 2 sections dealing with filling out SMT related information in logical_proc_info_add_by_id. This is ultimately used by GetLogicalProcessorInformation/GetLogicalProcessorInformationEx.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #19 from Roderick Colenbrander thunderbird2k@gmail.com --- Created attachment 61027 --> https://bugs.winehq.org/attachment.cgi?id=61027 Win10 log of coreinfo.exe
Added output of https://docs.microsoft.com/en-us/sysinternals/downloads/coreinfo
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #20 from Roderick Colenbrander thunderbird2k@gmail.com --- Created attachment 61028 --> https://bugs.winehq.org/attachment.cgi?id=61028 Output of coreinfo on Wine + Ryzen1800x
There are clearly a bunch of reporting issues in Wine for Ryzen. CPU name is wrong (not that big of a deal performance wise), but the main issue is reporting logical cores as physical cores.
Honestly if we are reporting this wrong on AMD, we are reporting the same wrong information in regards to SMT / hyperthreading on Intel. I suspect Intel to benefit from a proper implementation as well.
My bet is that the core reporting is making the game do pick incorrect pinning. I will work on patches for both issues. Not sure when I can get them ready though. I maybe to provide a really dirty hack just to test the theory.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #21 from Berillions berillions@gmail.com --- (In reply to Roderick Colenbrander from comment #18)
Can you run your game using WINEDEBUG=+process? I'm curious about some of the cpu related calls the game makes. I think you provided a log like this maybe on IRC, but I don't have access to it.
I did a quick audit on the Wine code and there are definitely some missing things, which look a little suspicious, but I don't know if the game uses it.
For example ntdll/nt.c has TODOs in 2 sections dealing with filling out SMT related information in logical_proc_info_add_by_id. This is ultimately used by GetLogicalProcessorInformation/GetLogicalProcessorInformationEx.
You can download the archive here : http://www.mediafire.com/file/4tq4o65do79r02g/server_process.txt.xz
About your hack, i can test it with FC3 if you want. If it works, it will be enough for me while waiting for the official patches.
https://bugs.winehq.org/show_bug.cgi?id=43277
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|matteo.mystral@gmail.com |
--- Comment #22 from Matteo Bruni matteo.mystral@gmail.com --- (In reply to Roderick Colenbrander from comment #20)
My bet is that the core reporting is making the game do pick incorrect pinning.
It's possible, but notice that we supposedly tried a hack to effectively disable SetThreadAffinity() and that made no difference.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #23 from Matteo Bruni matteo.mystral@gmail.com --- Created attachment 61033 --> https://bugs.winehq.org/attachment.cgi?id=61033 +process channel, grepped from the whole log mentioned in comment 21
FTR the log mentioned in comment 21 was made with WINEDEBUG=+process,server. I'm attaching the result of a "grep :process:", for convenience.
From my quick look it seems like the game calls
GetLogicalProcessorInformation() and then SetThreadAffinity() to set "fancy" affinity masks to the various threads. It appears to be making use of all 12 CPU threads in the various masks.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #24 from Berillions berillions@gmail.com --- Created attachment 61034 --> https://bugs.winehq.org/attachment.cgi?id=61034 ntdll info on Windows 10 (winetest_latest.exe)
As requested by Mystral on #wineharckers irc, i attach the ouput log of "ntdll_test.exe info" from my Win10 partition
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #25 from Roderick Colenbrander thunderbird2k@gmail.com --- Created attachment 61037 --> https://bugs.winehq.org/attachment.cgi?id=61037 Hacky test patch
Adding a proof-of-concept patch, which should make at least on Ryzen 5 / 7 the logical / physical cores reported correctly. I need to do a bunch of other improvements to make it a real patch (skip cores in a nicer way, test on intel, ..). The purpose of the patch is just to show if we are searching in the right direction.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #26 from Berillions berillions@gmail.com --- I tried the hack patch. With it, the logical cores are correctly reported :
----- Snip -----
Logical to Physical Processor Map: **---------- Physical Processor 0 (Hyperthreaded) --**-------- Physical Processor 1 (Hyperthreaded) ----**------ Physical Processor 2 (Hyperthreaded) ------**---- Physical Processor 3 (Hyperthreaded) --------**-- Physical Processor 4 (Hyperthreaded) ----------** Physical Processor 5 (Hyperthreaded)
----- Snip -----
Unfortunatly, for the game (FarCry3) there isn't effect. Even with the hack + all cpus enabled, i still have 10-15 FPS instead of 35-40FPS with 6 last cpus disabled.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #27 from Roderick Colenbrander thunderbird2k@gmail.com --- Hm, okay. I forgot one small change for GetLogicalProcessorInformation (the test app uses the Ex version). Try to add the following change on top of the patch: diff --git a/dlls/ntdll/nt.c b/dlls/ntdll/nt.c index 8995c362a9..315a91beee 100644 --- a/dlls/ntdll/nt.c +++ b/dlls/ntdll/nt.c @@ -1318,9 +1318,7 @@ static inline BOOL logical_proc_info_add_by_id(SYSTEM_LOGICAL_PROCESSOR_INFORMAT
(*pdata)[i].Relationship = rel; (*pdata)[i].ProcessorMask = mask; - /* TODO: set processor core flags */ - (*pdata)[i].u.Reserved[0] = 0; - (*pdata)[i].u.Reserved[1] = id; + (*pdata)[i].u.ProcessCore.Flags = 0x1; *len = i+1; }else{ SYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX *dataex;
This makes cores also reported as logical for GetLogicalProcessorInformation. I haven't been able to test or compile this.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #28 from Berillions berillions@gmail.com --- (In reply to Roderick Colenbrander from comment #27)
Hm, okay. I forgot one small change for GetLogicalProcessorInformation (the test app uses the Ex version). Try to add the following change on top of the patch: diff --git a/dlls/ntdll/nt.c b/dlls/ntdll/nt.c index 8995c362a9..315a91beee 100644 --- a/dlls/ntdll/nt.c +++ b/dlls/ntdll/nt.c @@ -1318,9 +1318,7 @@ static inline BOOL logical_proc_info_add_by_id(SYSTEM_LOGICAL_PROCESSOR_INFORMAT
(*pdata)[i].Relationship = rel; (*pdata)[i].ProcessorMask = mask;
/* TODO: set processor core flags */(*pdata)[i].u.Reserved[0] = 0;(*pdata)[i].u.Reserved[1] = id;
(*pdata)[i].u.ProcessCore.Flags = 0x1; *len = i+1;This makes cores also reported as logical for GetLogicalProcessorInformation. I haven't been able to test or compile this.
After trying to find where the crash came from during the compilation, there is a typo error here :
(*pdata)[i].u.ProcessCore.Flags = 0x1; must be to replace by (*pdata)[i].u.ProcessorCore.Flags = 0x1;
And i test it without success. Always bad performance with all my cpus enabled.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #29 from Matteo Bruni matteo.mystral@gmail.com --- (In reply to Berillions from comment #28)
And i test it without success. Always bad performance with all my cpus enabled.
Okay, thanks for all your testing. It again suggests that this is not a Wine bug after all and something else (probably the kernel) is to blame. We should probably try to figure out what's the peculiarity of Far Cry 3's CPU usage that makes it so troublesome for Ryzen. If someone has any other idea how Wine could be implicated in the bug, that would be interesting too.
BTW, we certainly want to fix GetLogicalProcessorInformation[Ex]() anyway.
https://bugs.winehq.org/show_bug.cgi?id=43277
Ivan Kalvachev iive@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |iive@yahoo.com
--- Comment #30 from Ivan Kalvachev iive@yahoo.com --- (In reply to Matteo Bruni from comment #29)
If someone has any other idea how Wine could be implicated in the bug, that would be interesting too.
I'd ask the user to try `taskset` utility and set CPU affinity to the `wineserver` so it is executed on a specific core/cpu_thread. Alternatively `htop` and pressing `a` might be used.
The `wineserver` process is single threaded and used for a number of windows kernel core function. Having it cause lag or delay would slow down all wine controlled threads.
If you look at this https://github.com/iXit/Mesa-3D/issues/313#issuecomment-379089675 benchmark, you can see that `wineserver` is using about 6 times more CPU in the threaded case.
As I've explained in the other thread: In Ryzen, 2 physical cores form a NUMA node that share L2 cache. Moving a process to another node means it looses all cached data. So this would lead to huge increase in CPU usage.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #31 from Berillions berillions@gmail.com --- Created attachment 61054 --> https://bugs.winehq.org/attachment.cgi?id=61054 wineserver set to 2 cpus with htop
(In reply to Ivan Kalvachev from comment #30)
(In reply to Matteo Bruni from comment #29)
If someone has any other idea how Wine could be implicated in the bug, that would be interesting too.
I'd ask the user to try `taskset` utility and set CPU affinity to the `wineserver` so it is executed on a specific core/cpu_thread. Alternatively `htop` and pressing `a` might be used.
The `wineserver` process is single threaded and used for a number of windows kernel core function. Having it cause lag or delay would slow down all wine controlled threads.
If you look at this https://github.com/iXit/Mesa-3D/issues/313#issuecomment-379089675 benchmark, you can see that `wineserver` is using about 6 times more CPU in the threaded case.
As I've explained in the other thread: In Ryzen, 2 physical cores form a NUMA node that share L2 cache. Moving a process to another node means it looses all cached data. So this would lead to huge increase in CPU usage.
Hi Ivan,
I tried your suggestion 5 minutes ago and unfortunatly, it does not work for me. Like you suggested, i used htop to set "wineserver" to a single core and i use the core #6 (cpu #11 & #12) like you can see on the screenshot.
maybe i did something wrong but i did this way : 1- Launch Uplay to create wineserver process 2- Launch htop in a console and set cpu #11/#12 like on the screenshot 3- Launch FarCry 3 from UPlay
Result : Still have the same bad perf (~10-15FPS)
I tried to set "wineserver" on only one cpu (cpu#12) without success too.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #32 from Ivan Kalvachev iive@yahoo.com --- Any new development on this issue?
Few days ago we talked on IRC and we did a bit of experimenting.
I think I found mistake in one of the experiments we did.
It seems that the NUMA nodes, or as AMD calls them CCX are formed by 4 physical cores. (I thought they are 2 previously).
On your processor Ryzen 1600, you have 2x CCX and each one has 3 physical cores (one is disabled).
So the layout looks like this: ccx/node0 { (0,1),(2,3),(4,5) } ccx/node1 { (6,7),(8,9),(10,11) }
Here, (0,1) are cpu's threads that run on same physical core.
So, when you disabled half of the cores, you disabled one whole ccx/node and this avoids the slow interconnect between nodes.
When I asked you to set affinity for wineserver and fc3 on cpu 5 & 7, I thought they would be on the same node, but they are actually on different ones.
Could you repeat the experiment, but this time with cpu3&5 ? Or just set affinity to the first 6 cores on all wine related programs (wineserver and everything that is *.exe).
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #33 from Berillions berillions@gmail.com --- (In reply to Ivan Kalvachev from comment #32)
Any new development on this issue?
Few days ago we talked on IRC and we did a bit of experimenting.
I think I found mistake in one of the experiments we did.
It seems that the NUMA nodes, or as AMD calls them CCX are formed by 4 physical cores. (I thought they are 2 previously).
On your processor Ryzen 1600, you have 2x CCX and each one has 3 physical cores (one is disabled).
So the layout looks like this: ccx/node0 { (0,1),(2,3),(4,5) } ccx/node1 { (6,7),(8,9),(10,11) }
Here, (0,1) are cpu's threads that run on same physical core.
So, when you disabled half of the cores, you disabled one whole ccx/node and this avoids the slow interconnect between nodes.
When I asked you to set affinity for wineserver and fc3 on cpu 5 & 7, I thought they would be on the same node, but they are actually on different ones.
Could you repeat the experiment, but this time with cpu3&5 ? Or just set affinity to the first 6 cores on all wine related programs (wineserver and everything that is *.exe).
The both suggestions don't work.
- I launch the game, once i'm in the main menu, i launch htop in on other console. So i select wineserver + all FC3 threads and i set for them cpu 3&5. Result : 5-10 FPS instead 10-14FPS
- - I launch the game, once i'm in the main menu, i launch htop in on other console. So i select wineserver + all .exe threads (winedevice, fc3 etc...) and i set for them cpu 1 to 6 (htop show cpu to 1 -> 12). Result : 10-14FPS
https://bugs.winehq.org/show_bug.cgi?id=43277
mrdeathjr28@yahoo.es changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mrdeathjr28@yahoo.es
https://bugs.winehq.org/show_bug.cgi?id=43277
zzzzzyzz@hacari.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzzzzyzz@hacari.org
https://bugs.winehq.org/show_bug.cgi?id=43277
Luca lukycrociato@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukycrociato@gmail.com
--- Comment #34 from Luca lukycrociato@gmail.com --- Having the same issue in every Wine game. Even in smaller ones like Half Life 2, there is an input lag caused by just one CPU core being loaded. Even with dxvk, every wine version.
https://bugs.winehq.org/show_bug.cgi?id=43277
Robert Walker bob.mt.wya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #35 from Robert Walker bob.mt.wya@gmail.com --- One of the changes AMD with the change to the Ryzen 2000 series was to harmonise the inter-CCX latency with the internal CCX latency.
This change, and general issue, has been covered very well by PC Perspective, e.g.: https://www.pcper.com/reviews/Processors/Ryzen-7-2700X-and-Ryzen-5-2600X-Rev...
As has been stated AMD have implemented an architecture (Zen), which requires NUMA tweaks to obtain optimum performance.
It would be interesting to know if anyone is experiencing this issue with the second generation Ryzen CPUS (2000) and if it is perhaps measureably less severe?
Also the inter-CCX latency is tied to the Infinity fabric speed, which in turn is tied to the system RAM frequency. So again it would be useful to get some performance metrics from Ryzen systems with higher performance system RAM.
Perhaps it would be instructive for AMD Ryzen owners to plot their own system inter-CCX times?
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #36 from Roderick Colenbrander thunderbird2k@gmail.com --- (In reply to Luca from comment #34)
Having the same issue in every Wine game. Even in smaller ones like Half Life 2, there is an input lag caused by just one CPU core being loaded. Even with dxvk, every wine version.
Ignore old games like HL2, which don't really use multiple threads.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #37 from Roderick Colenbrander thunderbird2k@gmail.com --- (In reply to Robert Walker from comment #35)
One of the changes AMD with the change to the Ryzen 2000 series was to harmonise the inter-CCX latency with the internal CCX latency.
This change, and general issue, has been covered very well by PC Perspective, e.g.: https://www.pcper.com/reviews/Processors/Ryzen-7-2700X-and-Ryzen-5-2600X- Review-Zen-Matures
As has been stated AMD have implemented an architecture (Zen), which requires NUMA tweaks to obtain optimum performance.
It would be interesting to know if anyone is experiencing this issue with the second generation Ryzen CPUS (2000) and if it is perhaps measureably less severe?
Also the inter-CCX latency is tied to the Infinity fabric speed, which in turn is tied to the system RAM frequency. So again it would be useful to get some performance metrics from Ryzen systems with higher performance system RAM.
Perhaps it would be instructive for AMD Ryzen owners to plot their own system inter-CCX times?
At this stage it is best to find more games which are truly affected by this issue and on which performance can be fixed using CPU pinning tricks.
My feeling the issue if you can call it one, is a Linux kernel problem though we need more evidence. I suspect the Windows kernel may have received more consumer application tweaking. AMD worked with Microsoft extensively (in the beginning it didn't report SMT correctly, cache sizes, but they also did many tweaks). Depending on how implemented some of these tunings may even be considered 'hacks'. Again first we need to gain more evidence on which applications are affected and find some patterns.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #38 from Roderick Colenbrander thunderbird2k@gmail.com --- Looking at it a little more, it is probably a game issue and it not handling Ryzen well. The reason is I see similar reports on Windows forums:
"use the task manager to set high priority, use only once ccx and no smt (physical cores only) and make sure your memory is OC'd - using these tricks you can get an additional +30 fps in this game."
https://www.techpowerup.com/forums/threads/far-cry-3-fps-hovers-around-20-50...
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #39 from joaopa jeremielapuree@yahoo.fr --- So, can an administrator mark this bug as INVALID?
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #40 from Luca lukycrociato@gmail.com --- Wait please. I don't think so, while FarCry is indeed a poor optimized game, there is definitely an issue on Ryzen CPU's and games being run through wine. I own a Ryzen 5 1600, 6 cores and 12 threads. On my laptop which uses an Intel CPU I don't have problems running wine games on it, they don't have any sort of issue, but not on this desktop, I experience a lot of stuttering and inconsistency between high framerates especially with the mouse, not definitely a libinput issue. I've disabled every sort of mouse acceleration.
I've discussed a lot on dxvk discord, and after trying ryzen-optimized kernel and some custom wine esync version which reduced a bit the problem, i got to the conclusion that there is some sort of CPU scheduling issue.
Basically every game I've tried, from Half-Life 2, to Killing floor 2 or GTA 5 have the same laggish input issue while having good and stable framerates, while having opened cpu monitoring software there are indeed cpu usage spikes where a single core is at 100%, an image explains it better.
In those screenshots you can see the same game (Half life 2) running in the same section of the map, same mouse movements, in the same version of wine, same linux distro, just different CPU and video card, a lot weaker than my desktop. I've also tried different mouses, kernels, drivers, wine versions, etc. Absolutely the same result.
https://imgur.com/a/bouDlbO The one with the balanced CPU usage is the laptop, the one with 100% CPU spikes on it is the desktop. But basically every game I run on it, new or older, DX11 or DX9, the same 100% cpu spikes occurs.
I've also made a video, as you can see as I'm approaching the beige house behind me the visual becames sluggish and stutters a lot, while not dropping game fps, but the mouse movement were the same, you can see that when I reach the other end of the house, the visual gains some speed. I can ensure that the mouse movement I was doing was absolutely linear.
So I came to the conclusion that there can be some sort of CPU scheduling issue, not related, I think, to the linux kernel, because any other game runs fine.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #41 from Luca lukycrociato@gmail.com --- And I repeat, this issue occurs just in wine games, the CPU usage on native steam games is regular.
I meant a wine CPU scheduler issue.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #42 from Roderick Colenbrander thunderbird2k@gmail.com --- (In reply to Luca from comment #41)
And I repeat, this issue occurs just in wine games, the CPU usage on native steam games is regular.
I meant a wine CPU scheduler issue.
I understand you are encounter performance issues (I'm a Ryzen user myself). However to me so far it looks like it are game issues, which are making poor choices for the cores they pin to (at least in Far Cry 3).
For your understanding, there is no CPU scheduler in Wine. Wine provides the same APIs on Windows allowing applications to determine detailed CPU information. Then we provide the Windows APIs applications can use to set 'affinity' (pinning threads to a particular core). This directly maps to standard pthread affinity API calls. In other words Wine exposes CPU information directly to the application, which can (if it chooses so) tell the Linux kernel how to map threads to cores. If an application doesn't do anything special, the Linux kernel will schedule the application in whatever way it thinks is best.
The fundamental issue is just that the application 'somehow' ends up using less optimal cores. I mean with less optimal is that the cores can be on other CCXes and if there is a lot of communication between the different CCXes this can affect performance. This is just how the Ryzen design works.
The cores are either picked by the application if it does core enumeration and setting affinity and in which case Wine is just a passthrough layer. If the game doesn't set affinity the Linux kernel will just pick based on what it thinks is best (e.g. CPU load, choice of Linux scheduler,..).
So far I'm more leaning towards unaware applications making poor CPU core choices.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #43 from Luca lukycrociato@gmail.com --- Okay maybe not a cpu scheduler issues but there is definitely a problem which no one understands, I've tried the exact amount of games on another computer with the same distro, wine version and settings, and that problem does not even occur.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #44 from Roderick Colenbrander thunderbird2k@gmail.com --- (In reply to Luca from comment #43)
Okay maybe not a cpu scheduler issues but there is definitely a problem which no one understands, I've tried the exact amount of games on another computer with the same distro, wine version and settings, and that problem does not even occur.
The same games should be tested on the same system on Windows.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #45 from Luca lukycrociato@gmail.com --- (In reply to Roderick Colenbrander from comment #44)
(In reply to Luca from comment #43)
Okay maybe not a cpu scheduler issues but there is definitely a problem which no one understands, I've tried the exact amount of games on another computer with the same distro, wine version and settings, and that problem does not even occur.
The same games should be tested on the same system on Windows.
https://www.youtube.com/watch?v=GBhXnfTbtaI&feature=youtu.be
Here you go, I made a video including all version I've tried on the same machine.
I understand it is a bit hard watching a video, but I can ensure that I'm really experiencing that issue, it is accelerating/decelerating only in wine games.
That is a particular example, half life 2, but I've seen it in other wine games as well.
Anyway, trying the Tk kernel, which uses a PBS scheduler, the cpu usage is greatly improved but the issue still remains.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #46 from Henri Verbeet hverbeet@gmail.com --- (In reply to Robert Walker from comment #35)
It would be interesting to know if anyone is experiencing this issue with the second generation Ryzen CPUS (2000) and if it is perhaps measureably less severe?
Anecdotally, I'm told the issue happens on second generation Ryzen as well. I haven't verified that myself.
https://bugs.winehq.org/show_bug.cgi?id=43277
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |florian.richer@protonmail.c | |om
--- Comment #47 from Matteo Bruni matteo.mystral@gmail.com --- *** Bug 47744 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #48 from Hans Leidekker hans@meelstraat.net --- Created attachment 65276 --> https://bugs.winehq.org/attachment.cgi?id=65276 hack
Here's a hack that allows you to restrict Wine processes to a subset of the available cores. You can pass a CPU mask through the WINECPUMASK environment variable:
$ WINECPUMASK=0xff wine ...
This will tie Wine processes (including wineserver) to the first 8 cores. It will also limit the number of reported cores to 8.
To get a performance gain on Ryzen the mask should specify the cores of one core complex (CCX). Here's little bash script that computes the mask for the first CCX:
#!bin/bash cat /proc/cpuinfo | grep "^model name" | grep "AMD Ryzen" >/dev/null 2>&1
if [ $? -eq 0 ]; then NUM_CPUS=$(cat /proc/cpuinfo | grep ^processor | wc -l) echo "found $NUM_CPUS AMD Ryzen cores"
CCX_MASK=$(((1 << $NUM_CPUS / 2) - 1)) echo -n "first CCX mask: " printf "0x%x\n" $CCX_MASK fi
With this patch The Forest goes from 23 to 40 fps on a 16 core Ryzen CPU. It would be interesting to see if this also makes difference for the games mentioned here and in duplicate reports.
https://bugs.winehq.org/show_bug.cgi?id=43277
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=43277
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
--- Comment #49 from Paul Gofman gofmanp@gmail.com --- Created attachment 65277 --> https://bugs.winehq.org/attachment.cgi?id=65277 test
Does this patch improve anything by any chance?
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #50 from Austin English austinenglish@gmail.com --- (In reply to Hans Leidekker from comment #48)
Created attachment 65276 [details] hack
Here's a hack that allows you to restrict Wine processes to a subset of the available cores. You can pass a CPU mask through the WINECPUMASK environment variable:
$ WINECPUMASK=0xff wine ...
This will tie Wine processes (including wineserver) to the first 8 cores. It will also limit the number of reported cores to 8.
Wouldn't taskset/cpuset be simpler?
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #51 from Hans Leidekker hans@meelstraat.net --- (In reply to Austin English from comment #50)
(In reply to Hans Leidekker from comment #48)
Created attachment 65276 [details] hack
Here's a hack that allows you to restrict Wine processes to a subset of the available cores. You can pass a CPU mask through the WINECPUMASK environment variable:
$ WINECPUMASK=0xff wine ...
This will tie Wine processes (including wineserver) to the first 8 cores. It will also limit the number of reported cores to 8.
Wouldn't taskset/cpuset be simpler?
They will allow you to set process affinity just the same, but they don't limit the number of cores reported to Windows apps.
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #52 from mrdeathjr28@yahoo.es --- Maybe can try dxvk for dx11 or d9vk for dx9 mode both are non supported by wine but have much better performance (around 2x performance with around 50% less cpu usage) than dx11/dx9 wine implementation
https://bugs.winehq.org/show_bug.cgi?id=43277
Anya animegirl@stronzi.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |animegirl@stronzi.org
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #53 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur with wine-6.4?
https://bugs.winehq.org/show_bug.cgi?id=43277
Neko-san nekoNexus@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nekoNexus@protonmail.ch
https://bugs.winehq.org/show_bug.cgi?id=43277
--- Comment #54 from Chebanenko Igor chebanenkoigor93@gmail.com --- Wine 8.21 was released. Please,retest.
https://bugs.winehq.org/show_bug.cgi?id=43277
soredake broaden_acid002@simplelogin.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|broaden_acid002@simplelogin | |.com |
-
wine-bugs＠winehq.org -
WineHQ Bugzilla