Language Selection

English French German Italian Portuguese Spanish

Graphics: X.Org, RADV, Virtualized GPU

Filed under
Graphics/Benchmarks

  • X.Org Server Patches Updated For Non-Desktop & Lease Handling

    Keith Packard has sent out his latest patches for implementing the non-desktop and DRM lease functionality from within the X.Org Server. This work also includes the relevant DDX bits being wired through for the xf86-video-modesetting driver.

    The "non-desktop" handling is the new property for indicating if a display output is not for a conventional desktop use-case, i.e. a VR HMD as the main use-case from Valve's perspective. When the VR HMD or other non-desktop output is set, it's not used by the X.Org Server and any desktop window manager so it can be reserved for the SteamVR compositor.

  • RADV Radeon Vulkan Driver Is Still A Better Bet Than AMDVLK In February 2018

    With the AMDVLK Radeon Vulkan driver that AMD open-sourced in December continuing to be updated in weekly batches with new Vulkan extensions / features / performance optimizations and the RADV Mesa-based Radeon Vulkan driver continuing to march to its own beat, I have spent the past few days conducting some fresh benchmarks between the AMDVLK and RADV Vulkan drivers with RX 560, RX 580, and RX Vega 64 graphics cards.

  • Virtualizing GPU Access

    Virtualized GPU access is becoming common in the containerized and virtualized application space. Let's have a look at why and how.

    For the past few years a clear trend of containerization of applications and services has emerged. Having processes containerized is beneficial in a number of ways. It both improves portability and strengthens security, and if done properly the performance penalty can be low.

    In order to further improve security containers are commonly run in virtualized environments. This provides some new challenges in terms of supporting the accelerated graphics usecase.

More in Tux Machines

OpenSUSE/SUSE: SLES for SAP and Christian Boltz Introduced

  • SUSE Linux Enterprise Server for SAP Applications support update
    SUSE has announced effective December 1, 2018, two changes to its SUSE Linux Enterprise Server (SLES) for SAP Applications product. SLES for SAP Applications now includes support for a given service pack for 4.5 years with the regular subscription while the basic codestream is general available and itself fully maintained. This change reflects the request from clients to align OS upgrades with hardware life cycles. To explain this a bit further, this change affects SLES for SAP Applications 12 and 15 code streams. SLES for SAP Applications 11 is at the end of the general availability already, therefore SLES for SAP Applications 11 SP4 is the last service pack. If clients choose to stay on SLES for SAP Applications 11, then they will need to purchase LTSS to ensure ongoing support. This is especially true for clients that run SAP HANA 1 workloads on IBM Power Systems servers in Big Endian mode.
  • 2018-2019 openSUSE Board Elections: Meet incumbent Christian Boltz
    With two weeks to go until the ballots open on Monday, February 4, 2019, openSUSE News and the Elections Committee are running a “meet your candidates” series. Questions were sent out to the seven Candidates. The questions and answers will appear in the News, one Candidate each day, in alphabetical order.

ArchLabs Refresh Release, 2019.01.20

Gidday ArchLabbers, Happy New Year. With the new year comes an ISO refresh. All changes are listed at the change-log. If you encounter any issues, please post them at the forum. Also, ArchLabs related bugs need to be raised at BitBucket. Read more

Programming: Homebrew 1.9, JBoss EAP, Python, Qt and Inclusion

  • Homebrew 1.9 Adds Linux Support, Auto-Cleanup, and More
    The latest release of popular macOS package manager Homebrew includes support for Linux, optional automatic package cleanup, and extended binary package support. Linux support, merged from the Linuxbrew project, is still in beta and will become stable in version 2.0. It also enables the use of Homebrew on Windows 10 systems with the Windows Subsystem for Linux installed. Auto-cleanup is meant to optimize disk space occupation by removing all intermediate data that Homebrew generates when installing packages. This can be a significant amount when Homebrew actually builds the packages from sources instead of just installing binaries. Auto-cleanup is opt-in by setting the HOMEBREW_INSTALL_CLEANUP. This behaviour will become opt-out in version 2.0, where you will be able to set the HOMEBREW_NO_INSTALL_CLEANUP environment variable to disable auto-cleanup.
  • Streamline your JBoss EAP dev environment with Red Hat CodeReady Workspaces: Part 1
  • Counteracting Code Complexity With Wily - Episode 195
    As we build software projects, complexity and technical debt are bound to creep into our code. To counteract these tendencies it is necessary to calculate and track metrics that highlight areas of improvement so that they can be acted on. To aid in identifying areas of your application that are breeding grounds for incidental complexity Anthony Shaw created Wily. In this episode he explains how Wily traverses the history of your repository and computes code complexity metrics over time and how you can use that information to guide your refactoring efforts.
  • Qt Visual Studio Tools 2.3.1 Released
    The Qt VS Tools version 2.3.1 has now been released to the Visual Studio Marketplace.
  • Ben Cotton: Inclusion is a necessary part of good coding
    Too often I see comments like “some people would rather focus on inclusion than write good code.” Not only is that a false dichotomy, but it completely misrepresents the relationship between the two. Inclusion doesn’t come at the cost of good code, it’s a necessary part of good code. We don’t write code for the sake of writing code. We write code for people to use it in some way. This means that the code needs to work for the people. In order to do that, the people designing and implementing the technology need to consider different experiences. The best way to do that is to have people with different experiences be on the team. As my 7th grade algebra teacher was fond of reminding us: garbage in, garbage out.

Graphics: Vega, Radeon, Wayland on BSD

  • Vega 10 & Newer Getting More Fine-Grained PowerPlay Controls On Linux
    With the upcoming Linux 5.1 kernel cycle, discrete Radeon graphics cards based on Vega 10 and newer will have fine-grained controls over what PowerPlay power management features are enabled and the ability to toggle them at run-time. Queued into the work-in-progress AMDGPU code for the eventual Linux 5.1 kernel cycle is now a ppfeatures for sysfs. This new "ppfeatures" file on sysfs will allow for querying the PowerPlay features state and toggling them individually. This includes features like GFXOFF (the ability to turn off the graphics engine when idling), automatic fan control, LED display for GPU activity, the dynamic power management state for the various blocks, and other features. Up to now the PowerPlay features couldn't be toggled individually but just a blanket enable/disable.
  • AMD Radeon 7 Will Have Day One Linux Support
    Linux gamers shouldn't see a repeat performance of the Radeon RX 590 situation.
  • Wayland Support On The BSDs Continuing To Improve
    While Wayland was designed on and for Linux systems, the BSD support for Wayland and the various compositors has continued improving particularly over the past year or so but it's still a lengthy journey. In a little more than one year, the FreeBSD Wayland support has been on a steady rise. It's looking like this year could even mark the KDE Wayland session for FreeBSD potentially getting squared away. Besides KDE, the GNOME Wayland work for FreeBSD has advanced a bit and is available in some FreeBSD Ports but there has been some complications around libinput and its Linux'isms. Details on the current state of Wayland-related components in FreeBSD is drafted at the FreeBSD Wiki.