Language Selection

English French German Italian Portuguese Spanish

Graphics: Mesa 19.1.8, dGPU and Intel

Filed under
Graphics/Benchmarks
  • Mesa 19.1.8
    Mesa 19.1.8 is now available.
    
    NOTE: It is anticipated that 19.1.8 will be the final release in the
    19.1 series. Users of 19.1 are encouraged to migrate to the 19.2 series
    in order to obtain future fixes.
    
    Apologies for the big delay in this release; there were several regressions that we
    were investigating, which prevented the pre-release to be on time.
    
    Subject: [ANNOUNCE] mesa 19.1.8
    To: mesa-announce at lists.freedesktop.org
    Cc: mesa-dev at lists.freedesktop.org
    
    Adam Jackson (1):
          docs: Update bug report URLs for the gitlab migration
    
    Alan Coopersmith (5):
          c99_compat.h: Don't try to use 'restrict' in C++ code
          util: Make Solaris implemention of p_atomic_add work with gcc
          util: Workaround lack of flock on Solaris
          meson: recognize "sunos" as the system name for Solaris
          intel/common: include unistd.h for ioctl() prototype on Solaris
    
    Andreas Gottschling (1):
          drisw: Fix shared memory leak on drawable resize
    
    Andres Gomez (3):
          docs: Add the maximum implemented Vulkan API version in 19.1 rel notes
          docs/features: Update VK_KHR_display_swapchain status
          egl: Remove the 565 pbuffer-only EGL config under X11.
    
    Andrii Simiklit (1):
          glsl: disallow incompatible matrices multiplication
    
    Arcady Goldmints-Orlov (1):
          anv: fix descriptor limits on gen8
    
    Bas Nieuwenhuizen (2):
          tu: Set up glsl types.
          radv: Add workaround for hang in The Surge 2.
    
    Danylo Piliaiev (1):
          st/nine: Ignore D3DSIO_RET if it is the last instruction in a shader
    
    Dylan Baker (5):
          meson: fix logic for generating .pc files with old glvnd
          meson: Try finding libxvmcw via pkg-config before using find_library
          meson: Link xvmc with libxv
          meson: gallium media state trackers require libdrm with x11
          meson: Only error building gallium video without libdrm when the platform is drm
    
    Eric Engestrom (4):
          gl: drop incorrect pkg-config file for glvnd
          meson: re-add incorrect pkg-config files with GLVND for backward compatibility
          util/anon_file: add missing #include
          util/anon_file: const string param
    
    Erik Faye-Lund (1):
          glsl: correct bitcast-helpers
    
    Greg V (1):
          util: add anon_file.h for all memfd/temp file usage
    
    Haihao Xiang (1):
          i965: support AYUV/XYUV for external import only
    
    Hal Gentz (1):
          gallium/osmesa: Fix the inability to set no context as current.
    
    Jason Ekstrand (2):
          nir/repair_ssa: Replace the unreachable check with the phi builder
          intel/fs: Fix fs_inst::flags_read for ANY/ALL predicates
    
    Juan A. Suarez Romero (12):
          docs: add sha256 checksums for 19.1.7
          cherry-ignore: add explicit 19.2 only nominations
          cherry-ignore: add explicit 19.3 only nominations
          Revert "Revert "intel/fs: Move the scalar-region conversion to the generator.""
          cherry-ignore: Revert "gallium: remove PIPE_CAP_TEXTURE_SHADOW_MAP"
          bin/get-pick-list.sh: sha1 commits can be smaller than 8 chars
          cherry-ignore: nir/opt_large_constants: Handle store writemasks
          cherry-ignore: util: added missing headers in anon-file
          cherry-ignore: radv: Fix condition for skipping the continue CS.
          cherry-ignore: Revert "radv: disable viewport clamping even if FS doesn't write Z"
          Update version to 19.1.8
          docs: add release notes for 19.1.8
    
    Ken Mays (1):
          haiku: fix Mesa build
    
    Kenneth Graunke (4):
          iris: Initialize ice->state.prim_mode to an invalid value
          intel: Increase Gen11 compute shader scratch IDs to 64.
          iris: Disable CCS_E for 32-bit floating point textures.
          iris: Fix iris_rebind_buffer() for VBOs with non-zero offsets.
    
    Lionel Landwerlin (5):
          anv: gem-stubs: return a valid fd got anv_gem_userptr()
          intel: use proper label for Comet Lake skus
          mesa: don't forget to clear _Layer field on texture unit
          intel: fix subslice computation from topology data
          intel/isl: Set null surface format to R32_UINT
    
    Marek Olšák (1):
          gallium/vl: don't set PIPE_HANDLE_USAGE_EXPLICIT_FLUSH
    
    Matt Turner (1):
          util: Drop preprocessor guards for glibc-2.12
    
    Michel Dänzer (1):
          radeonsi: fix VAAPI segfault due to various bugs
    
    Michel Zou (2):
          scons: add py3 support
          scons: For MinGW use -posix flag.
    
    Paulo Zanoni (1):
          intel/fs: fix SHADER_OPCODE_CLUSTER_BROADCAST for SIMD32
    
    Prodea Alexandru-Liviu (1):
          scons/MSYS2-MinGW-W64: Fix build options defaults
    
    Rhys Perry (2):
          radv: always emit a position export in gs copy shaders
          nir/opt_remove_phis: handle phis with no sources
    
    Samuel Iglesias Gonsálvez (1):
          intel/nir: do not apply the fsin and fcos trig workarounds for consts
    
    Stephen Barber (1):
          nouveau: add idep_nir_headers as dep for libnouveau
    
    Tapani Pälli (3):
          iris: close screen fd on iris_destroy_screen
          egl: check for NULL value like eglGetSyncAttribKHR does
          util: fix os_create_anonymous_file on android
    
    pal1000 (2):
          scons/windows: Support build with LLVM 9.
          scons: Fix MSYS2 Mingw-w64 build.
    
    git tag: mesa-19.1.8
    
  • Mesa 19.1.8 Released To End Out The Series

    More than one month has passed since Mesa 19.1.7 compared to the usual bi-weekly release cadence, but on Monday following the closure of remaining blocker bugs, Mesa 19.1.8 was released that also ends out this release series.

    Mesa 19.1.8 is the last planned release in the 19.1 Q2 series with users now being encouraged to upgrade at least to the stable Mesa 19.2 while Mesa 19.3 should be out around early December.

  • Linux 5.5 To Restore Power-Savings For Hybrid Laptops When Not Using The dGPU

    On recent kernels when using a laptop with hybrid graphics but not running with the discrete GPU graphics enabled, a regression meant the dGPU never got powered off... Fortunately, for Linux 5.5 -- and potentially to be back-ported after that -- is a change to restore that power-savings.

    A change enabling NVIDIA HDA controller support inadvertently left dGPUs powered up when not in use, i.e. where the dGPU is not bound to a driver. When the NVIDIA discrete graphics aren't bound to a driver, the power saving path wasn't being hit where the platform power management could disable power to the GPU.

  • Intel Lands More Graphics Code For Linux 5.5 - Jasper, More Intel Xe Multi-GPU Prepping

    Intel's open-source developers kicked off a new week by sending in their latest vetted changes to DRM-Next ahead of next month's Linux 5.5 kernel cycle.

    They already have sent in a lot of new graphics driver code for Linux 5.5 particularly around Tiger Lake while this week's pull request contains more new hardware enablement. They also anticipate sending in another pull request next week to DRM-Next with any other lingering feature work they are hoping to get into Linux 5.5.

  • Intel's Graphics Compiler For Their NEO Compute Stack Now Supports Jasper Lake

    The team maintaining the LLVM-based Intel Graphics Compiler as part of their "NEO" OpenCL/Compute Stack have rolled out v1.0.2714 that includes initial support for Jasper Lake among other improvements.

    Just in the past week we've begun seeing Linux graphics driver patches around "Jasper Lake" and that initial kernel-side support coming for Linux 5.5. Jasper Lake is the rumored 10nm successor to Gemini Lake for low-power SoCs but not to be confused with Elkhart Lake that is Tremont+Gen11 also for ultra-low-power environments based upon the limited information thus far.

