Language Selection

English French German Italian Portuguese Spanish

Raspberry Pi Is Getting Vulkan Support

Filed under

The Raspberry Pi Foundation announced today that it has started working on implementing support for the open-source Vulkan graphics API for their Raspberry Pi single-board computers.

While the latest Raspberry Pi 4 board is OpenGL ES 3.1 conformant, the company also wants to add support for the famous open-source Vulkan driver, which provides high-efficiency access to modern GPUs and better performance than the older OpenGL driver.

But don’t get too excited about this because the Raspberry Pi Foundation is just getting started on this Vulkan on Raspberry Pi thing, which will be big for gaming on the tiny boards.

Read more

Raspberry Pi Foundation Gets Back To Working On A Vulkan Driver

  • Raspberry Pi Foundation Gets Back To Working On A Vulkan Driver - New Effort By Igalia

    With the V3D Gallium3D driver hitting OpenGL ES 3.1 compliance, the Raspberry Pi Foundation and their partners have turned to focusing on getting their Vulkan driver off the ground for Raspberry Pi 4 and future SBCs.

    Eric Anholt at Broadcom back in 2018 before leaving the company had started a Broadcom Vulkan driver for the VideoCore IV graphics hardware as found now in the Raspberry Pi 4. That was the "BCMV" driver while there also has been an "rpi-vulkan-driver" effort too. But now Igalia under contract with Broadcom / Raspberry Pi Foundation has begun writing a new Vulkan driver.

Vulkan is coming to Raspberry Pi: first triangle

  • Vulkan is coming to Raspberry Pi: first triangle

    Following on from our recent announcement that Raspberry Pi 4 is OpenGL ES 3.1 conformant, we have some more news to share on the graphics front. We have started work on a much requested feature: an open-source Vulkan driver!

Raspberry Pi 4 graphics win: Open-source Vulkan driver support

  • Raspberry Pi 4 graphics win: Open-source Vulkan driver support is coming

    Raspberry Pi designer the Raspberry Pi Foundation is working on delivering a new open-source Vulkan driver, a graphics application programming interface (API) that could mean higher-quality and faster graphics for the tiny computer.

    Vulkan support is now common among Android smartphones and has long been backed by Samsung to improve graphics and games on Galaxy devices, and is supported by gaming heavyweights like Valve on SteamOS.

Raspberry Pi 4 is Now OpenGL ES 3.1 Conformant, Work on Vulkan

Open source Vulkan driver coming to Raspberry Pi

  • Open source Vulkan driver coming to Raspberry Pi

    Raspberry Pi boss Eben Upton has announced that work has begun on an open source Vulkan driver. This news comes hot on the heels of the announcement that the Raspberry Pi 4 is OpenGL ES 3.1 conformant.

    Regular HEXUS readers will be well aware of the Vulkan API and its value to PC developers , as well as its growing influence on a wide range of platforms like MacOS, Linux and Android. As Upton mentions in his blog post, the Vulkan API has been designed to make the most of modern compute / graphics hardware - addressing common bottlenecks in OpenGL.

Comment viewing options

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

More in Tux Machines

Kernel: Virtualisation, BPF, and Btrfs

  • QEMU 5.1 Bringing Many CPU Improvements From Loongson To RISC-V To s390

    QEMU 5.1-rc0 is available as the first step towards this next feature release of this important component to the Linux virtualization stack. The QEMU 5.1-rc0 release marks the hard feature freeze for this next release. Weekly release candidates will continue until QEMU 5.1 is ready to ship around the middle of August.

  • Sleepable BPF programs

    When support for classic BPF was added to the kernel many years ago, there was no question of whether BPF programs could block in their execution. Their functionality was limited to examining a packet's contents and deciding whether the packet should be forwarded or not; there was nothing such a program could do to block. Since then, BPF has changed a lot, but the assumption that BPF programs cannot sleep has been built deeply into the BPF machinery. More recently, classic BPF has been pushed aside by the extended BPF dialect; the wider applicability of extended BPF is now forcing a rethink of some basic assumptions. BPF programs can now do many things that were not possible for classic BPF programs, including calling helper functions in the kernel, accessing data structures ("maps") shared with the kernel or user space, and synchronizing with spinlocks. The core assumption that BPF programs are atomic has not changed, though. Once the kernel jumps into a BPF program, that program must complete without doing anything that might put the thread it is running in to sleep. BPF programs themselves have no way of invoking any sort of blocking action, and the helper functions exported to BPF programs by the kernel are required to be atomic. As BPF gains functionality and grows toward some sort of sentient singularity moment, though, the inability to block is increasingly getting in the way. There has, thus, been interest in making BPF programs sleepable for some time now, and that interest has recently expressed itself as code in the form of this patch set from Alexei Starovoitov. The patch adds a new flag, BPF_F_SLEEPABLE, that can be used when loading BPF programs into the kernel; it marks programs that may sleep during their execution. That, in turn, informs the BPF verifier about the nature of the program, and brings a number of new restrictions into effect. Most of these restrictions are the result of the simple fact that the BPF subsystem was never designed with sleepable programs in mind. Parts of that subsystem have been updated to handle sleeping programs correctly, but many other parts have not. That is likely to change over time but, until then, the functionality implemented by any part of the BPF subsystem that still expects atomicity is off-limits to sleepable programs. For example, of the many types of BPF programs supported by the kernel, only two are allowed to block: those run from the Linux security module subsystem and tracing programs (BPF_PROG_TYPE_LSM and BPF_PROG_TYPE_TRACING). Even then, tracing programs can only sleep if they are attached to security hooks or are attached to functions that have been set up for error injection. Other types of programs are likely to be added in the future, but the coverage will never be universal. Many types of BPF programs are invoked from within contexts that, themselves, do not allow sleeping — deep within the network packet-processing code or attached to atomic functions, for example — so making those programs sleepable is just not going to happen.

  • Btrfs at Facebook

    The Btrfs filesystem has had a long and sometimes turbulent history; LWN first wrote about it in 2007. It offers features not found in any other mainline Linux filesystem, but reliability and performance problems have prevented its widespread adoption. There is at least one company that is using Btrfs on a massive scale, though: Facebook. At the 2020 Open Source Summit North America virtual event, Btrfs developer Josef Bacik described why and how Facebook has invested deeply in Btrfs and where the remaining challenges are. Every Facebook service, Bacik began, runs within a container; among other things, that makes it easy to migrate services between machines (or even between data centers). Facebook has a huge number of machines, so it is impossible to manage them in any sort of unique way; the company wants all of these machines to be as consistent as possible. It should be possible to move any service to any machine at any time. The company will, on occasion, bring down entire data centers to test how well its disaster-recovery mechanisms work.

today's howtos

Home Assistant improves performance in 0.112 release

The Home Assistant project has released version 0.112 of the open-source home automation hub we have previously covered, which is the eighth release of the project this year. While previous releases have largely focused on new integrations and enhancements to the front-end interface, in this release the focus has shifted more toward improving the performance of the database. It is important to be aware that there are significant database changes and multiple potential backward compatibility breaks to understand before attempting an upgrade to take advantage of the improvements. According to the release notes written by contributor Franck Nijhof, better performance has been a major goal of this release with a focus on both the logbook and history components. This builds on the work of the previous release (v0.111) from a performance perspective, which focused on reducing the time it takes to initialize the hub at startup. Read more

Android Leftovers