Graphics/Benchmarks
Graphical desktop system X Window turns 38
Submitted by Roy Schestowitz on Wednesday 22nd of June 2022 02:53:35 PM Filed under
The X window system turned 38 years old this week, and although it has more rivals than ever, it is still the go-to for a graphical desktop on Unix.
The first public release of the X window system, according to Robert W. Scheifler's announcement, was 19 June 1984.
X itself was a rewrite of an older windowing system called W, which ran on a research microkernel OS called the V-System (V→W→X, you see.) Both the V-System and the W window system seem to have now been lost, although Bryan Lunduke has an interesting history.
About the only relic that you can see today, if you're curious, is the V-System manual [PDF].
Just two years after launch, X had already reached version 10 – the oldest point release showing in the release history on the X.org Foundation web page. X11R1 was introduced in 1987, and with some modifications, that's what the world is still using today.
That is quite a feat of longevity, considering that that's the same year as OS/2 1.0 came out, as well as Acorn's Archimedes range.
- Login or register to post comments
Printer-friendly version
- Read more
- 1820 reads
PDF version
Mike Blumenkrantz: Bugaroos
Submitted by Roy Schestowitz on Thursday 16th of June 2022 10:41:36 PM Filed under

We all remember our first bug. It’s usually “the code didn’t compile the first time I tried”. The worst bug there is.
The first bug I found in pursuit of this so-called rendering anomaly was not a simple compile error. No, unfortunately the code built and ran fine thanks to Mesa’s incredible and rock-stable CI systems (this was last week), which meant I had to continue on this futile quest to find out whatever was wrong.
Next, I looked at the ticket again and downloaded the trace, which was unfortunately provided to prevent me from claiming that I didn’t have the game or couldn’t find it or couldn’t launch it or was too lazy. Another unlucky roll of the dice.
- Login or register to post comments
Printer-friendly version
- Read more
- 2089 reads
PDF version
Mesa 22.1.2
Submitted by Roy Schestowitz on Thursday 16th of June 2022 06:58:41 PM Filed under

Hi list, I'd like to announce Mesa 22.1.2 is now available, after a short delay to bisect a regression. That's been fixed, and now we have a release! There's a lot of zink here, thanks to Mike for help with manually backporting parts of it! We've als got a bunch of fixes for panfrost, and some for intel, radeon, llvmpip, dzn, broadcom, nir, core gallium, the va state tracker, and freedreno. Cheers, Dylan
- Login or register to post comments
Printer-friendly version
- Read more
- 1961 reads
PDF version
Adding secondary command buffers to PanVk
Submitted by Roy Schestowitz on Wednesday 15th of June 2022 09:09:18 PM Filed under


For those who don't know yet, Panfrost is the open source OpenGL driver for the ARM Mali Midgard, Bifrost (and soon Valhall) GPU series. This driver is in a pretty good state already (see the conformance status here). On the other hand, we have PanVk, the open source Vulkan driver), and as can be guessed from the PAN_I_WANT_A_BROKEN_VULKAN_DRIVER=1 environment variable that is needed to have it loaded properly, it is still in its early days.
My internship, which started in December 2021 and wrapped up recently, was about getting PanVk closer to conformancy by implementing one of the core Vulkan features: support for secondary command buffers.
But before we dive into implementation details, let's take a step back to explain what command buffers are, why Vulkan introduced this concept, and what makes secondary command buffers different from the primary counterpart.
- Login or register to post comments
Printer-friendly version
- Read more
- 1943 reads
PDF version
Bridging the synchronization gap on Linux
Submitted by Roy Schestowitz on Friday 10th of June 2022 12:35:15 AM Filed under


