Language Selection

English French German Italian Portuguese Spanish

Graphics: Zink, VA-API, NVIDIA's NVAPI SDK

Filed under
Graphics/Benchmarks

  • Mike Blumenkrantz: Extensions

    Usually I cover in-depth looks at various chunks of code I’ve been working on, but today it’s going to be a more traditional style of modern blogging: memes and complaining.

  • New VA-API H.264 decoder in gst-plugins-bad

    Recently, a new H.264 decoder, using VA-API, was merged in gst-plugins-bad.

    Why another VA-based H.264 decoder if there is already gstreamer-vaapi?

    As usual, an historical perspective may give some clues.

    It started when Seungha Yang implemented the GStreamer decoders for Windows using DXVA2 and D3D11 APIs.

    Perhaps we need one step back and explain what are stateless decoders.

  • NVIDIA open sourced part of NVAPI SDK to aid 'Windows emulation environments'

    NVIDIA sneakily put out a little open source release recently, with a part of the NVAPI SDK now under the MIT license.

    This was mentioned by the crew working on the DXVK translation layer in the VKx Discord, who sent along word to me as well. NVAPI is NVIDIA's core software development kit that allows direct access to NVIDIA GPUs and drivers on all Windows platforms.

    Now, that doesn't sound interesting for Linux obviously but here's why this actually is important: in the NVAPI Open Source SDK, it directly mentions that the contained "nvapi.h" file that's now provided under the MIT license was done to enable "open source re-implementations of NVAPI for Windows emulation environments"—so the Wine and Proton compatibility layers are what they're getting at without naming them directly.

WebRender and Firefox

  • Mozilla GFX: moz://gfx newsletter #54

    Bonjour à tous et à toutes, this is episode 54 of your favorite and only Firefox graphics newsletter. From now on instead of peeling through commit logs, I will be simply gathering notes sent to me by the rest of the team. This means the newsletter will be shorter, hopefully a bit less overwhelming with only the juicier bits. It will also give yours-truly more time to fix bugs instead of writing about it.

    Lately we have been enabling WebRender for a lot more users. For the first time, WebRender is enabled by default in Nightly for Windows 7 and macOS users with modern GPUs. Today 78% of Nightly users have WebRender, 40% on beta, 22% release enabled. Not all of these configurations are ready to ride the trains yet, but the numbers are going to keep going up over the next few releases.

There Finally Is Work On Shipping Mozilla's WebRender...

  • There Finally Is Work On Shipping Mozilla's WebRender For Some Linux Environments

    While Mozilla has been gradually enabling WebRender out-of-the-box in more Windows configurations with succeeding Firefox releases, up to now there hasn't been much visible effort in getting WebRender enabled out-of-the-box for any Linux configurations. But fortunately that is finally changing.

    Linux users have been able to opt-in to this generally faster code path via MOZ_WEBRENDER=1 among other WebRender tunables within Firefox. This is for the GPU-based Rust-written rendering engine available within Firefox currently and also at the heart of their Servo effort. But as more Firefox installations on Windows have been seeing WebRender enabled, Linux users have not.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Today in Techrights

Android Leftovers

LibreOffice 6.4.5 finally for Slackware 14.2

The Document Foundation recently released version 7.0.0 of their Libre Office suite of applications. The packages for Slackware-current can be found in my repository. But the situation for Slackware 14.2 used to be different – I got stuck after LibreOffice 6.2 because the newer source releases (6.3 and onwards) require versions of system software that our stable Slackware 14.2 platform does not offer. From time to time during the last year, when there was time and the build box was not compiling packages, I messed around with the libreoffice.SlackBuild script in futile attempts to compile recent versions of LibreOffice on Slackware 14.2. I failed all the time. Until last week. After I had uploaded the new KDE Plasma5 packages to ‘ktown‘, I had an epiphany and decided to use a new approach. What I did was: question all the historic stuff in the SlackBuild script that got added whenever I needed to work around compilation failures; and accept that the compilation needs newer versions of software than Slackware 14.2 offers. The first statement meant that I disabled patches and variable declarations that messed with compiler and linker; and for the second statement I stuck to a single guideline: the end product, if I were able to compile a package successfully, has to run out of the box on Slackware 14.2 without the need to update any of the core Slackware packages. Read more

Web Browsers: New Tor RC, Firefox/Mozilla Trouble, and Web Browsers Need to Stop

  • New release candidate: 0.4.4.4-rc

    There's a new alpha release available for download. If you build Tor from source, you can download the source code for 0.4.4.4-rc from the download page. Packages should be available over the coming weeks, with a new alpha Tor Browser release likely in the coming weeks.

    Remember, this is a release candidate, not a a stable release: you should only run this if you'd like to find and report more bugs than usual.

  • Mozilla is dead

    If Mozilla wants to survive, the management will be fired with unearned compensation, the most important departments will be strengthened, products that nobody ordered will be discontinued and the organization will be limited to its core competence. Browser, email, security, adaptability and the fight for a free Internet. And they work with all their might to ensure that the products will become an integral part of everyday life and all operating systems.

    Three months. That’s all the time they have for a clear signal. After that, users have to make a decision. Unfortunately, it will probably only be something with chromium.

    Poor Internet.

  • Web browsers need to stop

    I call for an immediate and indefinite suspension of the addition of new developer-facing APIs to web browsers. Browser vendors need to start thinking about reducing scope and cutting features. WebUSB, WebBluetooth, WebXR, WebDRM WebMPAA WebBootlicking replacing User-Agent with Vendor-Agent cause let’s be honest with ourselves at this point “Encrypted Media Extensions” — this crap all needs to go. At some point you need to stop adding scope and start focusing on performance, efficiency, reliability, and security5 at the scope you already have.