Wayland Shortcomings

[Bob Davis]

Hi there - 

I hope this is an appropriate email for you all - If not, just let me know. 

As I'm working my way through the Siggraph deck (thank you again, Nick and Francois), one of the things that pops up for me is on slide 28, the third bullet:

• X.Org is going away, will force a move to Wayland which is far from ready for VFX

As your friendly neighborhood product manager who has some influence in how work gets prioritized, I'd really love to know what gaps this group considers critical. I feel like this is an area where we (Red Hat) can make some contributions that will help everyone with a vested interest in a fully featured Wayland (keeping in mind our "upstream first" approach). 

There is a documented list of "differences" in our docs (not sure if this is login gated or not), but I'm pretty sure this can't be 100% complete, and it doesn't describe what you want to do with it but can't because x feature doesn't exist or y problem does exist.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_the_desktop_environment_in_rhel_8/gnome-environments_using-the-desktop-environment-in-rhel-8#wayland-differences-xorg_overview-of-gnome-environments 

If there are specific features it's lacking or integrations that are missing (e.g., SLI from NVidia doesn't work with Wayland - but I don't know if that matters for most of you), please raise them so that I can get it documented and worked on. If you'd rather ping me separately, please do. 

I appreciate all of your feedback.

Best -

Bob

--

Bob Davis

Principal Product Manager, Red Hat Enterprise Linux

bobd...@redhat.com | 210-452-8945

[Deke Kincaid]

SLI is essentially dead as of earlier this year and only supports a single Ampere card.  Most DCC's do not use it as far as I know.  Even renderers that use multiple gpu's suggest that you turn SLI off.

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CAFj%3DrwPKtqD1QE5%3D96p5WFPybC3y_ROEWobokTS2y3WDejYv0Q%40mail.gmail.com.

[Schuler, Laurence (GSFC-606.4)[ADNET SYSTEMS INC]]

One show stopper for our group is that Wayland does not support native Nvidia drivers according to the link provided.

(but we’re still on RH7 until the end of the year)

-- 

Laurence Schuler (Larry)                       Laurence...@nasa.gov

Systems Support                                       ADNET Systems, Inc

Scientific Visualization Studio                https://svs.gsfc.nasa.gov

NASA/Goddard Space Flight Center, Code 606.4       phone: 1-301-286-3557

Greenbelt, MD 20771                                 cell: 1-410-739-0893

--

[Michael Rochefort]

---- On Mon, 13 Sep 2021 18:03:33 -0400 'Schuler, Laurence (GSFC-606.4)[ADNET SYSTEMS INC]' via vfx-platform-discuss <vfx-platfo...@googlegroups.com> wrote ----

> One show stopper for our group is that Wayland does not support native Nvidia drivers according to the link provided.

Newer versions of the NVIDIA driver offer better support for Wayland (and XWayland acceleration), however there is still room for improvement here. I'm not sure how great the EL7 experience would be regardless given the older Wayland and graphics stack. I played around with the 470 drivers on Fedora 34 for a few weeks before switching back to XOrg.

However, NVIDIA has been improving the situation and working on other areas of the stack, such as providing a way to load an alternate GBM implementation into Mesa. So at least they look to be moving in that direction which should make adoption easier than dealing with limited EGLStreams support from compositors (though I don't really know their plans here).

Besides proper NVIDIA support, the next big-ticket item in my eyes is HDR support. I'm aware of the effort going on here in the wayland-protocols project through the color-management protocol draft; seems to be what all the Wayland capable compositors are waiting on before implementing HDR/higher-bit-depth support, and non-basic color profiles:

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14

https://www.collabora.com/news-and-blog/blog/2020/11/19/developing-wayland-color-management-and-high-dynamic-range/

Unfortunately I don't have enough experience with the more advanced setups studios use, such as dedicated output cards e.g. Blackmagic Intensity and Decklink, so I don't know if these bypass the OS/DE-level restrictions (I assume they would?).

A third piece would be DCC support with Wayland, but this should be *mostly*(?) seamless I think. Many of our applications utilize Qt5, which natively supports Wayland through the Wayland QPA from QtWayland. Setting QT_QPA_PLATFORM="wayland" will set Qt to choose the Wayland backend at runtime (haven't tried the alternate method of passing "-platform wayland" to apps from this industry). Two things to note:

1) I don't know if any vendor specific/custom parts of the applications will have issues with Wayland, and
2) Since vendors typically bundle Qt along with their application I have a feeling they may also need to build and supply the Wayland QPA plugin and not rely on the distribution provided plugin, which can differ from the version of bundled Qt. Though this should be a limited problem right now considering Qt5 is at the end of its major development. For example, EL8.4 is presently shipping Qt5.12 and EL8.5 will introduce Qt5.15. The eventual transition to Qt6 may prove differently.

Can XWayland be considered a viable stopgap at all? I don't know enough about its restrictions, but I had read in the past that color-management was one of them. E.g. it only operates in a SDR sRGB mode. Please correct me if that is not the case, it's been a long time since I last looked into this specific area.

Cheers,
Mike

[Christian Fredrik Schaller]

Hi Laurence,
The very latest NVidia driver does have Wayland support (or more precisely XWayland support for full X.org backwards compatibility). I am sure there are bugfixes needed and we are working closely to address those as they come in, so my expectation is that by the time we have the fully rolled out in RHEL we should have it pretty polished. That said the OpenGL support exposed through EGL from the NVidia driver up to Wayland and XWayland doesn't yet have all the special NVidia OpenGL extensions added over the years. If anyone on this list, maybe especially from the ISVs in the space are able to let us know which of those NVidia extensions are actually used that would be a great help in terms of helping both us and NVidia prioritize what to bring over from GLX to EGL. Our understanding is that the ones tied to stereoscopic support are of interest, but we don't really know which else are actually being used.

Sincerely,

Christian Schaller

Senior Engineering Manager

Red Hat

[Christian Fredrik Schaller]

Well x.org only does SDR so XWayland naturally only does SDR too, but our goal is to help finalize the HDR protocol mentioned in the blog from Collabora you link to above to get HDR support into Wayland and then figure out how we can expose HDR support in XWayland too if possible. XWayland should be a viable stopgap that is the very reason we are developing it :)

Christian