Closed nonchip closed 5 years ago
Can you bisect the issue? There were more changes than just stream output between 0.81 and 0.90, and I'm not sure if the game even uses it..
maybe we could get a d3d11.fakeStreamOutUnsupported setting to DISable stream output
No, that's not an option. This is a core API feature, having an option to disable it doesn't make sense.
Can you bisect the issue? There were more changes than just stream output between 0.81 and 0.90, and I'm not sure if the game even uses it..
frankly I have no idea how to do that :P
This is a core API feature, having an option to disable it doesn't make sense.
well there is an option to fake enabling it, as well as faking having a different GPU or VRAM amount, or even disabling whole API levels and messing with other core API features such as tesselation or anisotropy...
and the options documented in the wiki don't really seem to have been picked on the basis of making much sense (see faking to enable stream output even though it's unsupported by the hardware; how's that different than faking to disable it even though it's supported?) but providing game specific compatibility.
@nonchip
frankly I have no idea how to do that :P
Well then look it up... https://git-scm.com/docs/git-bisect
Whenever you notice a regression in any git project, performing a bisect should be your first course of action.
will look into doing that tomorrow, gotta set up the toolchain first and it's getting late here. i'll report back here when i got some results.
EDIT: currently I'm struggling to setup mingw, which resists compiling (configure: error: Please check if the mingw-w64 header set and the build/host option are set properly.
when I do exactly what the docs tell me to) and doesn't seem to be available in binary form in the right version (according to https://mingw-w64.org/doku.php/download) for any distro to alien
the package from.
I did a binary search bisect. It seems the use of the new presenter for D3D11 in b53f666 results in the freezes
dxvk v0.81-18-g 8172d34 Revert "[d3d10] Implement ID3D10Multithread" working
dxvk v0.81-49-g 495716d [d3d10] Support pOffsets parameter in SOGetTargets working
dxvk v0.90-0 working
dxvk v0.90-15-g 8cb4852 [d3d11] Add new D3D11 swap chain code working
dxvk v0.90-16-g 64185d9 [d3d11] Move some DXGI presenter options to D3D11 Merkur - Odin - Grineer working
dxvk v0.90-17-g 967b276 [d3d11] Add COM interface for API-agnostic presenter working
dxvk v0.90-18-g b53f666 [dxgi] Use new presenter for D3D11 freeze
dxvk v0.90-21-g 83b51a6 [dxgi] Don't build shaders for presentation freeze
dxvk v0.90-26-g 941db96 [dxvk] Remove obsolete DxvkShaderKey constructor freeze
dxvk v0.91-0 freeze
Thanks for bisecting this. Unfortunately this means that I won't be able to fix this unless I find a way to reproduce it or a similar issue locally, reverting to the old presenter is obviously not an option and I haven't had any issues with the new one so far.
By the way, can anyone post the DXGI log file using latest DXVK? Maybe it's trying to use some awkward swap chain parameters. If not, there's nothing I can do.
By the way, can anyone post the DXGI log file using latest DXVK?
@doitsujin that I can do (still struggling with mingw, sorry :/)
this one is from 0.93: Warframe.x64_dxgi.log
also d3d11 log in case that helps: Warframe.x64_d3d11.log
those just seem to contain way more general info about the renderer setup and less runtime log, if there's any environment var you'd like me to set for that and run for a while to log it crashing please tell :)
reverting to the old presenter is obviously not an option
agreed, but:
and I haven't had any issues with the new one so far.
maybe this will be the first one then ;)
so yeah if there's anything else I can do to help resolve this please tell me, DXVK is doing wonders with this game (as with pretty much all of them :P) and I'd love to be able to use those neat features and performance boosts instead of being stuck on an old version :D
maybe this will be the first one then ;)
I can't reproduce this in any game, that's my problem.
Anyway, the 0.93 logs don't help, latest master uses a different swap chain implementation which prints more log messages. Here's a build if you need it. dxvk-master.tar.gz
logs with the current master
Warframe.x64_d3d11.log Warframe.x64_dxgi.log
edit: played one map until frozen in game
Hmm, interesting. I don't see anything overly suspicious there, but I do wonder why the game keeps switching between vsync on and off. Can you test if enabling it in game changes anything?
with vsync on I got a freeze while loading the game (before login), second time I got into the game :thinking: probably just coincidence. Log of the first run with vsync on: vsync_on_Warframe.x64_d3d11.log vsync_on_Warframe.x64_dxgi.log
vsync off, with max frames 60Hz. I was able to play a map and finish it without a freeze vsync_off_60Hz_Warframe.x64_d3d11.log vsync_off_60Hz_Warframe.x64_dxgi.log
interestingly i got the exact opposite result: vsync on, master build from above and able to run about (edit:) 4h with no freezes at all. i'll report back + attach logfile if that changes :P
seems perfectly fine with vsync on + master.
I just wanted to add my own test results.
In 0.90+, going into a high-load area such as Fortuna or some other multiplayer area seems to trigger this reliably. I've had this trigger inside multiplayer missions as well (especially survival missions where there's also a lot of enemies to deal with).
The strange part is that these freezes will correct themselves if the load isn't that bad, but we're definitely out of luck on cities like Fortuna where the load is constantly changing.
This indicates it's an optimization issue where the speed dropoff is massive.
Finally, we already know it only affects nVidia cards, but if you still can't reproduce this issue, @doitsujin, I think we should entertain the idea that it's card-specific, rather than just manufacturer-specific. If it helps, I have a GeForce GTX 1050, which is the only reason I can actually run these games on my ancient socket AM2+ motherboard from 2009 in the first place.
@Yowlen the reason why I can't reproduce it (easily, without spending ridicoulous amounts of time) is because I never played the game, not hardware.
Oh. Gotcha. Thanks for the quick reply.
tried again with 0.96 with vsync ON and was able to play for about 4 hours without a crash
with vsync auto the game crashes in one of the first two missions, I haven't tried with vsync off
@doitsujin It seems turning vsync either ON or OFF fixes the crashes for warframe. The issue seems to be the constant switching of vsync when in auto mode. Can we somehow help to identify this bug (maybe a rare race condition when switching vsync)
Yes, I've taken to using vsync on in the latest version of Proton, which uses one of the affected versions of DXVK, and it's working flawlessly.
I'll be happy to help test too, if I can. If you can provide a test version that will log everything related to toggling vsync to disk, I can add it into the Wine prefix and see what we come up with.
@NeroBurner I cannot get the game to work locally for some reason, so I can't debug it.
I'd be more than happy to help you get the game running. Which method did you try to get the game set up? in my experience steamplay-proton is the easiest to get working fast, and the native wine version is the most flexible to test new faudio/dxvk versions
If you don't want to pollute the issue you can send me a private message, open an issue over at the gitlab repo of the script https://gitlab.com/GloriousEggroll/warframe-linux/issues or message me on the warframe discord https://discord.gg/6y3BdzC (nick NeroBurner)
@doitsujin Do you have a preferred (semi-)private communication channel? I'd love to help you get Warframe running. I don't want to pester you, as you surely have little (free) time to waste on trying to get a game running. Just wanted to let you know that you don't have to figure out on your own how to install Warframe :)
@doitsujin I've written a little guide how to use the system wine with a testing wineprefix with already downloaded Warframe files. Hope it helps
For the following I create the wineprefix in ~/Games/Warframe_testing
and assume the (already downloaded) Warframe files are in ~/Games/Warframe/Downloaded/Public/
Install latest Wine to system
Download all the required files
~/Games/warframe-linux-master
~/Games/warframe-linux-master/dxvk-0.96
First thing we will prepare the testing WINEPREFIX
. The following commands will install FAudio and dxvk to the testing wineprefix
export WINEPREFIX=~/Games/Warframe_testing
cd ~/Games/warframe-linux-master/dxvk-0.96
winetricks --force setup_dxvk.verb
cd ~/Games/warframe-linux-master/FAudio
./wine_setup_native
With the testing wineprefix finished next we prepare a modified updater.sh
to start Warframe in the testing wineprefix
~/Games/warframe-linux-master/updater.sh
: hardcode WINEPREFIX
and EXEPREFIX
to be used. Insert the testing wineprefix before [Line 26](https://gitlab.com/GloriousEggroll/warframe-linux/blob/master/updater.sh#L26] and modify the EXEPREFIX
in Line 31. The EXEPREFIX
can also be the Gamefiles already downloaded by Lutris (or Steam), but I don't know the path Lutris installs the files on top of my headWINEPREFIX="~/Games/Warframe_testing"
# create folders if they don't exist
if [ ! -d "$WINEPREFIX/drive_c/Program Files/Warframe/Downloaded" ]; then
mkdir -p "$WINEPREFIX/drive_c/Program Files/Warframe/Downloaded/Public/"
fi
EXEPREFIX="~/Games/Warframe/Downloaded/Public/"
~/Games/warframe-linux-master/updater.sh
For NVidia users set the vsync
setting in Warframe to ON
Okay, so this is gonna be a long comment since there's a lot of information to go through.
The short version is that this issue seems to be more prevalent with higher GPU temperatures. Furthermore, it doesn't seem to be a DXVK issue, but rather, a driver issue that's related to increased GPU temperatures.
My evidence is as follows:
For one, it becomes more likely to happen again if I start up Warframe immediately after restarting the system.
Second, I've noticed similar freezes while just sitting on the desktop or doing some non-DXVX stuff in the background such as streaming video or whatever. I tested this by manually lowering the CPU fan speed to essentially heat up the whole system, and since my GPU holds hotter than my CPU, the GPU becomes the clear point of failure. Likewise, increasing the CPU fan to cool the entire system makes it less likely to crash.
Then there's little quirks I've noticed that happen with this freezing issue that can potentially be exploited in order to gather more data.
The I/O LED indicator still goes on as normal during the freezes, indicating the background services are still working. This led me to try something that revealed the second quirk.
This one is far more useful in order to debug things. I can use the CTRL-ALT-F# key combos to access a TTY terminal. This takes several minutes before it actually activates, but I suspect it works due to the fact that background processes still work. It should be possible to activate other system key combos during this time in order to do other things such as setting a key combo to automatically execute the command I mention below, but I haven't tested this.
During this TTY terminal, commands can be executed as per normal, and I've tested two different things:
Killing Warframe via the killall -9 Warframe.exe
(replace with whatever the offending app is if it's not Warframe, ofc) and then going back to the Xserver display will allow the desktop to recover without a reboot. Obviously, the several minute waiting time to even activate the TTY terminal in the first place makes this impractical for regular use, but I mention it since this is the most practical way to gain information on what's actually going on.
Switching back to the Xserver without killing the offending process will result in returning to the frozen and unusable state it was left in.
Edit: I forgot to address the whole vsync thing. I suspect that the reason the older DXVK version was okay was due to how vsync was implemented. Likely, the old system had hacks that resulted in less overall switching on and off, while the rewritten system in the new versions is more accurate and therefore taxes the GPU & its drivers more.
You could try to SSH into your frozen box, or let a diagnosing tool run in the shell during the freeze. With screen
, tmux
or byobu
you could leave the session open even if the SSH session times out
Another update: The Nightwave update released today wreaked havoc on the stability of the game for me, making it impossible to go through even 15 waves of a defense mission. This is why I had the renewed interest to look into this stuff and made the above comment.
Ultimately, Vsync on/off didn't matter, temperature didn't matter, deleting the .dxvk-cache
file... Nothing I did seemed to matter -- until I went into Windowed mode in preparation to test whether or not I could actually interact with background windows with the main one frozen.
I haven't had a problem since, which tells me the issue at hand involves the Borderless Fullscreen mode, at least on my machine. If someone else could test it for me to make sure it's not just me, that'd be wonderful.
I haven't tested normal Fullscreen mode yet, but I'll get to that tomorrow.
Try to set DXVK_HUD to check if dxvk is really used
On February 28, 2019 3:38:01 AM GMT+01:00, Yowlen notifications@github.com wrote:
Another update: The Nightwave update released today wreaked havoc on the stability of the game for me, making it impossible to go through even 15 waves of a defense mission. This is why I had the renewed interest to look into this stuff and made the above comment.
Ultimately, Vsync on/off didn't matter, temperature didn't matter, deleting the
.dxvk-cache
file... Nothing I did seemed to matter -- until I went into Windowed mode in preparation to test whether or not I could actually interact with background windows with the main one frozen.I haven't had a problem since, which tells me the issue at hand involves the Borderless Fullscreen mode, at least on my machine. If someone else could test it for me to make sure it's not just me, that'd be wonderful.
I haven't tested normal Fullscreen mode yet, but I'll get to that tomorrow.
-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/doitsujin/dxvk/issues/802#issuecomment-468113631
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
@Yowlen i noticed not a single stability issue with nightwave, only bug i've seen is sometimes menu backgrounds "stick" in other menus (as in: after i talked to a vendor i had the "INVENTORY: SELL" header showing behind my navigation).
since your issue depends on gpu temperatures maybe your driver is breaking or your actual gpu going into temperature shutoff thus breaking the driver and/or game and/or x server? or maybe it's just your cpu clocking down to a painfully slow rate because you're overheating it because for some reason you're using your cpu cooler to cool your gpu (which doesn't really sound like something endorsed by warframe's system requirements to me). have you tried SSHing into it and running htop and some sensor tools then playing the game while watching those monitors when everything breaks to see what's actually happening?
i'm on literally the newest dxvk release in fullscreen mode (though i have to toggle that before logging in because my WM acts up, maybe switching that off+on (by hitting alt+enter twice) is doing something to help me here, don't think so but can't say for 115% sure) right now, switched vsync on to prevent this issue's bug from happening and it works perfectly fine.
@NeroBurner I have no idea how to do that.
@nonchip As I said, I was using Borderless Fullscreen, not regular Fullscreen. These two modes function very differently, so please don't conflate the two when saying you don't have issues.
Regular Fullscreen allows the resolution to be changed, though on my Xfce WM, that amounts to just adding black space to fill in the rest for smaller resolutions.
Borderless Fullscreen automatically uses the maximum screen space of your desktop's current resolution.
Furthermore, the two modes offer different functionality with stuff like Alt-Tab. In Windows, Borderless is supposed to be faster at switching. In my Xfce WM, the Alt-Tab functionality is largely bugged, and I've had better luck with Borderless, which is why I was using it over regular Fullscreen.
As for what version of DXVK I'm using, I'm using whatever version comes with Proton 3.16-7 Beta in Steam. I think I mentioned it in a previous post, but if it helps for comparison, I'm also using a Pascal GPU -- a GTX 1050.
Latest wine-staging(using faudio) + dxvk 1.0 runs flawlessly for me. Played for about 4-5 hours without a crash. Borderless fullscreen, vsync off, GTX 970. Didn't notice any overheating, had similar temperatures to running the vkcube demo in immediate mode.
I guess I should clarify: I'm using Proton 3.16-7 Beta (the latest atm) with whatever version of DXVK is bundled with it. I'm not sure how to check the installed DXVK version, but if it's not up-to-date, I'll be happy to test again.
I did just reset Warframe's Proton prefix this morning, so I'm gonna test now to see if maybe it was a corrupt prefix & I'll update on that when I'm done.
@Yowlen yes i know you said you used windowed mode but that also doesn't crash, just looks ugly on my desktop, which is why i dont use it.
I'm using whatever version comes with Proton 3.16-7 Beta in Steam.
that appears to be 0.96 according to their changelogs, so between a working and a working version, and while i'm not 100% sure if i tested this specific version it should still be working.
the fact you're clearly suffering from a system load or slowpath issue nobody here has ever heard of makes it unlikely to be a dxvk problem, are you sure you're not encountering this problem: https://github.com/ValveSoftware/steam-for-linux/issues/6073 (tl;dr: steam locking up computers by going berserk with system load)
It's not a workload issue since my hard drive's I/O light doesn't go berserk. And as I stated above, by killing Warframe via the TTY terminal, it works smoothly again, indicating it's not something wrong with Steam itself, but something going wrong with the game.
Combined with the increased chance of it happening again if I try again right away, the only conclusion I can make is that nVidia's drivers are unstable and DXVK just happens to trigger the bug somehow.
Edit: It seems Steam insists on using 3.16-1 for Warframe for some reason, regardless of what I set it to in the settings & game's properties page in Steam. Wonderful.
Add --debug in your warframe launch options in steam. Right click on Warframe and select game properties. There you should also find launch options
On February 28, 2019 3:58:32 PM GMT+01:00, Yowlen notifications@github.com wrote:
@NeroBurner I have no idea how to do that.
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Latest wine-staging(using faudio) + dxvk 1.0 runs flawlessly for me. Played for about 4-5 hours without a crash. Borderless fullscreen, vsync off, GTX 970. Didn't notice any overheating, had similar temperatures to running the vkcube demo in immediate mode.
After playing some more I can say it's still stable, but there appears to be a vram leak? It slowly increases its vram usage(~1GiB at first after getting in-game) until it hits the max of my card(4GiB.) Causes everything else that uses the GPU to be slow. Should I open a new issue for this, @doitsujin ?
Apparently the game has been using DX10(since ??) instead of DX11. May be the source of issues and/or source of stability. Will do more testing after the hotfix.
I'll test too, though I can say that either resetting my Proton prefix or the 24.3.2 hotfix has made Borderless Fullscreen stable again.
Tbh, if the regression to DX10 came in that hotfix, I'm not looking forward to what that could mean for me and my stability in Warframe.
Edit: It seems stable now. I made it to wave 15 in the Defense mission on Ceres without issue. I think that whatever was causing the issue was either fixed in the 24.3.2 hotfix or the resetting of the Proton prefix.
Warframe defaults to DirectX11 now, and recently dropped DirectX9. DirectX10 is available as an option. See https://forums.warframe.com/topic/1052232-psa-minimum-supported-specs-changes-in-february/
@oswaldtechnic well they tried to default to d3d11, that's why they needed the hotfix to actually do that because they screwed up that change and forced d3d10 on everyone :P
and also, yes we're aware of those changes, they're unrelated to this issue though. only relevance is we're glad dxvk works pretty much perfectly now because the wined3d10/11 alternative was hell.
also i feel this issue is
so given i'm the one who opened it and nobody else is doing it i guess i'm gonna close it now
Sorry, but I'm gonna have to say it's not solved yet. Now that I'm using the latest version of DXVK and a clean Proton environment, I can verify that it's not anything like that getting in the way. The freezeup is still happening on the biggest areas for me. (Plains of Eidolon can be confirmed for sure. Haven't tested Orb Vallis yet.)
That said, the behavior seems to have changed a bit in DXVK 1.0 compared to DXVK 0.9x. Rather than locking up the system entirely, only the video is freezing now. Input, sound, etc. all still work. That means I can actually still play the game, but I'm running blind, so it's pretty much impossible to find my way to the exit to collect my rewards unless I'm already there in the first place. I really have no choice but to abandon the rewards I've collected and use ALT-F4 to close the game.
Interestingly, Warframe itself detects this video issue and opens up the crash reporter when I do this, so I've sent a couple reports to them as well to see if they can look into it from their end. But ultimately, this issue is dulled, but not solved.
@Yowlen sorry but i'm gonna have to say that yes it is, because it's a totally different issue, probably just your VRAM being too tiny or broken or your driver messing up. or something esoteric about your proton installation. so not this issue and you should probably do what you should've in the beginning: start a new issue after figuring out if it's actually dxvk's fault, because it's unrelated to this one
What kind of reply is that? "Do what you should've done"? I have been. And you know how I know you're just being a dick here? You mention my proton installation being a possible cause, which shows you haven't actually read my reply where I mentioned I ALREADY TESTED THAT WITH A FRESH PREFIX! So don't you dare dismiss me and my evidence and try to tell me it's something on my end, giving a dozen different reasons that, I repeat, I'VE ALREADY TESTED just so you can feel superior.
Everything I've seen indicated it's the same issue, just that 1.0 is better with not locking up the CPU anymore. I'm still stuck with DXVK 0.81 because of this since that's the latest version that's unaffected by this issue because it's the same. goddamn. issue.
Edit: Also, "just turn VSync on or off" is not a fix. It's a workaround, at best. The underlying cause is still present and needs to be addressed, so even if you wanna assume my issue is different, this issue should still remain open.
"Do what you should've done"? I have been.
you have not, you hijacked an unrelated issue and then told me it wasn't resolved.
And you know how I know you're just being a dick here?
maybe go back to kindergarten with that ad hominem style of yours?
which shows you haven't actually read my reply where I mentioned I ALREADY TESTED THAT WITH A FRESH PREFIX
who's the dick now shouting all over the place and telling me what not to dare when i'm trying to explain to you why your issue doesn't apply here, after already proving your qualification with highlights such as "it can't be system load since the led isn't blinking"? your proton version and specific steam and libraries setup has nothing to do with making a new prefix, and you're literally the only one here with that issue, so don't you dare dismiss me and my evidence and try to tell me it's something NOT on your end.
giving a dozen different reasons that, I repeat, I'VE ALREADY TESTED just so you can feel superior.
actually just 3 different possible reasons, and how exactly did you test the impact of your RAM/VRAM sizes? usually people don't just temporarily swap in better hardware before going back to their "normal" one... also how did you test the binary driver blob? or the system load after you already stated you are unwilling to be told what "ssh" means so you could actually monitor your system while it's happening?
the only one trying to feel superior here is you, shouting at me because I didn't agree your totally different issue is in fact the same one, and for trying to tell you that making a new issue for it would help the developer(s) with keeping track of things and increasing your chances of someone helping you.
I'm still stuck with DXVK 0.81 because of this since that's the latest version that's unaffected by this issue because it's the same. goddamn. issue.
except you're literally the only one experiencing it. by the way since you keep mentioning proton: i don't actually use it and from the statements of the others above it seems so neither do they, maybe that is your issue after all, not the prefix you were screaming at me about, but the fact you were using proton, and maybe then you should ask valve about this issue of yours or check their tracker for others with similar problems maybe?
Edit: Also, "just turn VSync on or off" is not a fix. It's a workaround, at best.
it is a fix. nobody needs the auto setting. and the auto setting is clearly misbehaving in the application as shown in the logs above.
even if you wanna assume my issue is different
it is.
this issue should still remain open.
since nobody else experiences the problem described in this issue anymore i closed it, and if the problems resurface i'm sure someone will reopen it and eventually deal with them.
I'll address the last part first since it's the easiest because I already explained it: The issue still exists. It's just hidden behind a workaround. Put Warframe's VSync setting on auto and it fucks up again. We all know this. For proper implementation, DXVK has to work on all settings. Therefore this is still a valid bug and needs to remain open.
As for the rest, I'll start playing fair again when you do. Stop the gaslighting and I'll stop the ad hominems. I told you my issue experiences the exact same symptoms as yours with the exact same set of requirements, and that I've already checked everything to make sure it was nothing on my end. A new issue would just be considered a duplicate of this one -- especially since this one has to remain open anyway.
Put Warframe's VSync setting on auto and it fucks up again. We all know this.
yes, because warframe behaves wrong, not dxvk, as seen in the logs above
As for the rest, I'll start playing fair again when you do. Stop the gaslighting and I'll stop the ad hominems.
oh i'm gaslighting now if i don't want to be shouted at and called a dick for having a different opinion and explaining how i got to my conclusions? neat, that's a new one.
the exact same symptoms as yours with the exact same set of requirements
except that:
so it's clearly a different issue because it's not solved by applying the "workaround", and it has different symptoms as this one. so a new one would, by definition, not be a duplicate, and this one doesn't have to remain open, because everything we can fix about it we did. we can't change warframe and prevent it from toggling between vsync on/off on the auto mode until it dies just because it can't decide which mode it likes more. it's not dxvk misbehaving, it's warframe. as already stated multiple times and backed up by the developer himself in response to a log file from a version he specifically made to figure that out.
EDIT: @doitsujin i think we might need a lock here if this keeps going, the insults are clearly not helping this issue at all.
EDIT2: oh btw just in case you're using that "linux-shader-cache-ramdisk" of yours for warframe (which i suspect you are since you mentioned over at the proton issue you made it because you decided "gloriouseggroll's cache does not make any sense at all" after not understanding what it actually is) , that could totally be the culprit here, leaking a bunch of ram on each map load is not gonna help your performance.
You're gaslighting because you're deliberately avoiding the issue and trying to convince me that everything I said was wrong. Hell, you even gaslit me about answering how I gaslit you by misrepresenting the fact that by context, it's clear I was referring to the post before my ad hominem, not your reply saying I made ad hominem attacks.
You wanna talk about logical fallacies, then stop making them yourself first.
As for the actual issue, stop making excuses. I told you, I already tested everything. This issue only affects DXVK versions >0.81, and only with nVidia cards. It doesn't affect DXVK + AMD/Intel & it doesn't affect Windows. And the fact that it doesn't affect DXVK 0.81 tells me it's not nVidia's drivers or even Warframe either, but rather a specific piece of code within DXVK either geared explicitly for nVidia cards or otherwise missing an exception for nVidia cards that 0.81 had.
Logical reasoning led me to this, so all your excuses trying to blame me are exactly that: excuses meant to protect your own fragile feelings.
As for locking this thread down, I'd just suggest the proper solution: Editing the main post and/or title, as well as re-opening the issue to reflect the findings I've made. Only after that do we delete the comments dealing with your undue attacks on me and my retaliation against those attacks.
You can unsubscribe from this anytime you want, little man, since you seem intent on not worrying about it anymore. I don't have that luxury since I'm still affected by it & need it fixed so that I don't have to keep using hacky workarounds such as downgrading DXVK. You're choosing to continue participating, and as a result, I'm forced to keep setting the record straight. Just unsubscribe, go away, and leave this to the people who actually know what they're talking about because you clearly don't.
You're gaslighting because you're deliberately avoiding the issue
i am not, i'm just saying it's a different one
and trying to convince me that everything I said was wrong.
because you were
it's clear I was referring to
oh it's "clear" now? who's gaslighting again?
This issue only affects DXVK versions >0.81, and only with nVidia cards.
i have used dxvk 0.90, 0.96 and 1.0, on nvidia cards, as have others here, and none but you has the issue. and you yourself said it does not depend on vsync. and you yourself said >0.81, not >0.90, so it's clearly a different issue than this one that freezes on >0.90 depending on vsync.
It doesn't affect DXVK + AMD/Intel & it doesn't affect Windows.
a) how do you know that, and b) how does that mean it's dxvk's fault, you just said it only happens on your nvidia setup.
And the fact that it doesn't affect DXVK 0.81 tells me it's not nVidia's drivers or even Warframe either
oh ok, yes, good point, so you just confirmed it's still a different issue because the one in this thread was warframe's fault?
but rather a specific piece of code within DXVK either geared explicitly for nVidia cards or otherwise missing an exception for nVidia cards that 0.81 had.
as i said a bazillion times already: it does not happen on my system, which is currently dxvk 1.0 on nvidia. so it cannot be dxvk>0.81 fucking up on nvidia.
Logical reasoning led me to this
the same logical reason that fails at literally every step of the way by ignoring you're the only one having this problem that's unrelated to this thread's issue?
excuses meant to protect your own fragile feelings.
and more ad hominem bs, you sure it's not your feelings you're talking about here? i mean you're the one crying about "gaslighting" just because i don't have the same bug you experience...
[... the paragraph openly trying to coerce me ...]
yeah that's reeeaaaaally victim like behaviour.
You can unsubscribe from this anytime you want, little man, since you seem intent on not worrying about it anymore.
a) i'm not a man b) i'm not little c) i'm not intend on "not worrying anymore", i'm intent on getting your problem fixed instead of trying to hide it in another resolved issue's thread. because you hijacking this resolved one will only serve to obscure it from the devs instead of getting it fixed.
since I'm still affected by it & need it fixed
start reading, maybe? you are affected by something else, since this one is fixed, which is why i'm telling you it's more effective to actually start a new issue for it. you're just lowering your chances of getting your issue resolved by burying it in another one and then bitching about how people are "gaslighting" for trying to help you.
You're choosing to continue participating, and as a result, I'm forced to keep setting the record straight. Just unsubscribe, go away, and leave this to the people who actually know what they're talking about because you clearly don't.
you just literally presented a textbook definition of actual gaslighting by saying that sentence.
uuuh thumbsdown emote, real mature. yeah i think i'm gonna "unsubscribe" you instead, have fun shouting at nobody.
EDIT:
solution:
either enable or disable vsync in game (esc->options->display) because "auto" breaks.
referencing https://gitlab.com/GloriousEggroll/warframe-linux/issues/70#note_122987817, it seems the versions including/supporting stream output reliably freeze Warframe (leaving behind an unresponsive window, the background music still playing and 3 threads at 150% cpu to be killed before restarting the game) on average every 5-15minutes.
downgrading to
0.81
has fixed the issue for some people (including me), so while not 100% sure stream output is the culprit it seems to be pointed to by that.maybe we could get a
d3d11.fakeStreamOutUnsupported
setting to DISable stream output and/or more logging facilities related to it to debug this further?EDIT: please excuse my lack of an apitrace, but it's simply not possible to reliably run the game without dxvk due to a memory management issue in the microsoft dlls in combination with linux allowing larger memory chunks to be allocated than win does.