Development
The Vulkan graphics API
The Khronos Group, which (among other things) maintains the OpenGL specification, has released version 1.0 of its new cross-platform graphics API, Vulkan. The Vulkan API is designed to be a lightweight API—at least in comparison to OpenGL—that provides graphics processing and general-purpose GPU computation. A number of open-source projects have announced Vulkan support already, although it may be some time before it can be put to the test in a major way on the average Linux system. In the long run, however, Vulkan promises higher performance on modern GPU hardware, simplified driver development, and a single API that covers all device profiles, from embedded systems to desktops.
Many of the ideas in Vulkan originated in AMD's Mantle API project, which was started in 2013, but shut down in 2015. Mantle was, understandably, an AMD-only effort, but its goals were of interest to graphics-software developers on many hardware platforms: build an OpenGL-like API from the ground up that dispensed with years' worth of legacy architecture no longer applicable on modern hardware.
For Linux users, the parallels to Wayland and X11 are clear. As with X, OpenGL was initially devised for hardware and software stacks that look very different from what is commonly deployed today. The Vulkan project targeted the same ideal as Mantle and eventually incorporated much of AMD's work on the subject. Still, Khronos took Vulkan from inception to a first release in a relatively fast 18 months, delivering drivers, demo code, and open-source software-development kits (SDKs) in conjunction with the specification.
What's available
The specification itself is available on the Khronos site as well as in a GitHub repository. The drivers available at launch time include offerings from a variety of companies that cover desktop and embedded Linux, Windows, and Android. On the desktop Linux side, Intel has released drivers for its fifth- and sixth-generation Core processors; NVIDIA has released drivers for the Kepler and Maxwell GPU families (essentially the GeForce 600 and later). For Android and embedded systems, Qualcomm has published a driver for the Adreno 530 GPU (found in the Snapdragon 820), and Imagination has developed drivers for PowerVR. So far, AMD has only released a Windows driver.
The NVIDIA drivers are proprietary, and available for both 64-bit and 32-bit systems. The Intel drivers are free software; they are available in the Mesa Git repository and have been packaged for Ubuntu and Fedora. Apart from the drivers themselves, Vulkan defines a Window System Interface (WSI) that provides hooks for various window systems. Included in the 1.0 WSI specification are Wayland, X11, Mir, and Android. There are two SDK options available; one is the official Vulkan offering from LunarG and includes desktop Linux and Android, the other is Google's Android Native Development Kit (NDK), which now includes Vulkan support.
In addition, support has already begun trickling into other libraries. Matthew Waters announced a GStreamer video sink element that uses Vulkan.
What's inside
With all of that code available, the natural question to ask is what Vulkan 1.0 provides that OpenGL does not. In a sense, Vulkan is designed to be a successor to OpenGL, offering a cross-platform interface to GPUs for 3D rendering, video and graphics processing, and parallel computing. In another sense, though, Vulkan is positioned to serve as an OpenGL alternative that is tailored to use cases that need to squeeze as much performance out of the hardware as possible. For those applications, ditching OpenGL's overhead is paramount. For other programs, however, Vulkan's stripped-down design means considerably more work.
There are four large pieces of the OpenGL specification that are cut away in Vulkan: memory management, error handling, validation, and diagnostics. Strictly speaking, the validation and diagnostic layers are optional in Vulkan, but for performance-sensitive applications, the inability to run without them in OpenGL was a drawback. Dispensing with built-in memory management and error handling places a heavier burden on the application but, in turn, it removes the OpenGL-context management and memory management code from the graphics driver.
In addition, Vulkan is designed to support multi-core CPUs with full multithreading. In Vulkan, threads can each create their own command buffer, and all of the buffers feed into the same queue. Here again, the application is responsible for its own synchronization and thread management, but OpenGL is hampered by the need to maintain a single context, which can leave CPU cores sitting idle.
For a lot of GPU-intensive use cases, the critical part of an OpenGL application is the shader, the program that runs on the GPU itself. OpenGL required that shaders be written in a device-independent language called OpenGL Shading Language (GLSL), in source form. The OpenGL driver was required to compile the GLSL into machine code for the device, thus both making the driver more complicated and making it impossible to pre-compile the shader.
Vulkan replaces GLSL with an intermediate representation called Standard Portable Intermediate Representation (SPIR). Shaders can be written in any language and compiled to SPIR offline. Earlier revisions of SPIR were designed to be compatible with the LLVM compiler's intermediate representation, although the current version, SPIR-V, no longer maintains that compatibility guarantee. The SPIR-V tools support compiling Open Compute Language (OpenCL) kernels as well as GLSL shaders. Finally, Vulkan offers only a single API, which is shared by the desktop, Android, and embedded platforms. Thus, there should not be a need for developers to wrangle OpenGL and OpenGL ES for a single application.
What next
At this point, applications that need to drive as much performance as possible out of the available hardware will likely find Vulkan an easier API than OpenGL for optimizing GPU performance. The primary use case thus far seems to be the gaming market; it is no coincidence that Valve (developers of the Steam game-distribution service) funded the development of the Vulkan SDK.
But the smaller or simpler an application is, the less appealing it will be to handle GPU memory allocation and error handling internally. In its press materials, the Khronos Group touts that Vulkan will attract a rich ecosystem of libraries and frameworks that provide the higher-level functionality encoded in the OpenGL specification but omitted from Vulkan. That is likely the case, particularly if OpenGL is destined to be phased out. But, for now, the further away one gets from the GPU hardware, the less Vulkan has to offer. Simpler drivers are, no doubt, a win, as is support for multithreading. The performance gains of switching to Vulkan, though, are likely reserved for gaming engine developers in the near term.
Brief items
Quotes of the week
In the initial iteration it usually turns out to have three significant problems:
- a nightmare from a security perspective
- there's no concern for stability, because the people working on it are devs and not people who have certain reliability requirements
- bundling other software is often considered a good idea, because it makes life so much easier[tm]
Given a couple of years they start to catch up where the rest of the world (e.g. GNU/Linux distributions) is - at least to some extent. And then their solution is actually of a similar complexity compared to what is in use by other people, because they slowly realize that what they're trying to do is actually not that simple and that other people who have done things before were not stupid and the complexity is actually necessary...
Announcing Vulkan 1.0
Vulkan is a new graphics API specification, seemingly meant to supersede OpenGL. Collabora has announced the availability of the 1.0 specification — and that the Wayland compositor already supports it. "To provide the best possible base for fluid modern user interfaces, Collabora have worked extensively on the Wayland window system, the underlying Kernel Mode Setting drivers and atomic modesetting, and also the EGL specifications and implementations. We are proud to continue this work with Vulkan." Intel has announced an open-source Vulkan driver for its hardware as well.
Go 1.6 released
Version 1.6 of the Go programming language has been released. The most significant change is the addition of support for HTTP/2, which is enabled by default. There have also been changes to templates, changes to the rules for sharing pointers between Go and C code, and many other small updates.
systemd v229 released
Version 229 of systemd has been released. The update includes the addition of DNSSEC support (among other features) to the systemd-resolved name-resolution service, a reworked coredump-collection feature, and numerous changes to other components.
Newsletters and articles
Development newsletters from the past week
- What's cooking in git.git (February 12)
- What's cooking in git.git (February 17)
- LLVM Weekly (February 15)
- OCaml Weekly News (February 16)
- OpenStack Developer Digest (February 12)
- Perl Weekly (February 15)
- PostgreSQL Weekly News (February 14)
- Python Weekly (February 11)
- Ruby Weekly (February 11)
- This Week in Rust (February 15)
- Tahoe-LAFS Weekly News (February 12)
- Tor Weekly News (February 15; returning after a multi-month hiatus)
- Wikimedia Tech News (February 15)
Is the vinyl LP an open music format? (Opensource.com)
Chris Hermansen looks at an early open music format—vinyl LP records—over at Opensource.com. He goes into some of the details of the format and how it is read, as well as a bit about ripping records using Linux. "Ok, so we just figured out that our stylus puts 136 times as much pressure on our records as our car puts on the pavement? That's crazy!!! Why doesn't the stylus completely destroy the record? Those alternate-Earth physicists and engineers are rolling on the floor now, clutching their bellies and gasping for breath... but here is the final straw. Despite the seemingly ridiculous or even impossible nature of the whole ensemble of components, a well-recorded vinyl LP played back with a decent turntable, tonearm, and cartridge sounds wonderful."
D’Souza: Maru is open source!
On the Maru blog, developer Preetam D’Souza has announced that the Maru project is now open source. Maru is a desktop system running on a smartphone, so that adding a display, keyboard, and mouse to a phone allows the user to run their desktop on the phone—and still be able to use the device as a phone. "I’ve gotta say, the open source community never ceases to amaze me. I’ve had emails from people asking if they can help test Maru on other devices on a Sunday. How many normal people do you know that willingly want to give up their Sundays to help test software? I’ve experienced this helpfulness time and time again, whether it was the speakers at open source conferences so willing to share their knowledge, or the folks on forums who were so keen to help out beginners like me. Maru would never have been possible without that spirit of openness."
Chapman: Unlocking my Lenovo laptop
In a lengthy blog series (part 1, part 2, and part 3), Matthew Chapman described the process of getting a non-Lenovo battery to charge in his Thinkpad laptop. He reverse-engineered the authorization that real batteries do and changed the code in the embedded controller (EC) on the laptop to allow other batteries to charge. "I look in BIOS to see where these messages are coming from. Both this message and the original unauthorised battery message are displayed by LenovoVideoInitDxe.efi: don’t ask me why this code is in this module rather than somewhere more relevant (may I suggest LenovoAnnoyingBatteryMessageDxe.efi?), but it might have been convenient to put it in the video initialisation module as the message is displayed when the screen is cleared post-POST [Power-on self-test]." (Thanks to Neil Brown.)
Wielaard: Looking forward to GCC6 – Many new warnings
Mark Wielaard writes about some of the many new compiler warnings provided by the GCC6 release. "My favorite is still -Wmisleading-indentation. But there are many more that have found various bugs. Not all of them are enabled by default, but it makes sense to enable as many as possible when writing new code."
Page editor: Nathan Willis
Next page:
Announcements>>