-
Notifications
You must be signed in to change notification settings - Fork 214
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
Stuttery input, but perfect frametiming. #995
Comments
This probably is only relevant when gamescope is running in nested mode (which I think is the mode that the JustCauseWhyNot is using): Looking at acquire_next_image() function in rendervulkan.cpp, it seems like resetFences() is always called after WaitForFences() and AcquireNextImageKHR() are successful. Looking at https://themaister.net/blog/2019/08/14/yet-another-blog-explaining-vulkan-synchronization/ |
I'd like to add that based off of some testing I did if I set Kinda separately |
A couple of things you could try:
I also suggest you first try running the game w/o a framerate cap, and without the --immediate-flips flag: or if you need to use strangle: (btw, with strangle, you can set a decimal fps cap. I suggest you go to https://www.testufo.com/refreshrate using google chrome/chromium/chromium-based browser to get a fps rate close to your display's refresh rate) there is also another vulkan vsync mode: Oh and, this may or may not be compatible with your gpu, but you can also try running gamescope in embedded mode |
I tried out what you sent. For the embedded session I got |
try setting -r to double your refresh rate
Lastly, if you're using the gamescope package installed from your repo, you can try building and installing gamescope from the git repository. The only catch is that there seems to be a nvidia driver bug that causes issues on the git version of gamescope.
|
I'm using portage, and installed gamescope-3.12.5. I did patch it to include to fix the resizing issue for nvidia gpus which was causing me grief.
|
|
I'm trying it out on a native game outside of steam, and from a quick little testing time. It's feeling a lot more how I'd expect. Close enough I'd almost say it's resolved sorta, and I was also having the same issue in this game as I'm with bbr. Right now I'd say the issue is with steam, or bbr itself. When I pass for instance gamemoderun to bbr in steam on it's own I also have a issue of it not turning on in the game. |
After more testing for the native linux game if I pass |
It seems like anything that brings my frames below 140 cause major stuttering issues, but if I wasn't using gamescope those issues wouldn't occur. |
I have been experimenting with making gamescope's vblanking system more accurate and also have a lower latency. HOWEVER, all branches of my fork still crash w/nvidia when running games like bbr on gamescope. I might make another branch based off of an older working version of gamescope that incorporates my vblanking experimentations Note that if you want to test out my nvidia-fix-and-vblank-debug branch, I would recommend you not to pass an |
I'll try out your branch. Thanks for informing me about it, and putting in the work. |
oh yea btw for some reason, it seems like my branch of gamescope crashes if it is given CAP_SYS_NICE |
...
Now that I think about it, bbr did manage to run when I turned off an environment variable: looking at this commit: 6b6ffcd I remember that bbr's error window when launching my nvidia-fix branch said something about the game not supporting some window resolution (I think it was whatever gamescope's nested window size was set to). If bbr crashes when running it w/ v3.12.5 gamescope with |
Running |
Try running it with |
That fixed auto crashing 👍, but I'm still noticing significant latency or what feels like it no matter the framerate. |
Try out my new branch: nvidia-fix-and-vblank-debug-extra-experimental EDIT: also I think sometimes this new branch crashes when starting, but should work after trying to launch it a couple times |
I updated the nvidia-fix-and-vblank-debug-extra-experimental branch to fix the issue Tho I will say running it with Make sure to run |
Is that what you're recommending I use? It did boot when I used the previous command I pasted here, but I'm getting |
No, that was just the command I used to run a program which I find helpful to quickly test the framepacing behavior of gamescope
make sure to add also, check that you recompiled gamescope with the latest commits I put out:
if you did set ENABLE_GAMESCOPE_WSI=0 and the game still crashed, then I think MESA_VK_WSI_PRESENT_MODE needs to be So try either of these commands: (not sure if setting -r to double your refresh will make it more or less stuttery)
|
No crashing, and it actually feels way better. But I still am having issues. I do thank you for all you've done to help and contribute. |
Another update: if the Notable difference in terms of usage are a couple switches I added to the new branch:
|
I'll 100% give this a try! |
Update: I just fixed a bug I had made which was causing random crashing. |
On portage I've made a local ebuild of gamescope where I've set it to a live version which when built will always pull the latest commit, and in the ebuild I've set it to your repo & branch. So I can just update gamescope through portage. All I've gotta do is change the branch name for the correct branch in your repo. I just like portage so I figured I'd share how I update gamescope with you, and anyone else who reads this. |
If I try and build your branch it fails to compile. Here's my build.log |
On the otherhand... looks like that same exact compiler error was posted about recently here:
I guess I can just edit my branch's meson.build file to force the fallback for vkroots... EDIT: I just pushed a new commit to the |
Ok Here's output `Exec=env __GL_SYNC_TO_VBLANK=0 __GL_SARPEN_ENABLE=1 __GL_SHARPEN_VALUE=50 __GL_SHARPEN_IGNORE_FILP_GRAIN=17 ENABLE_GAMESCOPE_WSI=0 gamescope -r 308 -w 1970 -h 1108 -W 1440 -H 2560 -F nis --sharpness 10 -S fit -- env MESA_VK_WSI_PRESENT_MODE=mailbox gamemoderun /home/justcausewhynot/Games/WarThunder/linux64/aces`
I did get 4.6 to build locally through meson. It's actually really awesome right now. No flickering, and using mangohuds framerate limiter reeally helps helps alleviate any stuttering. My one issue is if the frames drop below the frame limit of 154 the game will be very jerky. It's like it can't decide which frame to show. Even if the frames drop by a few it can cause major jerking. |
I just pushed out yet another new version: you may want to just use |
I'll try that out in a few hours. Thank you. |
I tried it out. It may be a bit better, but honestly I don't know. It's an issue with screen tearing. I don't believe gamescope is letting the game tear. It's like shows a new frame jumps back a frame and shows another frame. It's weird. Let me know if you want output. |
Not whole output, but I was getting
That printed a lot. |
Yeah I had added a bit of code to check the latency of each vblank imported into the steamcompmgr thread Are all of the lines just .01ms or .00ms? I was worried it would be higher
Anyhow I'll definitely going to have to tweak my code more...
I think there was a draft pr for trying to allow xwayland to tear or something, I might take a look at it at some point EDIT EDIT:
OHHH I just been thinking more about it, and now I think I know a reason for why that might be happening... |
I'd just like to add that its only "choppy" when the frames drop below my fps cap of 154. |
I did a port of vblankmanager to timerfd here: #1053 Still needs testing |
Did a quick test with Borderlands 3 and #1053 does seem to be smoother and have better frame pacing for me with Mangohud vsync set to adaptive in the config, used the in game fps limit to lock 120fps. EDIT: Put a lot more time into it and frame times do feel much more consistent and inline with what mangohud shows. |
Hey @sharkautarch which nvidia driver do you recommend for your revert/patches in https://github.com/sharkautarch/gamescope |
supposedly the newer nvidia driver versions should of had these issues fixed and thus not necessitate my patches, but if you still have issues w/ gamescope on nvidia, I recommend using the nvidia dkms 535 version |
Yeah on gamescope 3.13.19 I face issues starting gamescope on all nvidia drivers (535.154.05,550.40.07,535.43.25) I will give 535.154.05 and the tip of nvidia-fix a try |
Gamescope just hangs on stable :/ trying Gamescope-session from a tty. The closest I got was using Vulkan-beta but navigating the menus is flickering and feels like 15fps |
So are you saying that the |
There are multiple issue tickets in which users (including me) have reported this relatively new freezing / hanging behavior with Nvidia drivers 545 and later and the latest gamescope: Is it possible that this freezing / hanging is the same issue? |
It's very hard to tell, since the interaction between gamescope and the nvidia driver might appear different depending on if you're using X11 or wayland.
Does this new 'freezing' behavior also occur when running with:
Since distro beta packages for nvidia drivers can sometimes be slightly older than the latest nvidia beta, you could try installing the nvidia 545/550 beta driver directly from nvidia's website |
This is new hardware/system so I'm having a hard time finding a workable baseline but you can find my config here if you can navigate Nix
Below is combinations I've tried to no avail: Kernel: 6.1.52 / 6.7.4 I'm launching gamescope from a tty with gamescope session With driver 545.29.06 with Kernel 6.1.52 and gamescope https://github.com/sharkautarch/gamescope/commits/nvidia-fix I am at least able to see gamescope work but it works at about 15 fps with occasional stutters Current output of Nvidia-smi
I'm happy to provide any relevant helpful information. I've also tried all the variants of nvidia drivers with gamescope 3.13.19 |
Did you have to run gamescope with |
No I didn't, doesn't seem like it's set in gamescope-session. |
Hmm |
I tried compiling your branch, but it failed. Here's the build.log |
Do you have a |
Honestly I don't know. I'm guessing no since it's just pulling from your repo at time of build so it's always updated. |
Yeah make sure to put a also btw, you might also want to try my |
@JustCauseWhyNot do note that people have recently been reporting that regular gamescope (version >= 3.14.2) has been working on the 550.67 nvidia driver |
I'm using 3.14.2, but I'm having tons of flickering. With 550:67 nvidia drivers. |
Hmmm maybe try the new release version also what full command are you running gamescope with? |
|
Yeah try that, also check if you are able to run gamescope without the |
Sorry I've yet to update it, but I built it with no wsi support, and you |
I'm launching bbr with
gamescope -w 1970 -h 1108 -W 1440 -H 2560 -F nis --sharpness 8 -S fit --immediate-flips -- strangle 139 gamemoderun %command%
. It's doing a good job of upscaling, but despite setting immediate-flip it feels like I'm playing on 60fps. . As shown in ss the frametiming is near perfect, and stays that way while I input into the game. But it still feels bad to use. I don't know if it's just a limitation with the compositor, or if there's a options I'm missing.I am using dwm/x11, and no compositor of my own. And lastly I'm using an gtx 1660 super. I'm not sure what else to write down, but I'd like to have the upscaling while not having to use a compositor. But the pr to merge into proton got closed 😞.
The text was updated successfully, but these errors were encountered: