First post, by lowenz
FEAR 1.08 integrated benchmark crashes after the first combat scene @2560x1440.
The game itself suggests that the possible issue is the VRAM (->4096 MB) for that resolution
FEAR 1.08 integrated benchmark crashes after the first combat scene @2560x1440.
The game itself suggests that the possible issue is the VRAM (->4096 MB) for that resolution
Works fine here with the default (256 MB) VRAM setting. Try copying dgVoodoo.conf from the dgVoodoo archive to the game directory to make sure you're using stock settings.
ZellSF wrote on 2021-03-28, 17:34:Works fine here with the default (256 MB) VRAM setting. Try copying dgVoodoo.conf from the dgVoodoo archive to the game directory to make sure you're using stock settings.Clipboard01.jpg
Resolution? Got the problem at the specific resolution of 2560x1440.
That's 2560x1440.
ZellSF wrote on 2021-03-28, 17:34:Works fine here with the default (256 MB) VRAM setting. Try copying dgVoodoo.conf from the dgVoodoo archive to the game directory to make sure you're using stock settings.Clipboard01.jpg
Nope
There's an error in RAM quantity detection, just like in Outbreak.
The same using DXVK 1.8.1
Game freshly installed and manually patched to 1.08.
No issues with MS d3d9.dll
lowenz wrote on 2021-03-28, 00:43:FEAR 1.08 integrated benchmark crashes after the first combat scene @2560x1440.
The game itself suggests that the possible issue is the VRAM (->4096 MB) for that resolution
I confim the crash with the lastest WIP
No crash with DXVK or MS d3d9.dll
lowenz wrote on 2021-03-30, 14:57:Nope […]
ZellSF wrote on 2021-03-28, 17:34:Works fine here with the default (256 MB) VRAM setting. Try copying dgVoodoo.conf from the dgVoodoo archive to the game directory to make sure you're using stock settings.Clipboard01.jpg
Nope
There's an error in RAM quantity detection, just like in Outbreak.
I know, I already reported that, but what I meant was, the benchmark does not crash under dgVoodoo. There's something else that's causing it to crash.
lowenz wrote on 2021-03-30, 15:16:
Known issue with AMD drivers, covered in dgVoodoo's documentation.
Direct3D12 isn't the stock configuration though, and I told you to try that. Copy the stock dgVoodoo.conf to F.E.A.R's directory, ignore the texture errors, run the benchmark and see if it still crashes.
For me FEAR *benchmark* crashes ONLY with dgVoodoo2. No crash with DXVK or MS D3D9.
And it crashes specifically after the first scene. In the same exact point everytime.
Potentially another AMD driver bug, but try with the stock config as already mentioned.
ZellSF wrote on 2021-03-30, 17:28:Potentially another AMD driver bug, but try with the stock config as already mentioned.
But why?
They're plain txt file with the options.
Comparing the 2 files I see the obvious different values and nothing more.
The "default" file is no magic 😐
Copying the stock dgVoodoo.conf to the game folder eliminates a lot of variables. It will also only take a minute, so I don't see why you need to be so difficult about it.
ZellSF wrote on 2021-03-31, 01:54:Copying the stock dgVoodoo.conf to the game folder eliminates a lot of variables. It will also only take a minute, so I don't see why you need to be so difficult about it.
Because it's the same that dgVoodoo2 creates and because I've compared the 2 txt files and the only differences are my chosen values? The problem is still there with 256 MB of RAM.
Crash after the combat scene in the benchmark session. No crash with DXVK or MS D3D9.
lowenz wrote on 2021-03-31, 08:10:ZellSF wrote on 2021-03-31, 01:54:Copying the stock dgVoodoo.conf to the game folder eliminates a lot of variables. It will also only take a minute, so I don't see why you need to be so difficult about it.
Because it's the same that dgVoodoo2 creates and because I've compared the 2 txt files and the only differences are my chosen values?
1) Your chosen values which you haven't said what are, you for example left out that you were running D3D12 initially which could be very important. You say values so I assume there are more discrepancies.
2) Your method of making sure the settings are the same is subject to a lot of human error. Copying the config file is much less so.
3) It takes less time to do it than the time you've spent trying to justify not doing it, and the time you've made me waste repeatedly telling you to do it.
I mean if your ISP tells you to restart your router when you know it's not the problem, do you also put up a pointless fight about it? The only reason they would have put up with that btw, is that you're paying them.
1) Man, there's the RTSS overlay in the screenshot. You obviously can see "D3D12". The "other" values are the VRAM quantity and the Fast Video Memory Access. Of course I've tested with them @default: same crash
2) I'm just using the dgv2 control panel to set the values, there's no "human error" possible
3) "and the time you've made me waste repeatedly telling you to do it" -> 🤣
lowenz wrote on 2021-03-31, 12:39:2) I'm just using the dgv2 control panel to set the values, there's no "human error" possible
You could have easily:
1) Edited the wrong config file by accident (I've done this a lot).
2) Missed a value you didn't know you edited (I've done this a lot).
There's always a potential for human error, I'm asking you to do one simple thing to rule it out.
Also rolling on the floor laughing at anyone ever saying that there's no human error possible.
lowenz wrote on 2021-03-31, 12:39:1) Man, there's the RTSS overlay in the screenshot. You obviously can see "D3D12". The "other" values are the VRAM quantity and the Fast Video Memory Access. Of course I've tested with them @default: same crash
In your initial post, you didn't have the RTSS overlay on. See how fallible humans are?
I have FEAR version 1.8.282.0 and I can't reproduce the crash either. Resolution is set to 2560x1440.
I tested the game through the D3D11/12 SDK debug layer which reported a bug but that only affected forced MSAA case, and I fixed it in WIP79_1.
Tested on both nVidia and Intel UHD.
Also, I found a D3D12 pipeline cache bug but that's D3D12 only, I don't believe those bugs have to do sg to the crash.
So, plz try it again with WIP79_1, and if it still crashes (probably will) then I have no idea (and AMD card).
Also, you can check out the game with the dgV debug layer to see if the crash is caused by a failed resource allocation or sg like that.
It literally runs having hiccups on the star menu too using the debug version!
Yes, it's expected. The more log dumped the more hiccup and lower speed.
You can also use beta version of f.e.a.r. for found more bugs..this version contains alternative performance test
https://onedrive.live.com/?authkey=%21AKvtpxw … t&action=locate
XYC5-GAB2-CAF9-TUD7-5686