-
Notifications
You must be signed in to change notification settings - Fork 27
Resetting the cache state file #30
Comments
I'm not sure it's even that easy at the moment. once a map gets switched to another one due to the weekly/daily rotation, it becomes completely unusable for me - I'm talking 0 playable FPS and the game completely frozen for a few minutes, regardless of how many times I try playing it, even with DXVK_ASYNC enabled on Proton-GE. it eventually goes back to normal (usually well after I've touched the ground), but the overview of the entire map seems to be locking everything up every time. |
Seeing as we didn't have Olympus or World's Edge for the past week the lag would make sense for the next couple of days as we rebuild the cache file. I just hopped on with our latest cache file on World's Edge for the first time this season and I had very little stutter. This is why it is especially helpful to have more people contribute so we can build it back up again as quickly as possible.
This could be a couple of reasons I would imagine. Could be a hardware bottleneck from disk speed to cpu processing power. You might be accidentally not using Proton GE, or a spelling error in your command line args (this happened to me 🙄). I would say double check everything is installed and set up correctly. Otherwise, we have this cache file available for use! |
I too have had very little to no stutter today on WE. But I've had huge stutter issues in my very first game of Olympus today. After dying I stayed the whole game and spectated. After two more games of playing and spectating I had no more stuttering at all. Storm point is as far as I can see stutter free as well. Because I'm new to the whole DXVK pipeline cache I got a question. By resetting the cache file do you mean completely deleting the cache file or create a new cache file with the entries that are still valid? I also gotta read up upon why cache entries get invalided in the first place. But generally speaking I would be ok with resetting the cache file after major changes to the game. I don't mind playing or spectating the game after major map changes to get the cache back on track. |
Unfortunately from my very limited understanding we have no easy way of verifying what each entry represents came from the games shaders, or when it was actually rendered. It seems it uses some sort of hash generated when a shader is first rendered to identify each entry. It seems like now we are just adding on more entries and the extreme lag at the beginning of each map returning would suggest DXVK isn't accessing the old entries any more. I imagine starting from scratch because we cannot validate what each entry is from, time or map wise at this time.
Yeah, I'm sure if we had access to Apex Legends source code and design files and A LOT of man hours we could eventually figure out why map changes make the old entries invalid. But I don't think that will happen.
I have been looking at it, but as a hobby programmer with experience only in .NET, it is taking me a while to figure out exactly what the Rust code does in the tool. I would like to really understand it as it could be a really good base for a custom tool used to manage these state files and track it's changes over time.
Thank you for your feedback and work! |
After re-reading your first comment, I want to make sure I've understood correct. With the "large" map change, did you mean the start the new season or did you mean when they put WE and Olympus back in to the rotation at the start of this week?
Yeah that's what I thought too after taking a quick look at the source code of merge-tool.
There gotta be at least some hints to why they stop being valid on the internet without reverse engeneering the whole game 😄
That's what I thought too. I will take some time on the weekend maybe and take a deeper look at it. I've been meaning to learn Rust since some time ago so it's actually not that bad. I'm an EE and only a too hobby programmer. I've experience in C, C++ and Python. |
after posting my previous comment, I've started my very first World's Edge game ever yesterday, and didn't have a single stutter. it looks like my issue is limited to Olympus at the moment, and trying to "play" it (by which I mean staring at a static screen for 5 minutes, and then doing the same after getting killed while spectating a teammate, with a few seconds of normal gameplay inbetween) multiple times has no effect on the issue. unless someone else has managed to play Olympus without frame drops using this cache, in which case I'll start looking for other explanations.
I'm already using that file, and it's been working fine on every other map that I've tried so far. I don't really think it's an issue with something specific in my setup, given that before the recent update I played the map without any problems. |
After the most recent event update it seems that even small changes to a single map will invalidate all of the entries in the state cache file. For now, I have decided to reset the cache file since there is no point in wasting storage space on entries that no longer matter. |
After playing today it seems to me that each "large" map change or new map is going to invalidate most of the cache state file that we are working on here. I want to start a conversation around resetting the cache file when one of these major changes comes about. Obviously this is not ideal as each season and sometimes even more often we will have to do all the caching over again. The lag issue CAN be overcome by running DXVK_ASYNC=1 when you have a version of Proton that supports it. Without more expert knowledge on how the state file works, resetting the state cache file as we notice it begins to lag again seems like the best option until someone can some up with a custom merging and state file hosting solution. Is this something people would be okay with?
Each reset would rely on people willing to play many games and those who run with DXVK_ASYNC enabled to quickly build up something playable for others to use and start contributing.
Please post your thoughts here.
The text was updated successfully, but these errors were encountered: