Language Selection

English French German Italian Portuguese Spanish

Graphics: Libdrm, AMDGPU, AR/VR and Gallium3D

Filed under
Graphics/Benchmarks
  • Libdrm 2.4.100 Released With Bits For Intel Elkhart Lake, Tiger Lake Graphics

    AMD open-source developer Marek Olšák on Wednesday released libdrm 2.4.100 as the newest feature update to this Mesa DRM library.

    On the AMD front there are a number of RAS tests added, a new amdgpu_cs_query_reset_state2 interface, and other expanded AMDGPU test coverage.

  • AMDGPU GFX9+ Format Modifiers Being Worked On For Better DCC Handling

    RADV Vulkan driver developer Bas Nieuwenhuizen of Google has ventured into kernel space in working on format modifiers support for Vega/GFX9 and newer.

    This DRM format modifiers support for GFX9+ is being worked on for helping to evaluate when delta color compression (DCC) can be used and any other requirements around that DCC handling. Bas explained, "This is particularly useful to determine if we can use DCC, and whether we need an extra display compatible DCC metadata plane."

  • Free software support for virtual and augmented reality

    A talk at the recent X.Org Developers Conference in Montréal, Canada looked at support for "XR" in free software. XR is an umbrella term that includes both virtual reality (VR) and augmented reality (AR). In the talk, Joey Ferwerda and Christoph Haag from Collabora gave an overview of XR and the Monado project that provides support for those types of applications.

    Ferwerda started by defining the term "HMD", which predates VR and AR. It is a head-mounted display, which basically means "taking a screen and some sensors and duct-taping it to your face". All of the devices that are being used for XR are HMDs. They typically include some kind of tracking system to determine the position and orientation of the HMD itself. Multiple different technologies, including inertial measurement units (IMUs), photodiodes, lasers, and cameras, are used to do the tracking depending on the device and its use case.

    AR is intended to augment the real world with extra information; the user sees the real world around them, but various kinds of status and additional data is tagged to objects or locations in their view of the world. AR is a rather over-hyped technology these days, he said. The general idea is that users would wear glasses that would augment their view in some fashion, but, unfortunately, what most people think of as AR is Pokémon Go.

    VR uses two screens, one for each eye, to create a 3D world that the user inhabits and can interact with in some fashion. Instead of seeing the real world, the user sees a completely separate world. There are two words that are often used to describe the feel of VR, he said: "presence" and "immersion". That means users are aware of themselves as being part of the VR environment.

    XR encompasses both. Ferwerda said that he is not really sure what the "X" stands for; he has heard "cross reality" and "mixed reality" for XR. Haag said that "extended reality" was another definition that he had heard.

  • Intel Now Aiming For Gallium3D OpenGL Default For Mesa 20.0

    For the better part of two years now Intel has been working on this new "Iris" Gallium3D driver for supporting Broadwell "Gen8" graphics and newer as the eventual replacement to their long-standing i965 classic driver. With Tiger Lake "Gen12" Xe graphics, it's in fact Iris Gallium3D only. In our testing of Broadwell through the *lakes, this Gallium3D driver has been working out terrific on Mesa 19.2 stable and Mesa 19.3 development. But it looks like Intel is going to play it safe and punt the default change-over to next quarter's Mesa 20.0 cycle.

More in Tux Machines

GNOME Development: Technical Reports From Federico Mena-Quintero and Jussi Pakkanen

  • Refactoring the Length type

    Over a couple of years, librsvg's type that represents CSS lengths went from a C representation along the lines of "all data in the world is an int", to a Rust representation that uses some interesting type trickery: C struct with char for units. C struct with a LengthUnits enum. C struct without an embodied direction; each place that needs to normalize needs to get the orientation right. C struct with a built-in direction as an extra field, done at initialization time. Same struct but in Rust. An ugly but workable Parse trait so that the direction can be set at parse/initialization time. Three newtypes LengthHorizontal, LengthVertical, LengthBoth with a common core. A cleaned-up Parse trait. A macro to generate those newtypes. Replace the LengthDir enum with an Orientation trait, and three zero-sized types Horizontal/Vertical/Both that implement the trait. Replace most of the macro with a helper trait LengthTrait that has an Orientation associated type. Replace the helper trait with a single Length<T: Orientation> type, which puts the orientation as a generic parameter. The macro disappears and there is a single implementation for everything. Refactoring never ends!

  • Some intricacies of ABI stability

    As far as I know, there is no known real-world solution to this problem that would scale to a full operating system (i.e. all of Debian, FreeBSD or the like). If there are any university professors reading this needing problems for your grad students, this could be one of them. The problem itself is fairly simple to formulate: make it possible to run two different, ABI incompatible C++ standard libraries within one process. The solution will probably require changes in the compiler, linker and runtime loader. For example, you might extend symbol resolution rules so that they are not global, but instead symbols from, say library bar would first be looked up in its direct descendents (in this case only abi2) and only after that in other parts of the tree. To get you started, here is one potential solution I came up with while writing this post. I have no idea if it actually works, but I could not come up with an obvious thing that would break. I sadly don't have the time or know-how to implement this, but hopefully someone else has.