Intel Linux Graphics Drivers Show Multi-GPU Xe Support

  • Intel Linux Graphics Drivers Show Multi-GPU Xe Support

    Phoronix already reported in August on work Intel has been doing for its graphics driver to support multiple devices concurrently. Phoronix said the muti-GPU support would most commonly be for the case of integrated graphics paired with a discrete Xe GPU, as the patches said: "With discrete graphics system can have both integrated and discrete GPU handled by i915 [driver]."

    For multiple discrete GPU setups like SLI and CrossFire, Phoronix wasn’t expecting much on the user-space side, however, saying that the OpenCL and Vulkan APIs could handle those cases, for compute and graphics respectively.

    The work is part of an ongoing effort to prepare Intel’s driver for discrete graphics support. The latest changes Phoronix reported for the upcoming Linux 5.5 kernel is code for a performance monitoring unit (PMU) for handling the integrated plus discrete graphics use-case. While it isn’t too interesting by itself, it further shows Intel’s work on Xe and multi-GPU capabilities.

New evidence of Intel's multi-GPU support for upcoming Xe...

  • New evidence of Intel's multi-GPU support for upcoming Xe discrete cards uncovered in Linux drivers

    Apart from the 2020 release and the fact that there will not be any ray tracing support, at least with the first generation, Intel’s Xe discrete gaming GPUs are still shrouded in mystery. It looks like Intel is doing a great job at keeping everything under wraps, as no major specs or price point info got leaked. This did not stop sites like Phoronix from digging deeper for clues, hints or any sort of inkling regarding the Intel Xe features.

    Churning through the latest Linux graphics drivers, the guys over at Phoronix spotted some more references to hybrid GPU setups.The first clues regarding multi-GPU support were uncovered back in August, and the latest Linux driver essentially reinforces this through a perf PMU (Processor Monitoring Unit) that is supposed to handle an iGPU + discrete card use-case.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Bringing PostgreSQL to Government

  • Crunchy Data, ORock Technologies Form Open Source Cloud Partnership for Federal Clients

    Crunchy Data and ORock Technologies have partnered to offer a database-as-a-service platform by integrating the former's open source database with the latter's managed offering designed to support deployment of containers in multicloud or hybrid computing environments. The partnership aims to implement a PostgreSQL as a service within ORock's Secure Containers as a Service, which is certified for government use under the Federal Risk and Authorization Management Program, Crunchy Data said Tuesday.

  • Crunchy Data and ORock Technologies Partnership Brings Trusted Open Source Cloud Native PostgreSQL to Federal Government

    Crunchy Data and ORock Technologies, Inc. announced a partnership to bring Crunchy PostgreSQL for Kubernetes to ORock’s FedRAMP authorized container application Platform as a Service (PaaS) solution. Through this collaboration, Crunchy Data and ORock will offer PostgreSQL-as-a-Service within ORock’s Secure Containers as a Service with Red Hat OpenShift environment. The combined offering provides a fully managed Database as a Service (DBaaS) solution that enables the deployment of containerized PostgreSQL in hybrid and multi-cloud environments. Crunchy PostgreSQL for Kubernetes has achieved Red Hat OpenShift Operator Certification and provides Red Hat OpenShift users with the ability to provision trusted open source PostgreSQL clusters, elastic workloads, high availability, disaster recovery, and enterprise authentication systems. By integrating with the Red Hat OpenShift platform within ORock’s cloud environments, Crunchy PostgreSQL for Kubernetes leverages the ability of the Red Hat OpenShift Container Platform to unite developers and IT operations on a single FedRAMP-compliant platform to build, deploy, and manage applications consistently across hybrid cloud infrastructures.

