you do not understand.
I prefer not to have any hibrid solution at all
Hi,
Any news so far? Has someone a link to this 1629916 bug?
I believe that’s their internal tracking bugzilla, doubt that public has access to it.
Anyways, this is probably low on their priority list, right there with wayland support #shotsfired
+1
I really want to see VSync on Nvidia Optimus.
SteamOS is 3 mounth to go, and we have NOT oficial VSYNC on Nvidia (Notebooks)
Let’s start a betting pool.
10 bucks on this not getting fixed in 2015
another 10 bucks on 8 months until a fix.
I don’t like odds of betting against you ^^
Glad I didn’t bet. Issue remains unresolved, I can’t even watch youtube or scroll a website without getting massive tearing. Also Steam games have a very bad perfomance. Spent days on the issues without any success.
What follows is just my personal opinion, you don’t need to share it…
Bumpin this thread again… after reading into the issue some more, I don’t think it’s a good idea to wait for wayland, which will come someday, then starting to work on new drivers etc. That may take years to get to the state where linux&gaming is at the moment.
Scenario 1:
Wayland runs, but brings lots of issues to the regular (and now stable) desktop environment, like dual screen setups don’t work anymore etc. Long term linux users know the pain. So maybe VSYNC finally works with wayland (smiling Gabe), everything else doesn’t, making it impossible to have a linux desktop+gaming machine for the average user. I’m totally expecting this.
Scenario2:
Some descion making characters behind the major distros start thinking, that wayland is not a good idea anymore, because of bla… Happend before. Wayland gets pushed into a niche corner and will be forgotten. All work from nvidia for supporting wayland was for nothing.
I don’t get it. Can’t you guys at nvidia just fork or extend X to provide that one simple functionality? I mean, it may not be technically simple, but on the user’s side it is.
Again, towards more experienced linux users: we got a very stable, secure and highly compatible desktop and gaming plattform at the moment. We know the pain and the neccessary patience to get to today’s state. Think back 15 years ago, I couldn’t even get an mpeg video playing on linux or read a normal website, think back 5 years ago, it was a weeks-long nightmare to get your laptop’s broadcom wlan running.
If it’s about money from nvidia’s side, make some crowdfunding, I’ll bet we, the linux community, could and would pay for some of your senior coders, if that brings a better linux support.
Another issue likely caused by the lack of proper vsync, linked for reference:
Asus G750JM running funtoo with gentoo-sources-4.2.3 kernel xrandr+nvidia-drivers-358.09.
Everything is awesome, but screen tearing persists. I have read this thread on and off for the last year. Who will be our savior?! When will we be redeemed? Bumblebee is a bullshit solution. I want performance, and always have this huge brick of a laptop plugged-in. Take the tearing away through the use of Laplace transforms or some other high-mathgic. I will be your internet friend forever.
Some work is being done in the kernel and X server to help improve the tearing situation by adding double-buffering to X and support for fences to the Intel driver. See [PATCH i915 v2 0/2] PRIME Synchronization for more details. Once those pieces are in place, then we’ll look into using them from the NVIDIA driver to remove tearing from PRIME configurations.
Thanks!
TY!!
There is some approximate release date for the solution?
Does this mean that we can use the i915 driver instead of the modesetting driver for vsync as stated in https://a248.e.akamai.net/f/248/10/10/us.download.nvidia.com/XFree86/Linux-x86/355.11/README/randr14.html? I’m just assuming because the patch was for the i915 driver instead of the modesetting driver.
Section "ServerLayout"
Identifier "layout"
Screen 0 "nvidia"
Inactive "intel"
EndSection
Section "Device"
Identifier "nvidia"
Driver "nvidia"
BusID "<BusID for NVIDIA device here>"
EndSection
Section "Screen"
Identifier "nvidia"
Device "nvidia"
Option "AllowEmptyInitialConfiguration"
EndSection
Section "Device"
Identifier "intel"
Driver "modesetting"
EndSection
Section "Screen"
Identifier "intel"
Device "intel"
EndSection
It’s for the i915 kernel driver, which is what the modesetting X driver ends up talking to via the generic DRM modesetting interfaces.
Alex’s changes should work with other DRM kernel drivers too, as long as they implement the required interfaces.
Ah, thanks for the explanation! If it works well, we would just need proper optimus-like switching and power-saving to achieve feature parity like the Windows drivers; but that’s a whole different story by itself. Anyways, thanks for the update and keep up the good work!
Guys, I seriously have to apologize. I didn’t expect you’d pull it off. You’re awesome, can’t wait for the release.
Hooray! I’ve been waiting for this! Hurry to get this fixed!
Big thanks for working on this and providing us with a status update. I’ve left a notice with a link back to this thread and to the mailing list post in two downstream bugs caused by lack of proper vsync, namely QTBUG-45959 (upstream report of KDE Bug #347237) and mpv issue 2246.