Graphics and Games: Intel, Vulkan, Trine and Google Stadia

  • Intel's Graphics Driver DoS Fix Last Week Has Hurt Power Consumption

    While the patches overnight about "substantial" improvement in power usage for Intel graphics on Linux were exciting on first look, it's less so now as it turns out last week's graphics driver security fixes is what regressed the Intel graphics power-savings. During last Tuesday's round of Intel security disclosures where there was a fix for denial of service in the Intel graphics driver, it turns out that the CVE-2019-0154 fix is what regressed power usage. The potential Denial of Service vulnerability was about unprivileged users being able to cause a DoS by reading select memory regions when the graphics hardware is in certain low-power states.

  • vkBasalt 0.2 Released With SMAA, Other Vulkan Post Processing Layer Enhancements

    The open-source vkBasalt project was started as a layer implementing Contrast Adaptive Sharpening (akin to Radeon Image Sharpening) for any Vulkan-using GPU/driver/software. The vkBasalt project then picked up FXAA support for this Vulkan post-processing layer while now a new release is out with more functionality added. The vkBasalt 0.2 release is out today and adds support for enhanced sub-pixel morphological anti-aliasing (SMAA) for higher-quality anti-aliasing than FXAA. SMAA is an image-based implementation of MLAA. This release also allows for multiple visual effects to be activated at once where as previously only any one of these image enhancing features could be active at a time.

  • Flax Engine Ported To Linux + Vulkan Rendering Support

    Flax Engine is the latest game engine seeing native Linux support and in the process the renderer also picked up Vulkan support. Flax Engine is a lesser known game engine that now works on Linux alongside Windows and Xbox One. After two years in development, the open beta release of Flax is expected soon.

  • The sad case of Trine on Mesa and Linux in 2019

    A year or so back I was planning on writing a congratulatory article to show my appreciation to Dave Airlie for fixing a long standing bug in Mesa that prevented users of older AMD Radeon HD cards from enjoying Trine Enchanted Edition on the free graphics stack. Bug 91808 resulted in a variety of graphical artifacts which, while not interfering with the gameplay, still put me off using that version of Trine. After several years and a great deal of evident frustration on his part, Airlie was able to track down the root of the problem and at long last was able to push a fix to master in May 2018. Airlie and developers like him are often the unsung heroes of FOSS development, and I wanted to give him a well deserved public pat on the back for his effort in fixing a bug which would only have affected such a small number of people. Unfortunately my research into this led me down an entirely different rabbit hole when I discovered the report for Bug 66067. A much more subtle misrendering of the game's colours and lighting, this bug is present in both Trine 2 and Trine Enchanted Edition and affects all Mesa users. Unlike the previous instance where it was an issue in the drivers that was the culprit, this issue is present in the game binaries themselves.

  • Google Stadia is out now for early adopters, well a few anyway

    Today, the Google Stadia streaming service officially launched for those who picked up the Founder or Premier Edition. Well, sort of anyway. Some people have it, a lot of people don't, we certainly don't and it appears the team at Stadia give different answers to different people on when you will actually be able to access it. I've also seen plenty of people whose orders have been cancelled without warning or explanation. Even worse still, some people have been sent their hardware without an access code. Google have, so far, done a terrible job at communicating on Stadia and so the initial launch doesn't seem to have gone down well at all.

SystemTap 4.2 release

The SystemTap team announces release 4.2!

support for generating backtraces of different contexts; improved backtrace
tapset to include file names and line numbers; eBPF support extensions
including raw tracepoint access, prometheus exporter, procfs probes and
improved looping structures

= Where to get it

  https://sourceware.org/systemtap/ - Project Page
  https://sourceware.org/systemtap/ftp/releases/
  https://koji.fedoraproject.org/koji/packageinfo?packageID...
  git tag release-4.2 (commit 044a0640985ef0)

  There have been over 110 commits since the last release.
  There have been over 25 bugs fixed / features added since the last
release.

= SystemTap frontend (stap) changes

- When the -v option is set along with -L option, the output includes
  duplicate probe points which are distinguished by their PC address.

- Now it is possible to issue a backtrace using user specified pc, sp,
  and fp which can be used to generate backtraces of different contexts.
  This was introduced to get backtraces of user code from within the go
  runtime but it can also be used to do things like generating backtraces
  of user code from within signal handlers.

- The automatic printing implementation now differentiates between
  pointer and integer types, which are printed as hex or decimal
  respectively.

= SystemTap backend changes

- Initial support for multi-dimensional supports has been added to
  the stapbpf backend. Note that these arrays cannot be iterated upon
  with a foreach loop.

- The stapbpf backend now supports sorting by value in foreach loops.

- The stapbpf backend now supports the concatenation operator for
  userspace probes.

- The stapbpf backend now supports the target() function and -x option.

- The gettimeofday_* functions are now provided for the stapbpf backend.

