-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TES IV: Oblivion and Fallout: NV terrible performance #27
Comments
I played Fallout NV completly on gallium nine two years ago, and there was no perf issue. Not sure what could cause this potential regression. Could you post a screenshot of your config panel to replicate exactly ? any mod ? |
I had everything set to max, 1920x1080, no mods. I will send you the config panel once I am home. |
Yes this is what I wanted. If I cannot reproduce, I'll ask you to give me a screenshot in game with the GALLIUM_HUD set to handpicked statistics. |
I cannot reproduce. That sounds like a cpu overhead issue which I don't have (Intel vs AMD) ? Recompiling 32bits mesa with -march=native may help (not easy with meson and 32bits builds), I can give example. |
I actually used the version installed with protontricks. I will try using the Arch package today and later compile it with march=native or in some other ways. It is weird though, because I never saw any of the cores' utilization more than 40%. Maybe it's cache misses or something. And even weirder, wined3d works better. |
I suggest -march=native for the mesa package. I used the wine archlinux package, that may affect the result. |
To compile with -march=native in 32bits build, you need to replace the cross-file. with fast.native: [properties] [host_machine] |
Alright, thanks, will do once I have the time. |
Yeah, I think I saw pretty much the same thing (but can't confirm right now), CPU load going down and also GPU load going down. What is your setup (hardware)? |
my understanding is some recent amd cpus don't share well cached data, and if you share between a thread and another that are on different core groups you suffer bad perf. Is there any way you could force all the app threads to be for example on the 4 first cores ? |
I personally have the older FX-6300, which is a weird thing anyways. The FX architecture has 2 cores sharing the floating point unit. It was supposed to be a 6-core CPU in my case, but is 6 core only for some loads, for floating point loads it's 3 core. I don't know how the cache is distributed, but as I said, I will try march=native and maybe also try to limit the thing to just 2 cores, or something idk... |
I have Ryzen 7 1700 and RX 580. With nine, I can play Mass Effects, S.T.A.L.K.E.R. Anomaly in 4k at 60 FPS, but for some reason FO NV runs poorly. @axeldavy |
I just notice the trend that similar reports have Amd as well. Any idea ?
Le jeu. 18 avr. 2019 à 09:27, neVERberleRfellerER <notifications@github.com>
a écrit :
… I have Ryzen 7 1700 and RX 580. With nine, I can play Mass Effects,
S.T.A.L.K.E.R. Anomaly in 4k at 60 FPS, but for some reason FO NV runs
poorly.
@axeldavy <https://github.com/axeldavy>
taskset -p 0,1,2,3 $fonv_pid
output: mask ffff, affinity 123
If this is correct, it does not change anything.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#27 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AATNXMLFAGRKYRCYX6HVRF3PRAPFNANCNFSM4HGJ6LCQ>
.
|
I don't have an AMD cpu, but I do get similar effects with vsync on other games. |
thread_submit=true helps in S.T.A.L.K.E.R. and Mass Effect 1 (otherwise FPS go to 30 and GPU load goes to like 10%), but does not do anything in FO NV since FreeSync became supported. It helped before FreeSync, but FPS in Strip were same as they are now. |
There was not difference after building with I built the lib32-mesa package with the Arch Build System. I set Should I have built it in a different way? This was essentially the easiest way, I think, but I can try your way. I also tried it with my custom compiled wine + wine-nine from the Arch packages, same result. I just don't get it. Other games work fine, but the games using this engine are just terrible. |
I don't know whether what you did was good or not for that purpose. Could you take a screenshot in game with the hud: have you tried also if thread_submit=true and tearfree_discard=true changed fps at all. |
One way to take such a screenshot is to use a tool like spectacle with which you can set a counter (for example 1 minutes) |
@axeldavy Gallium HUD with your parameters shows, that it's indeed CPU bottlenecked. That's unfortunate. |
That is ... surprising. |
If sure the game is using nine, I would suggest to try the native d3dx9_* libs (install with winetricks). |
I had a very little time in this morning, but still did this: I get a completely different story, more in line with what you said, @axeldavy. Except the fps is not where it should be. Didn't have time to test much else right now. This was on Proton 4.2-3, 100% sure Gallium is loading, saw the "Native Direct3D 9" message in steam output. After setting the CPU governor to performance, it was smooth when looking at some sceneries, but not when looking at something else. It's not even looking at a wall or something. Look at this screenshoot bellow. When I was looking this way, I had poor performance, but just a few seconds ago, I was looking 10° to the left and it was almost smooth 60fps. There isn't even that much of a difference between these two sceneries in terms of rendering (at least I think): Very late, I noticed your variables didn't include all 6 cores (for my case), so I added them: The biggest hit is felt when moving the mouse around, but the poor performance is evident also when stationary looking at some specific angles and at some angles it's pure 60fps. I will need a little clarification about EDIT: Just tried de-activating Gallium 9 with this HUD active. I can confirm it's way different now. I don't get a constant 60 fps, but it also never goes bellow 45. Unfortunately, I don't have a FreeSync monitor, so this is not acceptable. And the cores are all over the place now, way more active, up to 90%. Did this just to make sure Gallium Nine really was active. Should I also try setting those d3dx9_* libs to native? |
thanks for the testing. In my testing, I found the overhead of gallium nine is very low in this game (you get max 2% if having all draw calls do nothing, or removing the global mutex - which gave a few artifacts -). Maybe somehow the clock of your cpu remains rather low for some reasons ? You can try assign the game to 2, 3 or 4 cores see if the increased use of these cores help, or anything else you have in mind. You can also try with the d3dx9_ libs |
@axeldavy Game loads just d3dx9_38 and using native one does not change anything. thread_submit=true and tearfree_discard=true (and false) also don't seem to change anything.
Yes, even very small mouse movements cause FPS drops for me. For example looking at center of Prospector Saloon at Goodsprings from the road and then looking halfway towards one of its sides sometimes cause even 20 FPS drop. |
If the issue is with the mouse, I'd suggest to try force software cursor. It's easier to rebuild the wine-nine-standalone. The mesa lib will revert to software cursor. edit: as the game may expect some events due to hardware cursor, this is not guaranteed to work. |
That sounds familiar. I've seen a WINE patch about that recently, something about high dpi mouse. Can you lower the resolution of your mouse (my zowie has a button for that at the bottom)? |
@dhewg That didn't help. Update: okay, below is what @cyro666 already said in
But I have something interesting. So far I though that looking at "nothing" always results in 60 FPS. Well, it's actually not the case. There is particular spot on ground in Goodspring that causes massive FPS drop and just by looking a little in any direction and basically still seeing the same scene (e.g. moving mark on ground by 1 cm) returns FPS back to 60 (from 35). Also, looking at sky in Goodsprings causes FPS to vary between 40 and 60, but it's stable 60 for sky in The Strip. |
Yes indeed, the problem is also there when doing nothing. And yes, indeed, looking at the same scene from a just a tiny different degree/angle sometimes gives 60 fps. I will check my CPU clock, but I think I remember doing that once to test the performance CPU governor in Rise of the Tomb Raider and all the cores were constantly at 3.5GHz. Now that I think of it, there is a distinct possibility, but rather small that the load here is too small and the CPU just isn't boosting. But it should be in my experience when using the performance CPU governor. Will check this when I have time. |
Breakthrough! Setting So that helped a lot, but it's not completely perfect. I tried limiting the cores, but that made it worse in the case of only 2 cores (one started hitting 100%) and about 2-3 fps worse when setting only 4 cores. EDIT: I also monitored the clocks of the cores and they were all definitely boosting. In no case ever was there CPU utilization bigger than 50% EDIT 2: To make it clear, in NV I had to actually put an effort to find a camera position where the fps dropped, it was at 60fps almost all the time. In Oblivion, the drops were a lot more noticable, though. It is definitely better than before, but I wouldn't call it completely playable for modern standards. |
To analyze what is going on with high dps mouse, it would help if you report on the impact of using software cursor (see my message about it). |
It makes no difference. I guess that FPS drops are caused by changes in viewing angle (as said earlier - even looking at ground and changing the angle slightly sometimes makes over 20 FPS differences and these remain until angle is changed again). |
It could be the case that the problems @neVERberleRfellerER is facing are different than mine. We established he is getting bottlenecked on one core for some reason, but the load in my case is evenly spread, never even going over 60% on any of the cores (far from that it seems). I will try experimenting with software cursor anyways. |
Also, I experimented with one more thing yesterday. I found I still had an old drive with Windows 10 for this machine. I ran NV and Oblivion to see the difference and it was an absolutely stable 60fps 100% of the time, sooo... Yeah. |
My problem is probably not caused by nine. D9VK shows similar performance characteristics (overally, it gives me 5 more FPS, but game crashes during firefights). It also suffers from FPS drops when looking at specific angles so CPU is being exhausted by something else. This goes in line with observation, that lowering reoslution, details, disabling shadows and so on does not improve performance. |
I also tried D9VK, had slightly worse performance. The CPU cores were utilized a bit more, but not as much as with wined3d To add to this, I cannot even confirm this is a regression. Could've been this way forever. In all honesty I don't remember playing NV or Oblivion on Linux ever before. The only reason I tried was because I bought this new graphics card and thought this machine should be easily capable of this. Also tried compiling a wine version with pba patches to maybe see a better wined3d performance. Unfortunately, pba needs wine 3.19 and earlier. And they can't run NV for me, I get a crash with a stack overflow on wined3d. This could take some time since compiling wine and trying out different versions takes considerable time, but I don't intend on giving up soon. |
There are performance tools (perf, operf, etc) which can estimate where app spents time. I would suggest look at these tools to investigate. |
Given capture done wine
then
for nine says
Does this mean, that Ryzen 1700 is not enough for this game? for d9vk says
for wined3d it says
Performance with nine and wined3d during profiling was same as without profiling, but with d9vk FPS dropped to 0-1. Out of curiosity I ran perf on Gothic 2 too and it's quite interesting:
The amount of time spent in radeonsi_dri seems to little too much to me. But profile is very different from Fallout New Vegas, so it's probably unrelated and wined3d just sucks for Gothic 2. |
I get the following with nine (forcing vsync off with vbank_mode=0, the game didn't seem to care I had vsync off in its config menu).
No idea what swapper is. Probably is part of the main exe as well as the perf-21904.map. I had about 100fps on average. |
Just in case... Did you try vblank_mode=0 ? |
Yes. I can get 67 FPS if I go to corner in opposite direction of what is visible in previous screenshot. It makes no difference in any other way. |
Did you also use native quartz dll ? I had to set it to have the game run, but maybe you use the integrated one and somehow it hits perf. |
Yes. From dsound, I have native From dx I have native |
Ok. Currently I was running with only quartz native for FalloutNV, but I guess the other dlls cannot hurt. I don't know what happens that makes it slow for your cpu... if you have any other ideas of things to test, say it. |
After setting everything to builtin and using only native quartz I see no difference, so extra dlls indeed didn't hurt. Update
From the rest, 200 MB are heap operations. 100 MB are various
and friends. 150 MB are GetLastError. 200 MB of memsets. 120 MB of VirtualAlloc. 40 MB of sleep. 30 MB of semaphore work. Thats all interesting. |
On my side, I decided to see just how much difference there is between Windows and Linux, so I plugged that disk with a Win installation in again. I turned off v-sync in both Linux and Windows. There was no difference in Linux in the problematic regions. However, on Windows, I was surprised. The game ran barely over 60fps and dipped down to 55 sometimes. Only inside it went to 80fps, but even that was rare. After that, I decided to do an Oblivion benchmark as well and... It had the same problems as on Linux, dips down to 40 fps in problematic areas. For the last benchmark, I went to the big boat scene in Dark Messiah of Might and Magic, because it was problematic in Linux as well. Lo and behold... 45 fps. At this point I feel like I must apologize for making you all wonder what's wrong. Windows does have a bit better performance, but not by much, it seems. I monitored the CPU utilization in Windows and 3 cores were usually around 50% while the other 3 were more like 30%. It seems like there's a problem with this engine's CPU utilization on the FX line of AMD processors. I'm not a computer scientist, but I am a soon to be electronics engineer. And to me this looks like there are massive cache misses with the way this engine runs on my processor. Unfortunately, I can't really overclock my RAM, the computer doesn't boot when setting the RAM clock any higher. Again, I apologize, I just thought this computer should've easily been capable of this since I played the most modern titles at 60fps without a problem. It seems older games were really bad at utilizing more cores. As for you problem, @neVERberleRfellerER, I hope you find a solution. The Ryzen line should be capable of this. My CPU is way shittier than yours. Maybe try overclocking your RAM? I heard the Ryzen processors are sensitive to RAM speeds. My brother also had better system speed and stability with a Ryzen after recently updating the BIOS/EFI/whatever. |
Also, to anyone wondering how I fixed the performance issues:
This gives me a constant 60fps. I have not tried the Strip area though, because I don't really have a save with that area. Same thing goes for Oblivion, the lower view distances helped the most. Everything else can be set to maximum detail. |
In my case no matter the distance, or quality or anything, I still get the same performance. This could be because my FONV is modded and mods could place more things or something and it is enough to "bottleneck the engine". Increasing memory clock from 2400 MHz to 2933 MHz didn't seem to help in noticeable way. |
@neVERberleRfellerER: Did you try Proton's esync ? I think it's supposed to reduce the cost of these barries. |
@axeldavy Esync does not help here, because InterlockedIncrement/Decrement are just 5 instructions and these are same with and without esync. |
Why would InterlockedIncrement and InterlockedDecrement be slow ? We use similar atomic instruction in gallium for object refcounting all the time. D3d9 is a C++ api which uses a refcount system for everything. |
@axeldavy I see. Then I am wrong and game is slow for different reasons, but I don't have any idea what these reasons might be. |
Yeah, I guess we can close this if nobody has any more ideas. My issues are "fixed" anyways. |
For those with 30 fps problem, could you try: |
|
I get better performance in these games with wined3d compared to Gallium Nine. I ran it in Proton 4.2-2. To fix the issue, I tried:
PROTON_FORCE_LARGE_ADDRESS_AWARE=1 PROTON_NO_D3D11=1 PROTON_NO_D3D10=1 PROTON_NO_ESYNC=1
None of these made a difference whatsoever. All this time, I monitored the performance.
htop
said max 40% utilization on one CPU core, rest of them were more like 15%.radeontop
said max 15-20% graphics pipe utilization. So these are not a bottleneck.I had the graphics set to maximum in both games. It is fair to note these games have pretty much the same engine (as with the rest of Bethesda games). I remember having these issues months ago with wine as well (that time I used the package that had gallium nine bundled in Arch Linux). Indoors it runs fine, but when it has to display a lot of things (outside), the performance just drops to about 15-20 fps and fluctuates back to 60 when looking at a wall or somewhere with fewer things to render.
Config:
AMD FX-6300
AMD RX 590
16GB RAM
Arch Linux, all packages updated
The text was updated successfully, but these errors were encountered: