
Firefox 75 on Wayland now to have full WebGL, working VA-API acceleration - nirv
https://www.phoronix.com/scan.php?page=news_item&px=Firefox-75-Wayland-Great-Shape
======
EricRiese
There's a $380 bounty for this [1]. If you fixed this, please collect this.
You deserve it. I hope this doesn't get lost just because it got fixed in a
different ticket number.

[1] [https://www.bountysource.com/issues/55506502-add-va-api-
hard...](https://www.bountysource.com/issues/55506502-add-va-api-hardware-
decoding-support-on-linux)

~~~
abrowne
That's not a bad "tip", but keep in mind the person who worked on this (Martin
Stránský) is employed by Red Hat to "work on mozilla packages (Firefox,
Seamonkey, Thunderbird) in Fedora and Red Hat."¹

1: [https://people.redhat.com/stransky/](https://people.redhat.com/stransky/)

~~~
thayne
Assuming he worked on it on company time, wouldn't that mean Red Hat could
collect it?

------
dzonga
for linux users, this is the best Firefox news in a loooong long time. having
to copy paste links from youtube to smplayer for mpv hardware accelerated
video can be a PITA.

------
diafygi
Relevant comment for X11:

> (In reply to lilydjwg from comment #30)

>> I'm glad to here that, but what about support for Firefox on X11? Is it
given up?

> Hardware decoding is platform independent so it generally works under X11 as
> it's implemented as Bug 1616185.

> For whole playback chain see Bug 1610199 what's needed to be done fox X11.

> I was closing this one as it refers to HW decode only, not the playback.

> The overall video playback is tracked at Bug 1210726.

[https://bugzilla.mozilla.org/show_bug.cgi?id=1210727#c31](https://bugzilla.mozilla.org/show_bug.cgi?id=1210727#c31)

------
miguelmota
As a regular linux user should I switch to wayland from xorg? will I notice
performance improvements?

~~~
jhoechtl
Depends on the window manager you are using.

If you are coming from i3 the move to sway is a no-brainer and works great
(sway is wayland only). Firefox, thunderbird, Libreoffice all work great and
look great, i.e. sharp when you need scaling for example. Sway is to thank for
base work they did for other distros like a wayland clipboard protocol all the
others are using.

Second comes Gnome. No issues. Gnome laid the gruntwork of porting gtk3 to
wayland which works great.

Third maybe KDE. Still two years to come. KDE plasma is suffering from
arguably better design decisions like client side decorations vs. Gnome
serverside decorations but as many users use GTK based apps those GTK apps do
not yet play nicely with the KDE design decisions. As such the brave KDE folks
have to implement things themselves while those relying on GTK are done. QT is
fine with wayland but not everything is QT.

That's all only true if you are not using NVidia hardware.

~~~
eikenberry
Sorry, but you seemed to have missed answering the OPs question... Why they
should switch to Wayland? If there were any benefits to using Wayland, like
performance improvements, etc.

Personally, the one real gain I've read about previously is no tearing when
watching videos or scrolling fast and security improvements. Also now these
Firefox performance improvements. But that's about it.

Are there any other benefits that a normal user would see?

~~~
jasondclinton
Here are the real, user-visible benefits that I am aware of, at the moment:

    
    
      * Fractional scaling of monitor outputs
      * Multi-touch gestures for e.g. switching desktops
      * Security sand-boxing of apps
      * Tear-free video
    

As the original link shows, though, the architecture has much better
abstractions for software engineers to work with so developer quality-of-life
is improved, too.

~~~
jasondclinton
I forgot the most important one: per-output scaling (integer or fractional).
This allows you to have your HiDPI laptop display and an external 1080p
monitor set to different scale factors.

------
shmerl
What's missing so far is VAAPI support for WebRTC. Apparently, Firefox is
using same libwebrtc as Chrome does, and it still doesn't support hardware
acceleration.

This results in some ugly behavior of WebEx for instance, which blocks video
in its WebRTC calls, since it assumes that "CPU is too weak" to handle it.
Cisco never fixed this issue.

------
ambrop7
The mention of DMA-BUF makes me suspect that it involves rendered video being
copied from the GPU to the main RAM and back to the GPU, which wastes energy.
Does someone have details about how the integration works?

~~~
cycloptic
It's the opposite. The point of using DMA-BUFs is that those are the handles
which are passed around, and the data never leaves GPU memory. The handles can
be directly accessed from EGL/Vulkan and used as render source/targets.

~~~
ambrop7
This is quite unclear to me. Is DMA-BUF so generic that the memory it refers
to can be in different types of RAM, including GPU RAM and CPU RAM?

~~~
floatboth
That is the whole point, one of the original use cases was passing around
buffers between different GPUs on dual-graphics laptops (PRIME)

~~~
ambrop7
Do you maybe know, when frames rendered by GPU 1 (e.g. fast GPU) need to be
sent to GPU 2 (e.g. slow GPU doing the compositing and outputting to the
monitor), how does the data actually get transferred? I can imagine the
following possibilities:

1) GPU 1 writes to CPU RAM, GPU 2 reads from CPU RAM

2) GPU 1 writes to GPU 2 RAM via PCI Express (DMA between devices)

3) GPU 2 reads from GPU 1 RAM via PCI Express (DMA between devices)

