Over the past several years, engineers at Intel have worked to stabilize Mesa development by eliminating regressions on Mesa's master branch. Together with Clayton Craft, I'd like to co-present some statistics about this effort to help people understand why the system has been remarkably effective for the community. Additionally, we would like to demonstrate the new public interface for Mesa developers to access their test results.
Some of the features of Intel's CI:
(*) planned for implementation before XDC
Community developers will be interested in the new public access to test results, which has been our most requested feature for several years. We seek input on refining the interface, and suggestions for features to add.
It may be that our test results will be hosted on FDO by XDC. If not, we would like to discuss impediments to hosting the data with attendees.
You're probably familiar with some CPU instruction set. Each has its own collection of oddities — some weirder than others. Many instruction sets come to be known primarily by those oddities: MIPS' delay slots, Alpha's lack of byte/word load and store, SPARC's register windows, and x86's... overall complexity (think: multiple addressing modes, special roles of general purpose registers, etc). GPUs instruction sets are necessarily different from CPUs and still have their own quirks. Intel's i965 instruction set is pretty quirky and makes for some interesting optimization challenges. It shares some features common in other GPU instruction sets like source and destination modifiers, instruction predication, and a unified register file; but also has some features that are at least uncommon: mixed type operations, vector immediates, conditional modifiers, and the oddity that should define the instruction set: register regioning. In this article, I hope to give the reader enough knowledge to read basic i965 assembly and to at least fear (if not appreciate!) some of the weird and wonderful ways we use it in the i965 compiler.
Recently the amdgpu’s (AMD’s graphics driver) scheduler was shifted to a shared space (now called DRM GPU scheduler) so that the other drivers can reuse the code. The GPU scheduler is now used by amdgpu, etnaviv (graphics driver for Vivante GPUs), and recently the Broadcom V3D driver. In this talk I will discuss my experience of adding a new feature of dynamic scheduling to the scheduler and also improving the scheduler code in general from the point of view of a newbie. My work involved adding documentation, cleaning the API and refactoring the code. Improving the scheduler will encourage others drivers to shift to using the common scheduler.
Note: GSoC - maybe compress to a half slot?
The Kernel Mode-Setting (KMS) is a mechanism that enables a process to command the kernel to set a mode (screen resolution, color depth, and rate) which is in a range of values supported by graphics cards and the display screen. However, over the past few years, the demand for testing tools built on top of KMS arises since it could bring benefits for DRM users. In this sense, creating a Virtual KMS (VKMS) become convenient in order to support the development of compositors, display servers protocol, fake output, and improve test coverage. For example, VKMS could be used for running X or Wayland on a headless machine (to be able to still use the GPU). In 2018, Hannen and I started the development of VKMS as our project in the Outreachy and GSoC, respectively. VKMS is a work in progress project; however, it already has the basic infrastructure that counts with the support for crc and vblank. In this presentation we want to introduce the VKMS work progress, and also share our experience as a newcomer in the community.
Note: Gsoc/Outreachy shared/split slot.
Recent low-overhead 3D APIs like Vulkan, an influx of low power CPUs, and timing-sensitive workloads like VR have brought a spotlight on OpenGL driver overhead. Although Vulkan is likely to be the best for low CPU overhead, many applications still use OpenGL. This begs the question: can we make our OpenGL drivers leaner and faster? How much?
At the culmination of nearly a year's worth of effort, Ken will present a new Gallium-based driver for Intel hardware, iris_dri.so, and compare the draw time overhead of Iris and i965.
The Clover Gallium state tracker inside mesa is an OpenCL 1.1 implementation for radeon and radeonsi driven GPUs. It uses LLVM to parse OpenCL C code and therefore only available for architectures with an LLVM backend.
Rob Clark, Pierre Moreau and Karol Herbst have been working on adding OpenCL for other architectures by taking OpenCL C code and converting it into SPIR-V. As SPIR-V can be translated into NIR, this allows every driver with a NIR backend inside mesa to be used for OpenCL as well.
We want to talk about the main tasks involved in this, what the biggest challenges are, how mesa drivers can make use of this work to get OpenCL support effortless and what possibilities this might bring us for the future.
Main topics:
An update on freedesktop.org, which hosts the development of projects including Cairo, Mesa, KMS, Pixman, Wayland, and X.Org. fd.o has recently deployed GitLab for its member projects: this will present the status and next steps for projects, as well as invite feedback. It will also outline the current governance of fd.o - a separate organisation to the X.Org Foundation but also under Software in the Public Interest - and discuss our future plans for the organisation.
Note: Maybe compress to a half-slot?
Your secretary delivering the yearly report of the X.org Foundation.
Smooth animation of graphics requires that the presentation timing of each frame be controlled accurately by the application so that the contents can be correctly adjusted for the display time. Controlling the presentation timing involves predicting when rendering of the frame will be complete and using the display API to request that the frame be displayed at a specific time.
Predicting the time it will take to render a frame usually draws upon historical frame rendering times along with application heuristics. Once drawn, the display API is given the job of presenting the content to the user at the specified time. A failure of either of these two mechanisms will result in content being delayed, and a stuttering or judder artifact made visible to the user.
Historical timing information includes both the time taken to render a frame with the GPU along with the actual time each frame was displayed to the user. Ideally, the application will also be given some estimate of how long it will take to ready the frame for display once the presentation request has been delivered to the display system. With these three pieces of information (application GPU time, actual display time, presentation overhead), the application can estimate when its next frame will be ready for display.
The following work is underway to provide applications this information and to improve the accuracy of display presentation timing in the Linux environment.
1) Vulkan GOOGLE_display_timing extension implementation in Mesa. This offers applications some fairly straightforward measurements that can help predict when a frame timing target might be missed.
2) Heuristics in the X Composite and Present extension implementations to improve accuracy of reported display times to Present-using applications
3) Additions to Composite that replace the above heuristics with precise timing information for Compositing managers modified to support these additions.
4) Semi-automatic compositing support added to the Composite extension which allow in-server compositing of some windows to reduce variability in the display process.
This presentation will describe the above work and demonstrate the benefits of the resulting code.
Since OpenGL 2.0, released more than 10 years ago, OpenGL has been using OpenGL Shading Language (GLSL) as a shading language. When Khronos published the first release of Vulkan, almost 2 years ago, shaders used a binary format, called SPIR-V, originally developed for use with OpenCL.
That means that the two major public 3D graphics API were using different shading languages, making porting from one to the other more complicated. Since then there were efforts to allow making this easier.
On July 2016, the extension ARB_gl_spirv was approved by Khronos, that allows a SPIR-V module to be specified as containing a programmable shader stage, rather than using GLSL, whatever the source language was used to create the SPIR-V module. This extension is now part of OpenGL 4.6 core, making it mandatory for any driver that wants to support this version.
The implementation of this extension for the Mesa driver, focused on the i965 intel driver, was started at the end of 2017. A first talk about the status of such implementation was done this year on FOSDEM. This talk on XDC would present all the updates, and in general it will explain the extension, what advantages provides, how is being implemented for the Mesa driver, and how much is pending to get it enabled.
Exploring Android-86 as a Desktop OS, we will cover the current roadmap, hardware and driver support, latest developments and outstanding work.
We will also take a closer look at the graphics stack itself - the hwcomposer, gralloc implementations their evolution and current support.
The current status of Mesa, combined with LLVM version support will be presented.
Testing results on various hardware will be presented, alongside the current limitations and workarounds needed.
As a finale, a demo of the whole stack, including Vulkan, will be available.
Systems with multiple GPUs are becoming more common.
At the same time, GL developers have limited means of enumerating or selecting which one to use in their application - a feature widely available in other APIs such as OpenCL, Vulkan.
Presently, users can select the GPU by setting the environment variable DRI_PRIME. Although that approach is partial and more importantly, Mesa specific.
This talk will cover how we can utilise the EGLDevice extensions to achieve that goal, and the status of these extensions in Mesa. A set of analogous GLXDevice extensions will be presented.
To wrap it up, Waffle will be used as a demonstration vehicle. Providing a new, simple interface for applications to use.
The linux kernel community highly dislike drivers calling get_user_page() and holding page reference for extended period of time. Most existing GPU driver user can be converted to use the HMM page table snapshoting capabilities which completely avoid the pin issue. This talks is as much a presentation about the get_user_page() pitfalls and wrong belief people have about it than a presentation about one aspect of HMM which can be use with all GPU hardware ie does not rely on any specific hard- ware feature.
The FOSS GPU virtualization stack has never before seen as intensive progress as in the the last months. As David Airlie put ”virgl hasn’t see this much de- velopment”. Virglrenderer started as a research project to investigate the possibility of cre- ating a virtual 3D GPU for use inside qemu virtual machines that allows the guest operating system to use the capabilities of the host GPU to accelerate 3D rendering [1].
This talk will go throught an introduction of the Open Source graphics virtual- ization stack, look at history of the project and at what is happening to take it to production level.
Finally, the future plan for the GPU virtualization stack will be shared, like the support OpenGL ES 3.1, OpenGL ES 3.2 and Vulkan on the guest side, improvements to the performance and security of the stack. The audience is invited to share and discuss ideas as well.
[1] https://virgil3d.github.io/
Mesa3D, or just Mesa, is an open source project that implements different graphic drivers from different vendors, both official and non-official: Intel, AMD, Nvidia, etc. These drivers implements both the different OpenGL/OpenGL-ES versions, as well as the new Vulkan API. We could safely say that this is the “official” open-source library for OpenGL and Vulkan, and thus used in many of the Linux distributions and ChromeOS devices.
Being a very active project that involves different hardware vendors and different API implementations, a special careful must be taken when doing the releases: an error introduced can lead from a simple unexpected behaviour to a system freeze.
In order to reduce the risk of committing such mistakes, we, as part of the release team, follow an strict process to choose which changes will be part of next releases, that involves interacting with the community, following a strict scheduling release, performing proper testing, and so on.
Regarding the testing process, nowadays Intel kindly provides a very complete testing system that we use when doing the releases to detect regressions. But other than that there is no official/free test system.
But the recent migration of Mesa3D repository to Freedesktop’s GitLab server gives new opportunities to use the Continuous Integration that GitLab provides. In fact, we at Igalia are using an unofficial GitLab CI setup to automate the testing process, helping to detect any issues as soon as possible.
So in this talk, we will cover both the release process and the testing process we follow to ensure everything works correctly. Specifically, we will give a brief introduction about how the release process has evolved in time, explain the current procedure we follow nowadays (how patches are selected for releases, what are the scheduling used for the releases, etc.), talk about how the test is done, with specially emphasis in the GitLab CI setup we use, and finally how the current process can be improved for the future.
In his kick-off talk, Jason will present the new timeline semaphores feature that has been proposed for Vulkan. This will be followed by a break-out session to get alignment on the design of the new kernel ABI that will be required to support timeline semaphores.
Panfrost aims to provide an open source 3D driver for the Midgard (Txxx) and Bifrost (Gxx) series of Mali embedded GPUs from ARM via reverse-engineering. The talk will include a brief history of the reversing work done on Mali thus far, a basic rundown of what we know about Midgard and Bifrost's ISA, and a summary of the tools we've written along the way. And yes, there will be a demo!
Intel GPUs (Haswell and later) include a feature that allows to monitor workloads submitted to the hardware. This observation feature provides a precise way to measure particular events throughout the GPU with precision timing in the range of 100s of nanoseconds. This hardware feature is one of the main provider of graphics performance data for tools like FrameRetrace [1] or GPA [2]. Making use of this feature allows these tools to give developers insights into the effect of a particular draw call or frame. It can also be used to monitor the use of the GPU throughout context switches between the different applications running on the system. Finally it has also been successfully used by the team working on the Intel open source 3D driver (part of the Mesa project) to identify potential driver bottlenecks.
This talk will provide an overview on how the observation feature is used throughout the graphics stack. We’ll start with a brief description of the hardware capability, then go through the i915 kernel driver interface and looks at the two different modes applications can use this interface either query mode (measuring the effect a of particular set of commands) or monitoring mode (measuring aggregated data over sampling period for the entire system).
Finally we’ll be looking at GPUTop [3], a tool that tries to give a system-wide view of how the GPU is used by different applications running on the system. We’ll walk through of the different metrics and timelines available in this tool.
[1] : https://github.com/janesma/apitrace/wiki/frameretrace-branch [2] : https://software.intel.com/en-us/gpa [3] : https://github.com/rib/gputop
Note: Needs to be scheduled before Fri 12pm