Graphics/Benchmarks
Graphical desktop system X Window turns 38
Submitted by Roy Schestowitz on Wednesday 22nd of June 2022 02:53:35 PM Filed underThe 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
- 2271 reads
- PDF version
Mike Blumenkrantz: Bugaroos
Submitted by Roy Schestowitz on Thursday 16th of June 2022 10:41:36 PM Filed underWe 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
- 2581 reads
- PDF version
Mesa 22.1.2
Submitted by Roy Schestowitz on Thursday 16th of June 2022 06:58:41 PM Filed underHi 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
- 2420 reads
- PDF version
Adding secondary command buffers to PanVk
Submitted by Roy Schestowitz on Wednesday 15th of June 2022 09:09:18 PM Filed underFor 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
- 2393 reads
- PDF version
Bridging the synchronization gap on Linux
Submitted by Roy Schestowitz on Friday 10th of June 2022 12:35:15 AM Filed underWith 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
- 2265 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
- 2681 reads
- PDF version
mesa 22.1.1
Submitted by Roy Schestowitz on Wednesday 1st of June 2022 11:34:24 PM Filed underHi 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
- 2285 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 underAs 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
- 2586 reads
- PDF version
lavapipe Vulkan 1.2 conformant
Submitted by Roy Schestowitz on Friday 27th of May 2022 08:09:51 PM Filed underThe 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
- 3244 reads
- PDF version
wayland 1.20.91
Submitted by Roy Schestowitz on Friday 27th of May 2022 08:07:02 AM Filed underThis 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
- 2320 reads
- PDF version
More in Tux Machines
- Highlights
- Front Page
- Latest Headlines
- Archive
- Recent comments
- All-Time Popular Stories
- Hot Topics
- New Members
digiKam 7.7.0 is releasedAfter three months of active maintenance and another bug triage, the digiKam team is proud to present version 7.7.0 of its open source digital photo manager. See below the list of most important features coming with this release. |
Dilution and Misuse of the "Linux" Brand
|
Samsung, Red Hat to Work on Linux Drivers for Future TechThe metaverse is expected to uproot system design as we know it, and Samsung is one of many hardware vendors re-imagining data center infrastructure in preparation for a parallel 3D world. Samsung is working on new memory technologies that provide faster bandwidth inside hardware for data to travel between CPUs, storage and other computing resources. The company also announced it was partnering with Red Hat to ensure these technologies have Linux compatibility. |
today's howtos
|
Recent comments
47 weeks 1 day ago
47 weeks 2 days ago
47 weeks 2 days ago
47 weeks 2 days ago
47 weeks 2 days ago
47 weeks 2 days ago
47 weeks 2 days ago
47 weeks 3 days ago
47 weeks 3 days ago
47 weeks 3 days ago