~~~
zlynx
AFAIK, GPU 1 writes directly to GPU 2 via PCIe.

Since GPU 2 is most often an Intel iGPU, that happens to also be CPU RAM.

------
new_realist
Does this work on Gnome i.e. with official Nvidia drivers?

~~~
sprash
At this point Wayland is nothing more than a 10 year old, over-hyped, tech-
demo. Why should Nvidia care about sub 1% of a sub 1% market?

~~~
DCKing
This is a strange opinion to express in general, but _really_ strange on this
news. Linux hasn't had hardware video acceleration in a browser for over a
decade when Windows and macOS did have it, precisely _because_ it was too hard
to support this use case within the restrictions of X11. The buffer sharing
trickery, combined with having to render web pages and a browser around it,
was just too hard to solve for years (within the limited attention X11 based
desktops get in general).

Linux finally has a graphics stack on which this isn't as much of a problem,
and it's received enough adoption that Firefox is now making changes for it.
And on that news you decide to comment that Wayland is a tech demo? This news
should tell you it's completely the opposite! Wayland seems to be finally
delivering.

~~~
AnIdiotOnTheNet
Parent is kinda right. Wayland was supposed to be this great next-gen display
protocol for Linux, finally doing away with the cruft of X and thereby making
development faster and easier while bringing modern features and yadda yadda.
Instead it has taken 10 years to kinda-sorta catch up to X and is still behind
its equivalents on Win/Mac.

~~~
DCKing
Wayland has a lot of problems, but they're adoption problems.

1) Wayland isn't a replacement for all of X.org. It's a replacement for much
of X11, the protocol. "Wayland is just a protocol" \- there's no wayland
binary on your computer like there is an xorg binary. All the
problems/limitations people commonly perceive with Wayland are _actually_
problems/limitations within Wayland _implementations_ like Mutter (Gnome) or
KWin (KDE) and lacking application support. There's really not that much that
"Wayland" as a project could deliver as it's just a protocol [1]!

2) Replacing something like your entire graphics stack requires a widespread,
coordinated effort to unify the various Linux distro's under it. That
widespread coordinated effort is not actually possible in the (by "design")
extremely fragmented Linux market. The only approach is to slowly let Wayland
implementations evolve, and there we have it.

Hot take: Wayland will not fully replace X11 the coming 10 years. There is no
fundamental solution to the two problems above. Many popular desktops (Xfce,
Cinnamon) have no plan to support Wayland at all. Some don't even want to. In
the future, there will be choices for graphics stacks on Linux leading to
further fragmentation.

[1]: The projects that should deliver here are: Gnome, KDE, other open source
desktops. Although I think using Gnome with Wayland is superior in many ways
to X11, it still has certain quite major shortcomings. It's also application
toolkits: Qt and Gtk work luckily, but Electron is waiting for some Chrome
renovations before supporting Wayland, and then there's stuff like Wine and
Java where the refactor/reward balance simply doesn't favor them. And
sometimes applications have to be updated to stop relying on using hardcoded
X11 stuff, and use agnostic Gtk/Qt/Freedesktop functionality.

There's a lot of history with X11 that we have to move away from, and the
incentives and coordination only allow for slow movement.

~~~
StillBored
Which is yet another case of fix the problems with the existing stack rather
than creating a new one.

Yah, you don't get to be a hero, and product arch, etc for making X work
better. I have yet to see a convincing argument that X couldn't have been made
more secure by bolting on another opt-in extension. Then once in place, like
GL ES, you start deprecating all the features used by basically no-one.

~~~
bigger_cheese
One of the big issues is there is a heap of legacy cruft in the existing X
Stack which makes trying to fix/enhance X difficult. From what I understand
the way it is written not easy to cleanly depreciate certain features like
you've suggested.

So I can totally see the appeal for a clean break from having to maintain
strict backwards compatibility with a stack that has its roots in the 1980's.

------
sitzkrieg
does this mean playing video will not use half of cpu available (at best)
constantly on linux now?