With older graphics APIs like OpenGL, the client makes a series of API calls, each of which either mutates some bit of state or performs a draw operation. There are a number of techniques that have been used over the years to parallelize the rendering work, but the implementation has to ensure that everything appears to happen in order from the client's perspective. While this served us well for years, it's become harder and harder to keep the GPU fully occupied. Games and other 3D applications have gotten more complex and need multiple CPU cores in order to have enough processing power to reliably render their entire scene in less than 16 milliseconds and achieve a smooth 60 frames per second. GPUs have also gotten larger with more parallelism, and there's only so much a driver can do behind the client's back to parallelize things.
To improve both GPU and CPU utilization, modern APIs like Vulkan take a different approach. Most Vulkan objects such as images are immutable: while the underlying image contents may change, the fundamental properties of the image such as its dimensions, color format, and number of miplevels do not. This is different from OpenGL where the application can change any property of anything at any time. To draw, the client records sequences of rendering commands in command buffers which are submitted to the GPU as a separate step. The command buffers themselves are still stateful, and the recorded commands have the same in-order guarantees as OpenGL. However, the state and ordering guarantees only apply within the command buffer, making it safe to record multiple command buffers simultaneously from different threads. The client only needs to synchronize between threads at the last moment when they submit those command buffers to the GPU. Vulkan also allows the driver to expose multiple hardware work queues of different types which all run in parallel. Getting the most out of a large desktop GPU often requires having 3D rendering, compute, and image/buffer copy (DMA) work happening all at the same time and in parallel with the CPU prep work for the next batch of GPU work.
Enabling all this additional CPU and GPU parallelism comes at a cost: synchronization. One piece of GPU work may depend on other pieces of GPU work, possibly on a different queue. For instance, you may upload a texture on a copy queue and then use that texture on a 3D queue. Because command buffers can be built in parallel and the driver has no idea what the client is actually trying to do, the client has to explicitly provide that dependency information to the driver. In Vulkan, this is done through VkSemaphore objects. If command buffers are the nodes in the dependency graph of work to be done, semaphores are the edges. When a command buffer is submitted to a queue, the client provides two sets of semaphores: a set to wait on before executing the command buffer and a set to signal when the command buffer completes. In our texture upload example, the client would tell the driver to signal a semaphore when the texture upload operation completes and then have it wait on that same semaphore before doing the 3D rendering which uses the texture. This allows the client to take advantage of as much parallelism as it can manage while still having things happen in the correct order as needed.
- Login or register to post comments
Printer-friendly version
- Read more
- 1864 reads
PDF version
Kernel: Graphics Work and Apple Facilitates ARM Linux Virtual Machines
Submitted by Roy Schestowitz on Tuesday 7th of June 2022 06:41:43 PM Filed under


-
Mike Blumenkrantz: Returning
After my last blog post I was so exhausted I had to take a week off, but I’m back. In the course of my blog-free week, I remembered the secret to blogging: blog before I start real work for the day.
It seems obvious, but once that code starts flowing, the prose ain’t coming.
[...]
Some time ago I implemented dmabuf support for lavapipe. This is finally landing, assuming CI doesn’t get lost at the pub on the way to ramming the patches into the repo. Enjoy running Vulkan-based display servers in style. I’m still waiting on Cyberpunk to finish loading, but I’m planning to test out a full lavapipe system once I finish the game.
Also in lavapipe-land, 1.3 conformance submissions are pending. While 1.2 conformance went through and was blogged about to great acclaim, this unfortunately can’t be listed in main or a current release since the driver has 1.2 conformance but advertises 1.3 support. The goalpost is moving, but we’ve got our hustle shoes on.
-
NVIDIA opengpu driver: (open)SUSE packages available
On May 19, 2022 nVidia made a release of their OpenSource kernel modules for their newer GPU platforms (Turing and newer) with Risc-V system processor. Meanwhile we have (open)SUSE packages for simple testing available in the X11:Drivers:Video project of our openSUSE Build Service. If you want to give these a try you need to install nvidia-open-gfxG06 and kernel-firmware-nvidia-gsp packages.
-
macOS Ventura includes support for Rosetta in ARM Linux VMs
Apple announced a slew of updates to Mac with macOS Ventura at WWDC this week, including a new feature that will let users take advantage of Rosetta inside ARM Linux virtual machines.
-
Apple will allow Linux VMs to run Intel apps with Rosetta in macOS Ventura | Ars Technica
One of the few things that Intel Macs can do that Apple Silicon Macs can't is run operating systems written for Intel processors inside of virtual machines. Most notably, this has meant that there is currently no legal way to run Windows on an Apple Silicon Mac.
- 3 comments
Printer-friendly version
- Read more
- 2302 reads
PDF version
mesa 22.1.1
Submitted by Roy Schestowitz on Wednesday 1st of June 2022 11:34:24 PM Filed under
Hi list, I'd like to announce mesa 22.1.1, the first maintanence release of the 22.1 series. Things are about where I'd expect for where we are in the cycle, and I'm happy. We've got a bit of everything here, zink, intel, and Panfrost being the biggest sets of changes, but some aco, zsn, llvm/lavapipe radv, nir, glsl, r300, aco, svga, and core mesa changes as well. I'll see you all again shortly for 22.0, and then again in two weeks for 22.1.2 Cheers, Dylan
- Login or register to post comments
Printer-friendly version
- Read more
- 1937 reads
PDF version
Monado's hand tracking: hand-waving our way towards a first attempt
Submitted by Roy Schestowitz on Tuesday 31st of May 2022 08:01:56 PM Filed under


