Language Selection

English French German Italian Portuguese Spanish

Graphics: Pixman, Vulkan, Sway and NVIDIA

Filed under
Graphics/Benchmarks
  • Pixman 0.38 Released With Meson Build System Support

    Pixman 0.38 is out this morning to kick off a new week of open-source software releases. Pixman is the pixel manipulation library used by the X.Org Server, Cairo, and other Linux software projects.

    The Pixman 0.38 release isn't the most exciting update and in fact only a handful of changes over Pixman 0.36 from last November, which itself was the first update to this library in three years. Pixman doesn't see too much activity these days thanks in part to more software using Vulkan and OpenGL to benefit from GPU hardware acceleration. The two primary changes of Pixman 0.38.0 is introducing Meson build system support and implementing floating point gradient computation.

  • Vulkan 1.1.100 Released Ahead Of Vulkan's Third Birthday

    Vulkan 1.1.100 was published this morning as the latest version of this high-performance, multi-platform graphics and compute API.

    While the patch version rolled over to 100, that's about as exciting as this update gets to Vulkan API with no major changes to mark this milestone. There aren't any great new extensions or major changes to this version number, but just some documentation/specification clarifications and corrections.

  • Sway 1.0 Close To Release For This Very Promising Wayland Compositor

    Out today is the second release candidate of the feature-packed Sway 1.0 Wayland compositor that continues to be inspired by the i3 window manager.

    Since last week's Sway 1.0 RC1, the compositor entered its feature freeze until the stable release happens. As such, in today's Sway 1.0 RC2 update is just a variety of bug/regression fixes.

    The Sway 1.0 development over the past number of months has brought a lot of improvements and new features from multi-GPU support, support for new Wayland protocols, video capture support, integration around the WLROOTS library, tablet support, and many other additions.

  • NVIDIA's VDPAU Picks Up HEVC 4:4:4 Support

    While NVIDIA is no longer active promoting their Video Decode and Presentation API for Unix "VDPAU" in favor of the cross-platform, CUDA-focused Video Codec SDK with NVENC/NVDEC, the VDPAU library still sees some rare activity from time to time.

    As the first commits since November, last week libvdpau added support for the HEVC 4:4:4 profile to the VDPAU API. This support for H.265 4:4:4 video decoding was added to the libvdpau API and presumably will be exposed by the NVIDIA proprietary driver shortly if it's not already in place with its own VDPAU library build.

More in Tux Machines

FreeBSD Quarterly Status Report

We also provide some up to date information about the status of our IRC channels Read more Also: FreeBSD In Q2'2019 Saw Updated Graphics Drivers, Continued Linux Compatibility Layer

DragonFlyBSD Pulls In AMD Radeon Graphics Code From Linux The 4.7 Kernel

It was just last month that DragonFlyBSD pulled in Radeon's Linux 4.4 kernel driver code as an upgrade from the Linux 3.19 era code they had been using for their open-source AMD graphics support. This week that's now up to a Linux 4.7 era port. François Tigeot who continues doing amazing work on pulling in updates to DragonFlyBSD's graphics driver now upgraded the Radeon DRM code to match that of what is found in the upstream Linux 4.7.10 kernel. Read more

Android Leftovers

TenFourFox FPR16b1 available

FPR16 got delayed because I really tried very hard to make some progress on our two biggest JavaScript deficiencies, the infamous issues 521 (async and await) and 533 (this is undefined). Unfortunately, not only did I make little progress on either, but the speculative fix I tried for issue 533 turned out to be the patch that unsettled the optimized build and had to be backed out. There is some partial work on issue 521, though, including a fully working parser patch. The problem is plumbing this into the browser runtime which is ripe for all kinds of regressions and is not currently implemented (instead, for compatibility, async functions get turned into a bytecode of null throw null return, essentially making any call to an async function throw an exception because it wouldn't have worked in the first place). This wouldn't seem very useful except that effectively what the whole shebang does is convert a compile-time error into a runtime warning, such that other functions that previously might not have been able to load because of the error can now be parsed and hopefully run. With luck this should improve the functionality of sites using these functions even if everything still doesn't fully work, as a down payment hopefully on a future implementation. It may not be technically possible but it's a start. Read more