[HN Gopher] Firefox 94 to start using EGL on Linux
___________________________________________________________________
Firefox 94 to start using EGL on Linux
Author : TangerineDream
Score : 334 points
Date : 2021-10-30 09:28 UTC (13 hours ago)
(HTM) web link (mozillagfx.wordpress.com)
(TXT) w3m dump (mozillagfx.wordpress.com)
| encryptluks2 wrote:
| About time. I don't know why, but for me in Linux Chromium has
| had much better performance than Firefox. Maybe this will help.
| flipbrad wrote:
| The only websites I've noticed Chromium having an advantage,
| are those run by or embedding Google content (eg Google maps)
| exyi wrote:
| It also seems to me. At least it motivates me to use anything
| which is not owned by Google :]
| iotku wrote:
| At this point I have enough confidence in Google's developers
| to consider bad performance in Firefox not an accident.
| Drdrdrq wrote:
| It would be interesting to profile these sites and make PRs
| for Firefox to fix any possible issues, then see how long
| it takes for Google to find new ways to make them slow
| again.
| watermelon0 wrote:
| It's much more believable that they are developing with
| Chromium in mind, and testing primarily on it.
|
| I've seen many webapps that are completely unrelated to
| Google, that are more performant on Chromium browsers, just
| because most developers are using them for development.
| It's also easier to justify spending time fixing
| bugs/improving performance if it affects the majority of
| users, instead of spending effort for 4% of users.
| Symbiote wrote:
| None of that is an accident, at a company with Google's
| experience and expertise with web browsers and apps.
| dralley wrote:
| Google has, in the past, made YouTube reliant on non-
| standard browser APIs and shipped a polyfill for other
| browsers that had _terrible_ performance.
|
| It's not just that they passively focus on Chromium, they
| will deliberately trash performance on _every other
| browser_ without a second thought.
| diegocg wrote:
| Google didn't have much of a choice. It's either a
| polyfill or not supporting Firefox at all.
|
| Or having two different frontends, or stopping feature
| development to make Firefox developers happy. Which are
| terrible choices.
|
| And going beyond of what standards offer is pretty much
| how web evolution had always happened.
| dralley wrote:
| What? Of _course_ they had a choice.
|
| Google built their redesign on top of a prototype set of
| APIs that didn't end up being standardized. That's _their
| own fault_ , and it should be _their problem_.
|
| It's not just Firefox devs, it's _everyone else_ apart
| from Chrome, because Chrome had gone and implemented said
| APIs that were never standardized, so they didn 't need a
| polyfill. And I would bet money that ShadowDOM v0 would
| have been removed from the Chrome codebase earlier if not
| for the fact that Youtube was using it - they wouldn't
| have forced themselves to use the same polyfill as
| everyone else.
|
| Shipping a new, standards incompliant frontend was a
| _choice_ , not an immutable fact of nature. There was
| nothing wrong with the previous frontend apart from the
| fact that nobody is going to get promoted for _not_
| shipping the new thing. And since the consequences of
| shipping impact everyone _except_ for Google, who cares,
| let 's ship the garbage UI anyway.
|
| Don't make excuses for this kind of behavior. Google
| absolutely has the resources to do these things properly
| but they didn't.
| floatboth wrote:
| It didn't actually have bad performance. I never had
| performance problems on YouTube, and I even made my own
| apps with Polymer / Web Components v0 (before v1 became a
| thing) purely in Firefox (never even tested in Chromium),
| it all worked pretty well.
| the8472 wrote:
| https://twitter.com/johnath/status/1116871231792455686
| mhd wrote:
| For a while. Wirth's Law still applies. Web developers will
| find further ways to mess up rendering some basic shapes and
| letters.
| marginalia_nu wrote:
| I think firefox has cache management problems. I got to the
| point where even opening an nginx test page off localhost took
| 1-2 seconds, but clearing the cache seems to have fixed it back
| to tolerable levels again.
| lobocinza wrote:
| If you can afford, just set on disk cache to 0 and increase
| on memory cache. Firefox have bad defaults.
| butz wrote:
| As Firefox is lagging a bit with new feature implementation,
| Chromium based browsers usually are using native implementation
| that is faster and Firefox is left using slower polyfills. And
| web app developers sure love using most recent web browser
| features and APIs.
| cute_boi wrote:
| well most api that is not implemented in firefox has high
| probably of not being implemented in safari too. So I don't
| think web app developer should use recent web browser
| features and API that is available in chromium browser only.
| 20-30% represent a large number of users so I think devs
| should show more pragmatism.
| gtirloni wrote:
| I think Chrome/Chromium don't use hw acceleration on Linux,
| right?
| Comevius wrote:
| With Chromium 95 and Nvidia 470.74 driver for me hardware
| acceleration is enabled for canvas, and can be enabled for
| rasterization. For video decode it can be enabled, but it's
| VA-API, which is not supported by Nvidia. Vulkan can be
| enabled. GpuMemoryBuffers is software only.
| fubbyy wrote:
| Have you tried vulkan? Curious if it offers any performance
| benefits.
| encryptluks2 wrote:
| Actually, that is one the main reasons I get better
| performance on Chromium is because you can use HW
| acceleration. I just use some of the settings documented in
| the Arch wiki.
|
| Firefox isn't terrible, but there is a noticeable startup
| lag and I get random freezes a lot more often.
| eptcyka wrote:
| It does, if it deems your drivers good enough.
| morsch wrote:
| Will you be affected? Here's the gist from the article: _As of
| Firefox 94, users using Mesa driver >= 21 will get it by default.
| Users of the proprietary Nvidia driver will need to wait a little
| bit longer as the currently released drivers lack an important
| extension. However, most likely we'll be able to enable EGL on
| the 470 series onwards. DMABUF support (and thus better WebGL
| performance) requires GBM support and will be limited to the 495
| series onwards._
|
| Ubuntu 21.10 currently comes with the 470 series driver.
| mnd999 wrote:
| Even Arch doesn't ship the 495 yet. It's coming though.
| Svenstaro wrote:
| Well in Arch we have the drivers in testing with an extended
| period to give users a chance to report issues. You can
| already get them and help us test! We'll likely move them
| next week.
| 5e92cb50239222b wrote:
| You're doing God's work. I don't use nvidia drivers, but do
| enjoy my Arch Linux installations very much. They are
| always up to date, but very rarely break in practice (IME,
| YMMV). Thanks for everything you do.
| dathinab wrote:
| Uh, through this article I noticed that I missed a juicy but if
| news:
|
| Nvidea seems to jump on the GBM wagon, at least for some GPUS.
| lucb1e wrote:
| For anyone else as uninitiated as me:
|
| > Generic Buffer Management (GBM) is an API that provides a
| mechanism for allocating buffers for graphics rendering tied to
| Mesa. GBM is intended to be used as a native platform for EGL
| on DRM or openwfd. The handle it creates can be used to
| initialize EGL and to create render target buffers.
|
| Where
|
| > The Direct Rendering Manager (DRM) is a subsystem of the
| Linux kernel responsible for interfacing with GPUs of modern
| video cards. DRM exposes an API that user-space programs can
| use to send commands and data to the GPU
|
| https://en.wikipedia.org/wiki/Mesa_(computer_graphics)#Gener...
| and https://en.wikipedia.org/wiki/Direct_Rendering_Manager
|
| What does it mean for nvidia to jump on the GBM bandwagon?
| Firefox would just talk (perhaps via some intermediate API like
| EGL or BGM) to the Linux kernel for talking to an nvidia card,
| if I understand it correctly?
| yissp wrote:
| With the proprietary driver, the GPU is controlled by their
| closed-source kernel module, so Mesa's GBM code wouldn't know
| how to talk to it. However, as of the latest version, NVIDIA
| is shipping a GBM back-end library that Mesa can load which
| is able to talk to their module.
| lucb1e wrote:
| So Firefox, not using GBM but EGL, would not be able to
| make use of the proprietary driver and has to talk to DRM?
| Can two kernel modules even use the same card at the same
| time?
| pxc wrote:
| > Can two kernel modules even use the same card at the
| same time?
|
| yes, I'm not sure how everything is divvied up. NVIDIA
| ships multiple kernel modules in their driver, and one of
| them is called 'nvidia_drm'. So idk, maybe you have to
| use their DRM implementation or something
| nextaccountic wrote:
| But what does this mean for applications that use Vulkan?
| matheusmoreira wrote:
| I wonder if nvidia will ever integrate into the kernel
| properly. Using their drivers is such a poor user
| experience.
| 1_player wrote:
| Yes, the latest stable version 495 has GBM support.
| hedgehog wrote:
| Does anyone know if this will make Firefox on headless setups
| (like Xvfb + VNC) work better?
| Zardoz84 wrote:
| do you know that Firefox have a headless mode and you not
| anymore to use Xvfb ?
| bno1 wrote:
| I already force-enabled EGL in firefox 93 on Arch Linux with the
| 470.74 nvidia driver, and the performance is stellar compared
| with what it used to be. Before EGL all desktop applications
| (including firefox) would stutter when a video was playing in
| firefox.
|
| I did not encounter any bugs so far.
| Arisaka1 wrote:
| Wasn't there friction when using nvidia's proprietary drivers,
| as Nvidia's video acceleration depends on VDPAU compared to
| Intel/AMD using VA-API?
|
| The only reason I haven't made the full change for Linux yet is
| because I watch a lot of Twitch.tv and the CPU usage hits
| 45-50% on average even at 720p.
| bno1 wrote:
| Yes, I tried to make video accel work but didn't succeed.
| There's a vaapi driver for vdpau, but it crashes when I try
| using it. In some firefox issue there was someone mentioning
| that video accel needs dmabuf, which needs gbm, so the 490
| driver might solve the issue.
| oynqr wrote:
| Have you tried the streamlink gui client? You can play
| streams in mpv/vlc/whatever that way
| Arisaka1 wrote:
| I thought they're trying to actively block it as it allowed
| people to watch without ads.
| vzaliva wrote:
| I thought video playback is not using OpenGL.
| AnssiH wrote:
| But the video is still usually rendered to an OpenGL surface,
| so there is interaction between them.
| ronjouch wrote:
| Video playback is accelerated in many apps, for example VLC
| 3.x defaults to it.
|
| In web browsers, things are more delicate because videos live
| within the complex context that is a webpage -with its own
| layer of hardware acceleration!-, and failures can be brutal
| depending on your browser, hardware and driver quality
| (crashes, video corruption, etc).
|
| The pain-in-the-ass-ness to enable it on a given browser
| varies with time and browser/OS and along regressions, stack
| changes, and maintainer priorities. From personal experience
| during the past years, it has never been great on Linux:
|
| - In Firefox, regressions have been frequent.
|
| - In Chrome, the feature is here but Google disables it at
| build time in their official builds (my personal intuition is
| that they do enable it for their Chromebooks, but they don't
| want to support the wild west of broader Linux configuration
| and old/broken driver fun). However, out of official Chrome
| builds, several distributions builds (Arch, Debian) of
| Chromium now enable it at build time, so it's possible to try
| to use it.
|
| So, it's finnicky to enable, but sometimes feasible, until
| it's no longer :D . To give it a try on a Linux box, the
| well-maintained Arch wiki is what you want (and these
| sections are mostly not specific to Arch):
|
| - Firefox: https://wiki.archlinux.org/title/Firefox#Hardware_
| video_acce...
|
| - Chrome: https://wiki.archlinux.org/title/Chromium#Hardware_
| video_acc...
| vetinari wrote:
| There are two steps in the task of hw assisted video
| playback: 1) video decoding, i.e. going from compressed
| stream to uncompressed, offscreen video frame, and 2)
| compositing video with all the other surfaces the video
| playback application uses -- the decoded frames are usually
| put into OpenGL (or Vulkan, whatever) texture and then
| composed with the rest.
|
| When you do 1) on the GPU (well, not exactly GPU, but video
| decode block on the videocard, but that's not really
| important now), you end up with decoded frame in VRAM.
| Reading it back to system RAM, just to push it back to VRAM
| elsewhere is expensive (if the graphic is not UMA, then you
| go via PCIE back and forth) and unnecessary in the end, it is
| more efficient to have some way to directly share content
| from 1) into 2) already in VRAM.
|
| For that, both subsystems must support some way of sharing
| memory buffers. VA-API (for 1) and Mesa (for 2) support DMA-
| BUF, so that's the reason why it is used here.
| remexre wrote:
| Though Vulkan has video decoding built in, so eventually
| everything will hopefully unify to use that and we can
| avoid needing multiple separate subsystems depending on
| vendor...
| __s wrote:
| Reading linked issue, it seems like you might run into issues
| after suspend/resume
| bno1 wrote:
| Now that you mention, I did have an issue after a suspend.
| All text was missing inside firefox, restarting it resolved
| the issue. But I keep my laptop plugged in and open 99% of
| the time with presentation mode enabled, so this is extremely
| rare for me.
| fghjfghk wrote:
| It seems to pretty consistently break after suspend, with
| the text looking like an ms-dos machine with bad vram.
|
| I enabled EGL in response to seeing your comment this
| morning, then found myself having to turn it back off after
| the very first suspend/resume.
| superkuh wrote:
| Firefox has become an excellent operating system but somewhere
| along the way it became a pretty marginal browser. Still, getting
| hardware acceleration working on linuxes was serious work and
| it's not like this guy would've been fixing the UI issues created
| in recent version if he wasn't doing this.
| snuser wrote:
| I may be weird but I really like the new UI
| 1over137 wrote:
| Does this affect the BSDs at all?
| floatboth wrote:
| Yes, nearly everything about "Linux" in Firefox applies to BSD.
| vzaliva wrote:
| I am curious to see benchmarks on promised improved perofmance
| and reduced battery usage. Are there any?
| smitty1e wrote:
| For those needing an EGL LEG-up:
|
| https://en.wikipedia.org/wiki/EGL_(API)
| tombh wrote:
| Note that Wayland users are already using EGL in Firefox, so I
| don't think this makes any difference to them?
| kzrdude wrote:
| Does Firefox ship one binary that can do both X and Wayland?
| How do they probe for it?
| maxnoe wrote:
| There are env variables set by the session
| lucb1e wrote:
| How do you change those? This is something I remember
| trying to look up some time ago (to set PATH also for the
| Alt+F2 'run command' dialog in Cinnamon) but I didn't find
| it.
| md8z wrote:
| Wayland uses WAYLAND_DISPLAY, X uses DISPLAY.
| lucb1e wrote:
| I think you misunderstood my question. Indeed with
| `DISPLAY=:0 glxgears` I can run something on my screen
| from a different virtual terminal (perhaps even an ssh
| session), but what I mean is that my desktop environment
| takes the PATH environment variable from somewhere and I
| don't know where. When I run 'josm' in the Alt+F2 dialog,
| it can't find the command, even though in my bashrc I
| configured my PATH to include ~/bin/.
| the8472 wrote:
| Environment variables are defined in multiple files. most
| desktop environments launch in a systemd user session, so
| one option is to use that[0]. Then are .xsession, scripts
| specific to the DE, /etc/environment and a bunch of other
| stuff I am forgetting.
|
| [0] https://wiki.archlinux.org/title/systemd/User#Environ
| ment_va...
| nightfly wrote:
| A TTY like you get in your "ALT+F2" is a new
| login/session shell and uses .bash_profile rather than
| .bashrc (which is invoked when you create a new bash
| process in an already existing login session like when
| you open a terminal window). There are lots of moving
| pieces, but I've found the easiest way to get the same
| behavior in both is to have my .bash_profile source my
| .bashrc.
| Scramblejams wrote:
| How can one tell if Firefox is already using EGL?
| sweetsocks21 wrote:
| If you go to about:support and scroll to the end of the
| graphics section you should see two entries:
|
| X11_EGL
|
| DMABUF
|
| and should say something like "available by
| default"/enabled or similar wording. Otherwise it'll
| either say unsupported/disabled or will be missing.
| [deleted]
| solarkraft wrote:
| > For OpenGL on X11 most programs use GLX, while its successor,
| EGL, gets used on Wayland, Android and in the embedded space
|
| The headline is kind of wrong, then. This is about X11. Firefox
| on modern (Wayland) desktops is already using EGL.
| CameronNemo wrote:
| That's too bad. My WebGL performance is pretty bad.
| roca wrote:
| It's still possible for EGL to not be enabled on Wayland for
| various reasons.
| skohan wrote:
| I'm not really sure what EGL is, but will Vulkan also run on top
| of EGL?
| ZiiS wrote:
| No Vulkan dose not need/use EGL. It nativity talks to
| Wayland/X11.
| jabl wrote:
| Vulkan has WSI, which is roughly equivalent to GLX or EGL in
| the OpenGL world.
|
| https://github.com/KhronosGroup/Vulkan-Guide/blob/master/cha...
| corysama wrote:
| It's a spec for how GPU APIs can share data without necessary
| copying and converting through CPU memory. Mainly because the
| OpenGL specification explicitly does not define anything to do
| with windowing. But, EGL is not just and OpenGL - XWindows
| bridge. CUDA, GStreamer and several other APIs use it to
| communicate.
| floatboth wrote:
| EGL is primarily about windowing system integration, it's
| what lets you initialize an OpenGL context in the first
| place.
|
| It doesn't really accomplish interop between different APIs
| on its own, though of course various interop methods are
| based on it -- e.g. if you want to import a dmabuf, you'd use
| EGL_EXT_image_dma_buf_import. But, say, on the Vulkan side
| you'd use VK_EXT_external_memory_dma_buf -- there is no EGL
| with Vulkan, Vulkan has its own WSI subsystem.
| johnvega wrote:
| "For most cases, you do all the actual rendering work in GL or
| GLES contexts, which you create with WGL, CGL, GLX, or EGL,
| depending on your platform.
|
| GL and GLES do the actual rendering. EGL and friends are
| basically just the glue layer to get things to the screen.
| (Well, to the window manager)"
|
| https://www.reddit.com/r/opengl/comments/11q0oz/what_is_the_...
| matheusmoreira wrote:
| > EGL and friends are basically just the glue layer to get
| things to the screen. (Well, to the window manager)"
|
| EGL can also be used directly with kernel mode setting and
| buffer management. No window managers necessary!
|
| A simple example I found:
|
| https://github.com/siro20/XlessEGL/blob/master/eglkms.c
___________________________________________________________________
(page generated 2021-10-30 23:00 UTC)