- The stapbpf backend now supports order parameterization for begin
  and end probes.

- The stapbpf backend now supports stap-exporter extensions.

- The stapbpf backend now supports procfs probes. The implementation
  uses FIFO special files in /var/tmp/systemtap-$EFFUSER/MODNAME instead
  of the proc filesystem files.

- The eBPF backend now uses bpf raw tracepoints for kernel.trace("*")
  probes.  These have target variable arguments that match the
  arguments available for the traditional linux kernel modules
  tracepoints.  Support for the older bpf tracepoint arguments can be
  forced with a --compatible=4.1 option on the command line.

- The compiler optimizes out probes with empty handlers. Previously,
  warnings were issued but, the probe was not internally removed. For
  example, this script now outputs a warning and an error as the only
  probe handler is empty:

      probe begin {}

  Additionally, probe handlers that evaluate to empty are also removed.
  For example, in this script, the begin probe is elided as $foo does
  not exist, however, an error won't be outputted because atleast one
  probe with a non-empty handler exists (probe begin):

      probe begin {
          print("Protected from elision")
      }

      probe end {
          if (@defined($foo)) { print("Evaluates to empty handler") }
      }

- The sys/sdt.h file changes the way i386 registers operands are
  sometimes named, due to an ambiguity.  A comment block explains.

= SystemTap tapset changes

- New backtracing functions print_[u]backtrace_fileline() have been added
  to the tapset. These functions behave similarly to print_[u]backtrace(),
  the only difference being that file names and line numbers are added
  to the backtrace.

= SystemTap sample scripts

All 180+ examples can be found at https://sourceware.org/systemtap/examples/
.

- Several sample scripts have been enabled to run on the stapbpf backend:

apps/libguestfs_log.stp
network/sk_stream_wait_memory.stp
memory/mmfilepage.meta
memory/mmwriteback.meta
general/ansi_colors.meta

- New stap-exporter sample script for the stapbpf backend:

syscallsrw.stp    Tallies the read and write syscalls.

= Examples of tested kernel versions

2.6.32 (RHEL6 x86_64)
4.15.0 (Ubuntu 18.04 x86_64)
4.18.0 (RHEL8 x86_64, aarch64, ppc64le, s390x)
5.0.7  (Fedora 29 x86_64)
5.3.8  (Fedora 30 i686)
5.3.9  (Fedora 31 x86_64)
5.4.0-rc  (Fedora 32 x86_64)

= Known issues with this release

- The array dump macros which are used with prometheus probes do not
entirely
  work with stapbpf as the macros use foreach loops which cannot be used
with
  multi-dimensional arrays yet.

- The user_string() function in the BPF tapsets uses the BPF
probe_read_str()
  helper, which only works correctly when there is no address translation
  between user and kernel address spaces. It has been restricted to x86_64
  only until the BPF infrastructure provides separate helpers for reading
user
  and kernel data.

= Coming soon

- More stapbpf functionality including full statistics aggregate support
and
  try-catch blocks.

= Contributors for this release

*Carlos O'Donell, Frank Ch. Eigler, Jafeer Uddin,
*Richard Purdie, Ross Burton, *Sagar Patel, Serhei Makarov
Stan Cox, *Wenzong Fan, William Cohen

Special thanks to new contributors, marked with '*' above.

Special thanks to Sagar for assembling these notes.

= Bugs fixed for this release &tl;https://sourceware.org/PR#####>

9922    need to configure with --disable-pie on ubuntu
25174   string auto-concat doesn't work in @var / @cast module parameter
25169   strcpy overlap between transport arg and string on-stack
25133   stapbpf foreach loop crashing
24953   foreach (v = v1,v2) syntax not behaving correctly in stapbpf
24812   stapbpf: support order-parametrized begin/end probes
25113   Explanation and "code" mismatch in section ⁠2.3.1.2. File Flight
Recorder
25107   need -L variant that doesn't merge duplicate probe points
23285   stapbpf procfs probes
24946   printing hex sequences causes crash
24947   valid hex and octal sequences not checked for
24926   non-ascii characters not printing on stapbpf
24934   stapbpf stack-smash on EXIT message processing
23879   print_ubacktrace can not print function name
24875   VMA tracker is broken on Fedora 29
24904   stack_trace struct undefined on kernel 5.2
23858   sorted iteration on bpf arrays can't sort values
24885   add test_{,install}check_dyninst tag to check.exp
23866   dissonance between kernel tracepoint parametrization, lkm vs bpf
24811   stapbpf segfault: nested foreach loops can corrupt sorted key data
when limit==0
11353   elide side-effect-free probes
24528   stapbpf-next housekeeping: bpf-translate.cxx should distinguish
codegen for kernel/userspace targets
24543   stapbpf breaks when cpu0 is disabled
12025   Have appropriate selection of hex and decimal formatted output for
automatic output
24639   "next" statement not recognized by stap bpf backend
24343   Some syscall.*.return missing name and retstr variables
Read more

today's howtos