As part of my internship at Collabora, I picked up Monado's hand tracking project. Today I will outline the section I did during the summer of 2021, which was a fairly bare-bones first attempt. Keep in mind that we've moved on from the architecture I describe here and have made considerable progress since then. More than anything, this is to illustrate how awesome it is to experience an internship at Collabora.
So. I started my internship right in the middle of this project - we already had done the work on model architecture and had developed unique techniques for training these models. Now it was time to take those trained models and try to deploy them inside Monado. Optical hand tracking for XR has a bit of a reputation as a Very Hard Tracking Task, and indeed it is - getting training data, training neural nets, and deploying them in real-time, low-latency environments such as XR is every bit as hard as they say it is. And also, when I started, I had very little experience with computer vision. But, somebody needed to do this; I decided I'd be crazy and just go for it.
- Login or register to post comments
Printer-friendly version
- Read more
- 2224 reads
PDF version
lavapipe Vulkan 1.2 conformant
Submitted by Roy Schestowitz on Friday 27th of May 2022 08:09:51 PM Filed under
The software Vulkan renderer in Mesa, lavapipe, achieved official Vulkan 1.2 conformance. The non obvious entry in the table is here.
Thanks to all the Mesa team who helped achieve this, Shout outs to Mike of Zink fame who drove a bunch of pieces over the line, Roland who helped review some of the funkier changes.
- Login or register to post comments
Printer-friendly version
- Read more
- 2876 reads
PDF version
wayland 1.20.91
Submitted by Roy Schestowitz on Friday 27th of May 2022 08:07:02 AM Filed under
This new release adds a new wl_pointer high-resolution scroll event, adds a few new convenience functions, and contains a collection of bug fixes. This is the first release to use GitLab releases instead of the usual wayland.freedesktop.org website. The new links are available at the end of this email, or in the GitLab UI. Full commit history below.
- Login or register to post comments
Printer-friendly version
- Read more
- 1995 reads
PDF version

More in Tux Machines
- Highlights
- Front Page
- Latest Headlines
- Archive
- Recent comments
- All-Time Popular Stories
- Hot Topics
- New Members
today's howtos
| Red Hat Hires a Blind Software Engineer to Improve Accessibility on Linux Desktop
Accessibility on a Linux desktop is not one of the strongest points to highlight. However, GNOME, one of the best desktop environments, has managed to do better comparatively (I think).
In a blog post by Christian Fredrik Schaller (Director for Desktop/Graphics, Red Hat), he mentions that they are making serious efforts to improve accessibility.
Starting with Red Hat hiring Lukas Tyrychtr, who is a blind software engineer to lead the effort in improving Red Hat Enterprise Linux, and Fedora Workstation in terms of accessibility.
|
Today in Techrights
| Android Leftovers |
Recent comments
31 weeks 4 days ago
31 weeks 4 days ago
31 weeks 4 days ago
31 weeks 4 days ago
31 weeks 4 days ago
31 weeks 4 days ago
31 weeks 4 days ago
31 weeks 5 days ago
31 weeks 5 days ago
31 weeks 5 days ago