Hardware, Science and History

  • An Open Source Toolbox For Studying The Earth

    Fully understanding the planet’s complex ecosystem takes data, and lots of it. Unfortunately, the ability to collect detailed environmental data on a large scale with any sort of accuracy has traditionally been something that only the government or well-funded institutions have been capable of. Building and deploying the sensors necessary to cover large areas or remote locations simply wasn’t something the individual could realistically do. But by leveraging modular hardware and open source software, the FieldKit from [Conservify] hopes to even the scales a bit. With an array of standardized sensors and easy to use software tools for collating and visualizing collected data, the project aims to empower independent environmental monitoring systems that can scale from a handful of nodes up to several hundred.

  • The Early History of Usenet, Part II: Hardware and Economics

    There was a planning meeting for what became Usenet at Duke CS. We knew three things, and three things only: we wanted something that could be used locally for administrative messages, we wanted a networked system, and we would use uucp for intersite communication. This last decision was more or less by default: there were no other possibilities available to us or to most other sites that ran standard Unix. Furthermore, all you needed to run uucp was a single dial-up modem port. (I do not remember who had the initial idea for a networked system, but I think it was Tom Truscott and the late Jim Ellis, both grad students at Duke.) There was a problem with this last option, though: who would do the dialing? The problems were both economic and technical-economic. The latter issue was rooted in the regulatory climate of the time: hardwired modems were quite unusual, and ones that could automatically dial were all but non-existent. (The famous Hayes Smartmodem was still a few years in the future.) The official solution was a leased Bell 801 autodialer and a DEC DN11 peripheral as the interface between the computer and the Bell 801. This was a non-starter for a skunkworks project; it was hard enough to manage one-time purchases like a modem or a DN11, but getting faculty to pay monthly lease costs for the autodialer just wasn't going to happen. Fortunately, Tom and Jim had already solved that problem.

  • UNIX Version 0, Running On A PDP-7, In 2019

    WIth the 50th birthday of the UNIX operating system being in the news of late, there has been a bit of a spotlight shone upon its earliest origins. At the Living Computers museum in Seattle though they’ve gone well beyond a bit of historical inquiry though, because they’ve had UNIX (or should we in this context say unix instead?) version 0 running on a DEC PDP-7 minicomputer. This primordial version on the original hardware is all the more remarkable because unlike its younger siblings very few PDP-7s have survived. The machine running UNIX version 0 belongs to [Fred Yearian], a former Boeing engineer who bought his machine from the company’s surplus channel at the end of the 1970s. He restored it to working order and it sat in his basement for decades, while the vintage computing world labored under the impression that including the museum’s existing machine only four had survived — of which only one worked. [Fred’s] unexpected appearance with a potentially working fifth machine, therefore, came as something of a surprise.

