Closed eMorph closed 3 years ago
Hi @eMorph, Thanks for the info! All original code paths are left intact, but were disabled. I'll try to test which are available with this new driver version. Did not find and info about dma-buf support though, will see.
I can confirm that:
EGL_MESA_image_dma_buf_export
EGL_EXT_image_dma_buf_import
EGL_EXT_image_dma_buf_import_modifiers
are all available in 470. Haven't tried using them yet, but it looks promising.
Current state: with 470 diver process hangs right after rendering the first frame. Searching for a reason.
Current state: with 470 diver process hangs right after rendering the first frame. Searching for a reason.
same for me, something seatd?
The reason of hanging was halt in eglSwapBuffers when no stream image is available. This looks like a bug in blob, but anyway I added a check for this. Now swapping is not done until a new or old frame is ready. With 470 driver it works (and with current 465 as well).
However, there are at least 2 problems:
For me it's currently unusable because of (1), but you may try how this works for you. Note: dmabuf image import is disabled because of (2). If you want to try accelerated X, plrease remove check at egl.c, line 359.
Small mupdate: looks like X acceleration works even without (2). I had to reboot after 470 driver installation. In my case the info from glxgears showing:
$ glxgears -info
GL_RENDERER = NVIDIA GeForce GT 1030/PCIe/SSE2
GL_VERSION = 4.6.0 NVIDIA 470.42.01
GL_VENDOR = NVIDIA Corporation
The last thing is to wait when performance issues are resolved, maybe in next driver release
Well, I tried KDE with new driver and it works just fine, no lagging at all! Seems that there is something else left to be tweaked. Working on it.
The issue seems to be related to timings. In pre-470 series eglStreamConsumerAcquireAttribNV
function (which displays new frame) took <= 1 millisecond and returned almost immidietely. But with 470 it's takes ~16 milliseconds (hardware vsync?) and maybe breaks internal wlroots timings.
I'm not quite sure yet how to solve this properly. Still looking for a solution.
Nvidia confirmed a bug. Unfortunately the way wlroots handles events makes it not so simple to overcome this until bug is fixed. Hope in next driver version the corrections will be made.
How can we get XWayland to run with the EGLStream backend in sway?
sway doesn't start XWayland with -eglstream
, so it's choppy, while it works fine on GNOME Shell (which does officially support it).
Hi @hyarsan, currently with stable 465 driver series it won't work because of driver limitations. With beta 470 version it will use acceleration but will be choppy until issue with presentation timings is fixed in the next minor driver release.
@danvd, NVIDIA Releases 470.57.02 Linux Driver. Has laggy rendering been fixed in the stable version?
Nope, the issue is still here. What it means is, well, now I don't know if it will ever be fixed. May be there is a workaround exists, I'll try to find it, but can't guarantee success.
As I can see dmabuf functionality is still disabled. Are the new extensions not functional?
May be they are functional but useless (I did not find any apps really using them). But enabling dma-buf breaks chromium (it tries to use gbm and fails), so I left it disabled for now
Latest pushed changes contains some klugdes for 470 driver (moved eglstream flipping to a separate thread). It more or less functional with single monitor, but defenetely it's not the end of story. Still waiting for nvidia bug fix.
Mesa 21.2 has been released. Proprietary NVIDIA driver should now support GBM. Has anyone managed to run Sway with original wlroots on new Mesa?
@monosans Correct me if I'm wrong, but it looks like GBM alternative back-ends support has landed in Mesa, but that does not change the fact that Nvidia drivers still don't support it.
@PolyMeilex I was wrong.
Quote from phoronix.com:
With it being upstreamed for Mesa 21.2, presumably NVIDIA will soon be shipping a proprietary driver update with their external GBM back-end library for further improving their Wayland support.
Hi guys, the issue is fixed with new driver 470.63.01 Even steam games work (proton):
https://user-images.githubusercontent.com/5666218/128910395-4478b6ab-a8c5-440e-95ca-f58a9e5f6590.mp4
That's awesome to see! Are there huge performance impacts running proton on xwayland instead of classic x11 directly?
I hope one day we can use Sway for gaming with proprietary Nvidia drivers 🥳
That's awesome to see! Are there huge performance impacts running proton on xwayland instead of classic x11 directly?
I hope one day we can use Sway for gaming with proprietary Nvidia drivers partying_face
Not particular to Proton but, IIRC, you cannot turn vsync off on Wayland, so competitive gaming might be better on Xorg at the moment.
Sway specifically also has some caveats, for example this bug.
I did not noticed any slowdown. Played farcry5 for several days and it runs very well :-) Closing this as resolved.
The README of the project states that dma-buf does not work, due to the proprietary NVIDIA driver not supporting it. Therefore, on-the-fly GPU switching and buffer protocol switching aren't possible.
However, with the incoming release of NVIDIA version series 470, dma-buf support will arrive. The beta for the first version in this series of drivers is already out for testing purposes, boasting full support for dma-buf and XWayland acceleration.
Given this development (in both senses of the word), is dma-buf support still technically included in the code for this framework? And are there any plans to make use of it in regards to NVIDIA GPUs?