AMD AMF Support in FFmpeg Enhanced for Vulkan Video: What You Need to Know

Better AMD AMF support in FFmpeg for better encoding (of) via Vulkan Video

Another set of pieces from AMD improves the project FFmpeg interface with AMD’s AMF framework (Advanced Media Framework) to make FFmpeg run better with AMD GPUs, especially in terms of system access to GPU capabilities. This is a necessary function for running video cases on AMD GPUs through the Vulkan Video interface.

For example, AMD includes here hwcontext_amf for using X.264/AVC, H.265/HEVC and AV1 video format decoders on AMD GPUs. The patches also enable AMD SmartAccess video support for AMF encoders, where multiple encoders and decoders can be run in parallel via multiple VCN hardware settings (video engine in AMD GPUs). The company also adds two new filter designs vpp_amf (for simple scaling and color conversion) a sr_amf (for more advanced scaling in FSR style) – AMF encoder side support in FFmpeg is already out of the box, AMF in FFmpeg we have been together for 4 years. It is included hwcontext_amf allows shared AMF content for encoder, decoder and AMF-based filters (such as those in FFmpeg), all without copying data from/to RAM. Dmitry Ovchinnikov from AMD to that supplies, the result is significant speedup when the entire video process is run within a single AMF pipeline. Additionally, AMF provides, or will provide in the future, more capabilities than standard DX12 and Vulkan encoders due to higher connectivity with enterprise GPUs.

In general, the main innovation that leads to the possibility of significant qualitative improvement, especially video enhancement processes, is the implementation of FSR-type algorithms, because FSR algorithms can be used not only with Radeons, but also with Other GPUs, and it. It can be assumed that the implementation will eventually reach the general level.

SDL3 supports PipeWire Camera

The list of next-generation SDL3 framework capabilities continues to grow. Support was recently added for such a PipeWire interface (where SDL3 uses PipeWire instead of PulseAudio, which is the current Linux trend anyway), now SDL3 can also PipeWire Camera, with thanks to the SDL applications that can capture images from cameras. No one else is responsible for supporting this part of the PipeWire interface Wim Taymans from Red Hat, the original author of the PipeWire project. The news is now at the level of the already included pull request.

Two weeks in KDE: the path to Plasma 6.1

last week Nate Graham he reported, that more of the bugs reported in Plasma 6.0 are a thing of the past and the developers are now focusing more on the work leading up to the upcoming Plasma 6.1 release, with several other UI improvements. So there were no revolutionary things happening, just the usual honest work to develop the project.

In my opinion, the main innovation that improves usability went to the Kate editor (as part of version 24.05), when Kate not only considers recently opened files, but also the those saved or closed.

The panel of icons in the Kickoff and Kicker menus has a new limited size, so that there is no risk of growing to large sizes (it will appear in Plasma 6.0.5). In the system preferences, it will no longer be possible (within the same version of Plasma or higher) to select Adwaita from GNOME or High Contrast as the default system image set, because despite they say they are compatible with FreeBestkop, they are not and it will break everything in KDE if used.

Plasma 6.1 brings a change to how KDE determines which screen to place a new window on. Decisions will now be made based on the user’s last actions, which should better reflect where the user wants to open that window. The reset dialog of the global theme of the environment will appear better than it will be changed. The power and battery widget shows the power profile settings in use powerprofilesctl. Some of the icons in the Breeze theme then received a suitable symbolic version for sizes 16 and 22 pixels (that will appear with Frameworks 6.2).

In the last few days, many changes have been introduced to the project, which has been worked on for several weeks. how come Nate Graham he jokingly states in the introduction, Isn’t it big? Isn’t it great to have a bunch of free news week after week, no price tag, no ads, no snooping, no action, no subscriptions, no attention. And not just within KDE, but also the entire system that KDE itself is built on. Well, let’s get to it.

The news of the last few days includes, for example, selecting all items in a folder if the user double-clicks on the back of that folder (it is possible to set another event for this task, enter a standard command in the Terminal). Elisa can even move the content of the playlist on the basis of albums, not only songs (that is, she does not mix songs, but albums as whole units, after all, which was always mixing the legendary. The Wall no less prayer The best of Eva and Vasekhe knows what life-threatening suffering is like).

There is a new page in the system settings where you can enable and configure remote access based on the Remote Desktop Protocol. For now, the current UI is still a bit rough, waiting for the unification part of the code, which will solve some errors in the alignment of elements.

KWin on Wayland can now be configured to extract color image information from the monitor’s EDID metadata, Nate but immediately warn that this information is often reported incorrectly by monitors, so you should always make sure that your particular monitor is not real (this news will be in Plasma 6.2).

Spectacle informs you that screen recording is complete. On Plasma 6, it is also clearer how to exit the panel options dialog, a “Done” button has been added to the corner. For QML-based KDE applications, smooth scrolling is optional, although still on by default. Newly, third-party applications can override this setting for their needs (also Plasma 6.2). The small dialogs inside the windows of applications based on QtQuick have a new look that does not contain any unnecessary objects (going to Frameworks 6.3).

The Nvidia driver will be open by default for Turing and later

In the not too distant future, the standard Nvidia driver for generations of GeForce graphics cards will change from Turing, i.e. RTX 2080 Ti and higher (or Ada generation and higher in terms of virtualization). In addition to the nouveau project that still exists, Nvidia itself, which came out with a basic open driver the year before, did not recommend a closed driver, but this open option. It follows from the tests that it achieves almost the same performance with the closed controller.

The change will occur when driver version 560 is released, in which it will be possible to continue enjoying the closed driver (option --kernel-module-type=proprietary). Aaron Plattner from nvidia also saysthat everything will be ready to run with a classic installation using .run file, Linux distributions using a packaging system to install Nvidia drivers may need to make some additional changes.

Phoronix reminds that even the open nvidia driver is still out of the treesits in its own GitHub repository.