Language Selection

English French German Italian Portuguese Spanish

How XMir and Mir fit together

Filed under
Software
Ubuntu

For Ubuntu 13.10, Canonical are proposing to use Mir by default. Of course, this requires a certain amount of replumbing. X would normally be responsible for doing things like setting up the screen and pushing the pixels out to the hardware, but this is now handled by Mir instead. Where a native X server would allocate a framebuffer in video memory and render into it, XMir asks Mir for a window corresponding to the size of the screen and renders into that and then simply asks Mir to display it. This step is actually more interesting than it sounds.

Unless you're willing to throw lots of CPU at them, unaccelerated graphics are slow. Even if you are, you're going to end up consuming more power for the same performance, so XMir would be impractical if it didn't provide access to accelerated hardware graphics functions. It makes use of the existing Xorg accelerated X drivers to do this, which is as simple as telling the drivers to render into the window that XMir requested from Mir rather than into the video framebuffer directly. In other words, when displaying through XMir, you're using exactly the same display driver stack as you would be if you were using Xorg. In theory you'd expect identical performance - in practice there's a 10-20% performance hit right now, but that's being actively worked on. Fullscreen 3D apps will also currently take a hit due to there being no support for skipping compositing, which is being fixed. XMir should certainly be capable of performing around as well as native X, but there's no reason for it to be any faster.

rest here




More in Tux Machines

Security: Updates, IBM, Elytron and Container Vulnerability Scanning

  • Security updates for Friday
  • IBM Security launches open-source AI
    IBM Security unveiled an open-source toolkit at RSA 2018 that will allow the cyber community to test their AI-based security defenses against a strong and complex opponent in order to help build resilience and dependability into their systems.
  • Elytron: A New Security Framework in WildFly/JBoss EAP
    Elytron is a new security framework that ships with WildFly version 10 and Red Hat JBoss Enterprise Application Platform (EAP) 7.1. This project is a complete replacement of PicketBox and JAAS. Elytron is a single security framework that will be usable for securing management access to the server and for securing applications deployed in WildFly. You can still use the legacy security framework, which is PicketBox, but it is a deprecated module; hence, there is no guarantee that PicketBox will be included in future releases of WildFly. In this article, we will explore the components of Elytron and how to configure them in Wildfly.
  • PodCTL #32 – Container Vulnerability Scanning

NetBSD 8.0 RC1 Available, Bringing Initial USB 3.0 Support & Spectre/Meltdown Mitigation

It's a busy month for the BSDs with DragonFlyBSD 5.2 having come along with OpenBSD 6.3 and right before that was TrueOS 18.03. Now there's finally the release candidate of the long-awaited NetBSD 8.0 update. NetBSD 7.0 arrived back in October 2015 while the NetBSD 8.0 release should not be too much further out. Arguably most interesting with NetBSD 8.0 is its finally bring initial USB 3.0 support though the change-log currently just describes it as "some USB 3 support." Read more

FFmpeg 4.0 Released

  • FFmpeg 4.0 released
    Version 4.0 of the FFmpeg multimedia toolkit is out. There is a long list of new filters, formats, and more; see the announcement for details.
  • April 20th, 2018, FFmpeg 4.0 "Wu"
  • FFmpeg 4.0 Released With New Encoders/Decoders, NVIDIA NVDEC Decoding
    FFmpeg 4.0 is now available as the latest major release for this widely-used open-source multimedia encode/decoder library. FFmpeg 4.0 introduces NVIDIA NVDEC GPU-based decoding for H264 / MJPEG / HEVC / MPEG-1/2/4, VC1, VP8, and VP9 formats. This release also adds an Intel QSV accelerated overlay filter, an OpenCL overlay filter, VA-API MJPEG and VP8 decoding support, new VA-API filters, and many other accelerated code path improvements.

Graphics: AMD, Intel and Vulkan

  • AMDGPU DC Fixes For Linux 4.17 Take Care Of "The Dark Screen Issue"
    AMD's Alex Deucher has sent in a small set of fixes for the AMDGPU Direct Rendering Manager driver in the Linux 4.17 kernel. The three patches are for fixing a dark screen issue with AMDGPU DC, a fix for clock/voltage dependency tracking for WattMan, and an updated SMU interface for the yet-to-be-announced Vega 12 GPU.
  • Intel KVMGT 2018-Q1 Release Offers Mediated GPU Pass-Through Improvements
    While the relevant bits for supporting Intel GPU mediated pass-through to virtual machines with KVM are now upstream in the Linux kernel as well as in QEMU 2.12, Intel developers have just announced their quarterly release of "KVMGT" for those wanting the officially blessed configuration for running Intel virtual GPU support with KVM virtual machines.
  • RADV Vulkan Driver Adds Vega M Support
    Following RadeonSI adding "Vega M" support for the new Radeon graphics appearing embedded on select Intel Kabylake processor packages, the RADV developers have similarly staged their Vega M support in this open-source Vulkan driver.
  • The Forge Now Offers Full-Featured Vulkan Support On Linux
    Earlier this month we covered "The Forge" picking up initial Linux support and now they have rounded out their full-featured Linux support with Vulkan rendering.