Audiocasts/Shows: Linux Action News and Open Source Security Podcast

Red Hat and Containers

  • Queensland government looks to open source for single sign-on project

    Red Hat Single Sign-On, which is based on the open source Keycloak project, and the Apollo GraphQL API Gateway platform will be the two key software components underpinning a Queensland effort to deliver a single login for access to online government services. Queensland is implementing single sign-on capabilities for state government services, including ‘tell us once’ capabilities that will allow basic personal details of individuals to be, where consent is given by an individual, shared between departments and agencies.

  • Red Hat Releases Open Source Project Quay Container Registry
  • Red Hat open sources Project Quay container registry

    Yesterday, Red Hat introduced the open source Project Quay container registry, which is the upstream project representing the code that powers Red Hat Quay and Quay.io. Open-sourced as a Red Hat commitment, Project Quay “represents the culmination of years of work around the Quay container registry since 2013 by CoreOS, and now Red Hat,” the official post reads. Red Hat Quay container image registry provides storage and enables users to build, distribute, and deploy containers. It will also help users to gain more security over their image repositories with automation, authentication, and authorization systems. It is compatible with most container environments and orchestration platforms and is also available as a hosted service or on-premises.

  • Red Hat declares Quay code open

    Red Hat has open sourced the code behind Project Quay, the six year old container registry it inherited through its purchase of CoreOS. The code in question powers both Red Hat Quay and Quay.IO, and also includes the Clair open source security project which was developed by the Quay team, and integrated with the registry back in 2015. In the blog post announcing the move, Red Hat principal software engineer – and CoreOS alumnus – Joey Schorr, wrote, “We believe together the projects will benefit the cloud-native community to lower the barrier to innovation around containers, helping to make containers more secure and accessible.”

  • New Open Source Offerings Simplify Securing Kubernetes

    In advance of the upcoming KubeCon 2019 (CyberArk booth S55), the flagship event for all things Kubernetes and Cloud Native Computing Foundation, CyberArk is adding several new Kubernetes offerings to its open source portfolio to improve the security of application containers within Kubernetes clusters running enterprise workloads.

  • Java Applications Go Cloud-Native with Open-Source Quarkus Framework

    "With Quarkus, Java developers are able to continue to work in Java, the language they are proficient in, even when they are working with new, cloud-native technologies," John Clingan, senior principal product manager of middleware at Red Hat, told IT Pro Today. "With memory utilization measured in 10s of MB and startup time measured in 10s of milliseconds, Quarkus enables organizations to continue with their significant Java investments for both microservices and serverless." Many organizations have been considering alternative runtimes to Java, like Node.js and Go, due to high memory utilization of Java applications, according to Clingan. In addition, Java’s startup times are generally too slow to be an effective solution for serverless environments. As such, Clingan said that even if an organization decided to stick with Java for microservices, it would be forced to switch to an alternative runtime for serverless, or functions-as-a-service (FaaS), deployment.

  • Styra Secures $14M in Funding Led by Accel to Expand Open Source and Commercial Solutions for Kubernetes/Cloud-native Security

    New technology—like Kubernetes, Containers, ServiceMesh, and CICD Automation—speed application delivery and development. However, they lack a common framework for authorization to determine where access should be allowed, and where it should be denied. Styra’s commercial and open source solutions—purpose-built for the scale of cloud-native development—provide this authorization layer to mitigate risk across cloud application components, as well as the infrastructure they are built upon.