Red Hat developer Adam Jackson has opened a new merge request for the Mesa project, with what they're calling GLX Delay, to bring accelerated GLX for Xwayland with the NVIDIA driver.
Their work in progress code should be reasonably fast, they mentioned the OpenGL rendering part should hold up against Xorg itself or EGL "on the bare metal". However, it's thoroughly unfinished with tons not even implemented yet like resizing windows and plenty of other features. Amusingly, they describe the way it's done as something that "sounds unpleasant":
"Delay" is a hack to enable direct GLX contexts under Xwayland when using the NVIDIA binary driver. It works by creating an EGL context on the client side, running GL rendering through that, and translating GLX commands to either EGL or X protocol as necessary. The library that performs this translation is a GLVND vendor library, which Xwayland configures as the vendor responsible for the screen.
Why is it going into Mesa when it's for the NVIDIA proprietary driver? They said pretty simply that Mesa's GLX code already implements most of what's needed to allow it. Additionally, Jackson mentioned how it seems like it will "eliminate a large class of reasons why you might need to use Xorg and NVIDIA's driver" and that it is "better than what you currently get for GLX clients in that scenario, which is llvmpipe". However, it can be seen that it "entrenches the position of NVIDIA's libEGL, since we've only made it more useable" but "on balance, that this reduces the binary driver footprint, and I think that's a good direction to go".
In short: if finished and accepted, you might in future see NVIDIA's proprietary Linux driver + Wayland working nicer.
For those interested, the code is up here.
Article taken from GamingOnLinux.com.
somebody1121 Aug 24, 2020
NVIDIA are very much aware of us, they event sent us their top GPU. So yeah, weird thing to say.Why can't be done in the NVIDIA or wayland side? Mesa has enough dealing with hardware and game bugs to increase the maintenance burden with the proprietary drivers.Please in NVIDIA would be laughing at your comment. If they cared for Linux at all to even know about this site, that is.
Why can't be done in the NVIDIA or wayland side? Mesa has enough dealing with hardware and game bugs to increase the maintenance burden with the proprietary drivers.It can't be done on NVIDIA's side because of NVIDIA. It also cannot be done on Wayland's side because such a side doesn't really exist. You have your Wayland specification and a number of implementations and individual implementations probably shouldn't be concerned with how to handle accelerated X11 clients on a specific GPU vendor, because they are supposed to be Wayland compositors and not X11 servers. So this can only really be done as a shim on the GLX/Xwayland level.
The MR has a "Why is this in Mesa?" section that explains why they decided to implement it on Mesa. After a quick scan of the changes they've made in that MR, it doesn't look like it would be too big of an additional maintenance burden, but the Mesa devs would be well within their rights to deny code that is only aimed at working around issues in NVIDIA's proprietary drivers.
Even the recent GeForce Now capability we had, it was more like a loophole from Chrome OS - so much that they did not even recognized Linux PCs using chrome to allow it to be played, we had to fake the user agent. I mean, if they care for Linux, why not bunch together chromeos and linux? After all, it works the same in either!
The video hardware decoding support needed for a quality stream is still a mess on Linux. Yes, you can play even with software decoding provided you have a good CPU, but (as Stadia has shown) this can lead to a very wide range of results, starting from very good, to disastrous.
Even on Chromebooks, only several models have been tested and guaranteed to work, others "may work".
While Google threw their hands in the air and allowed Stadia to run even on non-adequate hardware (and like I said, with disastrous results) Nvidia most likely wants to assure that some standards of quality are still met. Standards that unfortunately right now can't be guaranteed on Linux. Nothing nefarious, no "anti-Linux" agenda here. Heck, the web client in question is unsupported even on Windows.
That being said, they're still working on extending their support to other platforms. If that means also Linux, it remains to be seen.
Last edited by dubigrasu on 24 August 2020 at 1:35 pm UTC
The video hardware decoding support needed for a quality stream is still a mess on Linux.This sounds like something important and I don't know anything about it. Could you develop this theme a bit? Like, what does that mean exactly? And who would need to fix it, and are there barriers in the way of their doing so, and whose fault is that?
And who would need to fix it, and are there barriers in the way of their doing so, and whose fault is that?Well, there isn't a single entity that is to blame or able to fix it, and is unlikely that the issues will be fixed anytime soon, (apart from unofficial forks). The bug report itself carries the label "Wontfix".
The basic motives are described (by a Chrome developer) like this:
“Our goal is to have a Stable and secure browser first, and a GPU-accelerated one second, when possible.
As we found out time and again, any sort of GPU acceleration has a lot of maintenance associated with it, between the multitude of configurations our users run, the general lack of quality of drivers (in particular on Linux), and the constant stream of incoming issue due to new hardware, driver, or distribution release.
“We don’t want to compromise the first goal (stable and secure browser), our choice is not to enable these acceleration features on Linux.
A good (and fairly recent) comprehensive story with all the relevant links can be found here:
https://www.omgubuntu.co.uk/2018/10/hardware-acceleration-chrome-linux
So I am thankful for this MR.
My next graphics card will probably be from AMD to support the cause
.
Luke_Nukem Jan 26, 2021
Patreon
PayPal
See more from me