[Testing Update] 2019-08-17 - Kernels, Systemd, KDE-Git

So if it still does not work with extra plugins removed. Try with a fresh config.

mv ~/.config/deadbeef/config ~/.config/deadbeef/config.bak

If that does not work, maybe rename the entire directory and start with a clean profile.

1 Like

Yes, it worked with a new config. Thanks!
The dam thing is that I lost all my playlists.

You can copy the playlists from the old profile to the new one. That should not be a problem.

Found the reason for pulse audio not playing, it was just that in the "PulseAudio output plugin" config is to leave blank if it was the default and I write "default" in there. :slight_smile:
So, back to my old configurations

anyone having issues with steam/proton after this last update?

most of my proton games either wont start or do start but a constant cycle of about 5 seconds frozen and 2 seconds not frozen. kernel 5.2, 5.3, 4.19 with the same behavior. i tried uninstalling a game thats usually a solid 60FPS on high settings (redfaction re-marstered). got rid of the local files left behind and did a fresh install of the game and it ended up with the same result. also tried multiple proton versions and still nothing.

just curious if anyone else is observing something similar?

Might that be based on the Nvidia driver?

im gonna do some more testing shortly, i always use vsync in games so i tried disabling it and on the 1 game i tested stopped the 5s freeze/2s play issue. im gonna setup my test install for prime and run some games from there to see if i can reproduce it. i'll post what i find.

note: this is not with the new render offload setup, it's setup as prime.

ok, it seems the nvidia drivers are causing it.

i have an awesome-wm setup with PRIME(daily driver) and a clean i3 install setup as PRIME also for a clean environment to test this.

awesome (testing branch)

  • latest nvidia 435 drivers
  • the unusable long pause/freezing situation happens if i launch a game with vsync enabled. this issue never happened until after the nvidia update.
  • i also noticed in lutris, in a wine games preferences, the nvidia vulkan ICD loader is no longer listed, "none" is now the only option. both lib32-vulkan-icd-loader and vulkan-icd-loader are installed

  • i tried downgrading the icd-loader packages only but had no effect.

i3 (testing branch)

  • latest 435 drivers
  • behavior is exactly the same as my daily driver awesome-wm install so it's reproducible in a clean environment.
  • tried each step i did with the awesome-wm install and had no positive effect.

i3 (stable branch)

  • i switched to the stable branch since it has the 430.* drivers
sudo pacman-mirrors --api --set-branch stable
sudo pacman -Syyuu --overwrite '*'
  • after a reboot, launch steam, launch game and everything works again.
  • lutris also shows the correct icd-loader listed as well.

  • im gonna test a GL only game to confirm it has something to do with vulkan/435.* drivers to see if this behavior is only with vulkan and the new drivers.

im gonna do some more troubleshooting, let me know if you have any ideas you want me to test.

UPDATE: this seems to effect vulkan games with vsync enabled.
with the 435.* drivers, i also tested this with DOOM (2016) on both installs.

with 435.* drivers freezing happens if vsync enabled using vulkan api, disabling vsync OR switching to OpenGL and the freezing stops (but game performs terribly bad in GL). OpenGL with vsync doesnt seem to have the same effect so it seems something is up with vulkan on these new drivers.


I have no problem with the latest nvidia driver here. CMIIW, nvidia did remove their non-glvnd driver and move it's vulkan json file to a different place. So, if you fail to load vulkan games/wrapper or old apps you might want to tell the game/steam where nvidia files are with LD_LIBRARY_PATH and VK_ICD_FILENAMES. For Proton/Lutris games, telling them where the json file is probably enough.


I've played some wine+dxvk games and they are all works straight without those calls tho.

1 Like

i just tried them to be sure, but the problem is not that vulkan fails to load. the games will launch as vulkan but enabling vsync results in not only locking up the game but cpu process also shoots up. but only when vulkan and vsync are used together.

i tried both with and without prime synchronization enabled, multiple kernels. going back to the 430.* drivers gets rid of the issue.

tried these and no difference.

did you test with vsync enabled or disabled?

DXVK+vsync is working on my PC. I see you're using nvidia prime offloader on your profile. Maybe that's part of the problem. Arch wiki do mention about vulkan+vsync lockups problem with Prime. Read the last part of this page. I hope it helps. https://wiki.archlinux.org/index.php/PRIME

1 Like

No problem here with Steam and Nvidia 435 (GTX 1050). I only use DOOM with Vulkan but it's all good. Synchronization is set to adaptive. Wine games (wine 4.13) works fine too (Wolfenstein Old Blood). Again sync on adaptive which switch on/off depending on the load.

Actually it is pretty much up to the level of windows now. What an accomplishment.

1 Like

prime has been rock solid up until this point, and only on these new drivers but these drivers also introduced new features for optimus setups for offloading so im wondering if in the process of adding this "new" feature something else went wrong.

it does sound strikingly similar to what im seeing except, disabling prime sync only introduces horrible tearing.

thanks @sdn and @suzannex for checking, it seems an optimus related issue which for now anyway is not a big deal as these drivers are only in testing/unstable. i'll focus on the optimus/vulkan/vsync angle and see what i come up with. :man_shrugging:

You're welcome. And, yes, its kinda weird if you didn't have that problem before. Maybe that new beta driver is from the same development path that introduce vulkan+vsync lockups, where it has been fixed in the 430 driver series. Or maybe simply because it's a beta version. :grin: I hope they fix it in the next stable release.

PS: I don't use Prime but would you try disable Prime Sync but then enable nvidia full composition pipeline to reduce tearing just in case it works? I don't recommend this for playing games with laptop as your GPU may actually still render a lot of frames than your monitor refresh rate, and combining with in-game vsync might cause input lag (I did try that with CSGO and it became laggier than usually happen with only in-game vsync enabled).

i can work around it by using the 430 drivers but thats not really a fix.

thats the thing, prime sync which is what nvidia drm_modeset=1 does but it has no effect on the current issue, it's only the difference between tearing or no tearing. FFCP is not an option for the reasons you mentioned among others. if i cant figure it out, i'll create a thread about it.

that's the thing though, i've read that prime wiki many times in the past while helping others fix random nvidia issues and the part about vulkan/vsync causing lockups i could never relate to since i, myself have never had this issue nor have any of the users i've helped troubleshoot other issues. before these 435.* drivers, prime worked perfectly.

My only objections with nvidia 435 is losing the slider bar in Open GL for Image settings. now there are four settings instead of getting a partial change for changing my Desktop wallpaper quality. I imagine for game players this has an effect too. I do not play games, but, I love high def.

even when you had the bar, there was only 4 settings depending on where the bar was adjusted to so aside from aesthetics it's no different.

1 Like

It's a matter of degrees, not the set amount.

I duo-boot with Testing. My stable version 18.10 rc5 still has the older nvidia v: 430.40. You can move the bar in very short increments, it does not jump to the next setting. I saw your ":thinking" emoji . Perhaps this clarifies it?

1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by