19:00 | Pre-conference social event @ Bierhaus
| 09:00 | Check In / Badge Pickup / Coffee / Opening Session |
|---|---|
| 09:45 | Ben Widawsky (Intel) - Modifiers and implementing end to end compression on Intel |
| 10:30 | Break / Morning Snack |
| 11:00 | James Jones (NVIDIA) - Unix Device Memory Allocation Update |
| 12:00 | Lunch @ Google |
| 13:00 | Laura Abbott (Red Hat) - Ion future and open discussion |
| 14:00 | Alex Goins (NVIDIA) - DeepColor: On-screen HDR Drawables in X |
| 15:00 | Break / Afternoon Snack |
| 15:30 | Martin Peres (Intel) - Intel GFX CI - What services we provide, our roadmaps, and how to replicate our efforts for other drivers |
| 16:30 | Mark Janes (Intel) - Frame Analysis with GPU Performance Counters |
| 17:30 | Demos |
| 17:30 | Gwan-gyeong Mun - Mesa for Tizen Platform (Video) |
| 17:40 | Pierre-Loup A. Griffais - gpuvis, a Visual Debugging Tool for GPU Scheduling (Video) |
| 17:50 | Kevin Brace - OpenChrome demo (Video) |
| 18:00 | Google Hosted Happy Hour @ Google |
| 09:00 | Opening Session / Coffee |
|---|---|
| 09:15 | Kaveh Nasri (Intel) - Mesa i965: Scenes from a Quiet Revolution |
| 10:00 | Break / Morning Snack |
| 10:30 | Eric Anholt (Broadcom) - Status of the Broadcom's vc4 driver |
| 11:30 | Daniel Vetter (Intel) - dim tooling and commit rights |
| 12:00 | Lunch @ Google |
| 13:00 | Zhenyu Wang (Intel) - Full GPU virtualization in mediated pass-through way |
| 14:00 | Tom Stellard (Red Hat) - Current state of Open Source GPGPU |
| 15:00 | Break / Afternoon Snack |
| 15:30 | Kevin Brace (The OpenChrome Project maintainer / developer) - Reviving the Development of OpenChrome |
| 16:15 | Manasi Navare (Intel) - A Journey through Upstream Atomic KMS to achieve DP Compliance |
| 17:00 | X.Org Board Meeting |
| 18:00 | Collabora Hosted Happy Hour @ Steins Beer Garden |
| 09:00 | Opening Session / Coffee |
|---|---|
| 09:15 | Martin Peres (Intel) - Reducing the cost of upstream development to encourage collaboration |
| 10:00 | Break / Morning Snack |
| 10:30 | Robert Foss (Collabora) - drm_hwcomposer: A brief status update |
| 11:30 | Daniel Vetter (Intel) - State of the X.org |
| 12:00 | Lunch @ Google |
| 13:00 | Keith Packard (Valve) - DRM Leasing |
| 14:00 | Kyle Brenneman (NVIDIA) - GLVND |
| 15:00 | Break / Afternoon Snack |
| 15:30 | Lightning Talks / Demos |
| 15:30 | Michal Lukaszek & Lukasz Spintzyk - Partial Updates in DRM Atomic (Slides, Video) |
| 15:35 | Francisco Jerez - Improving Graphics Performance through Energy Efficiency (Slides, Video) |
| 15:50 | Karol Herbst & Martin Peres - Nouveau updates (Slides, Video) |
| 16:00 | Dongseong Hwang - DRM Atomic and Hardware Overlays in Chrome OS (Video) |
| 16:10 | Brian Paul - Piglit Discussion (Slides, Video) |
| 16:25 | Adam Jackson - xserver 1.20 planning (Video) |
| 16:35 | Pierre-Loup A. Griffais - Mesa Regression Testing for Steam Games (Slides, Video) |
| 16:45 | Chad Versace - DRM Format Modifiers and dma-bufs in Vulkan (draft specs, Slides, Video) |
| 16:45 | Closing Session |
Modern GPUs feature a lossless compression for surfaces as they are operated upon within the GPU pipeline. The purpose of this compression is to reduce precious memory bandwidth. Supporting this in a modern graphics software stack requires every component participating - compositor, display server, buffer managers, mesa, and the KMS drivers. This talk will go over the technical details of the solution, as well as use Intel's experience of a case study on implementing this on a modern graphics software stack.
Ion is a buffer allocation framework originally created by Google for Android graphics. It currently exists as a framework under drivers/staging although it is likely to move out sometime in the near future. There's been interest outside of Android in something Ion-like as well. The goal of this talk is to give a (brief) overview of where Ion is today and present some of the open problems for discussion. This talk has been given elsewhere but the focus will be on problems relevant to the greater graphics community. Topics may include: - ABIs for the /dev space and heap specification - Android currently has a libion userspace framework. Is this something that might make sense to integrate as part of libdrm? - Integration with other testing frameworks - debugging infrastructure and possible integration with dma_buf
At XDC 2016 we began developing a consensus design for a userspace API responsible for allocation of device-accessible memory on Unix. Since then, discussions have progressed and a prototype-quality implementation has been completed. Moving forward requires addressing minor shortcomings and open issues in the current design identified while prototyping, namely device management, format description, and capability granularity.
Additionally, a number of difficult problems remain. Detailed discussion of the mechanisms needed to make use of the device memory allocations within graphics APIs such as Vulkan and OpenGL was left out of last year's sessions, both to limit the scope and because related mechanisms in Vulkan and GL themselves were still under development.
In this year's presentation I will discuss problems encountered and lower-level design decisions made while implementing the prototype code, present a design proposal to allow efficiently using the generically-allocated device memory allocations in the OpenGL and Vulkan graphics APIs, and further discuss the interactions between the userspace allocation library and kernel drivers.
HDR, or High Dynamic Range, high precision rendering has been utilized by graphics applications for years. The limited capabilities of displays, however, have forced applications to tonemap their results down to the standard 8 bits per component before reaching the end of the display pipeline. As a result, there has been no need for on-screen drawables to support higher precision, with such rendering exclusively used in pre-processing stages. At XDC 2016, however, Andy Ritger spoke about the development of displays that support HDR standards such as HDR10, and the need to take advantage of these capabilities; composition and display pipelines, including X's, must support higher precision and floating point on-screen drawables to cover the variety of linear and non-linear HDR formats.
Since Andy's presentation, there has been an ongoing effort to design a solution for the X graphics stack, driven by the excitement of customers and developers at the prospect of higher fidelity graphics afforded by a much larger color gamut. Although Vulkan and EGL have received extensions for specifying a variety of HDR colorspaces, X has lacked the capability to use these surfaces as backing for on-screen drawables. In an effort to make that happen, a proposal has been made to create the DeepColor Extension to X, an extension that provides a new visual class, DeepColor, for use with on-screen HDR drawables. In this presentation we will discuss the progress and challenges pertaining to this effort pursued with the support of the X.Org community.
Although the DeepColor extension specifies how on-screen drawables interact with the X server and the composition pipeline, it intentionally leaves room for a variety of different implementation techniques both with and without the use of an external compositor. In addition to discussion pertaining to the drafting of the DeepColor X extension, we will also discuss our efforts regarding the implementation of HDR support in the NVIDIA driver's display pipeline.
I'd like to give a status update of the Broadcom graphics stack at XDC2017. It would include:
Summary of the state of vc4 3D: performance and featureset compared to the closed driver. Hopefully an announcement that it's enabled by default in Raspbian.
Summary of the state of vc4 KMS: feature comparison and what's left to do before we can kill off the closed source display stack (which is most of the closed source firmware)
Architecture of the new vc5 3D stack, featureset being exposed, and feature completeness. Lessons learned from vc4 development that are being applied, improvements in Mesa architecture that make it easier.
Future directions -- Vulkan, CL for vc5. Hopefully open discussion of how CL should be done.
GPU virtualization has an increasing requirement from cloud service providers who want to utilize GPU power in many kinds of cloud based workloads e.g media codec transcoding, remote graphics desktop, remote gaming, machine learning training acceleration, etc. For cloud environment, GPU virtualization can provide GPU hardware acceleration for virtual machines to fulfill the requirement of those applications. Our purpose is to do full GPU hardware virtualization for best compatibility across different VM systems.
GPU virtualization can be provided for usual VM hypervisors e.g KVM/XEN, so guest VM can utilize GPU acceleration through virtualized GPU device. It can also be applied for VM technology based container implementation which can support GPU acceleration for container based applications as well.
Although there's new trend that GPU hardware vendors would increasingly provide hardware features for virtualization requirement, this present is still focus on software solution of GPU virtualization without special hardware features.
So besides initial capability to directly pass-through GPU hardware to single VM via VT-d/IOMMU, current demand is to be able to share GPU resources between multiple VMs. This present will try to elaborate Intel's current solution in upstream named as "Intel GVT-g" (GPU Virtualization Technology) with mediated pass-through way to provide full GPU virtualization.
The new vGPU (virtual GPU) device model provides mediation of GPU hardware resource access from multiple VMs and one virtual GPU device is provided for each VM. The virtual GPU device has full hardware features that guest VM can use native graphics driver stack (Xorg, mesa, libva, etc.) without change just like on normal host, all types of graphics workload e.g 3D/compute/media can be supported in VM, only guest kernel DRM/i915 driver needs change for some para-virtualization requirement.
This present will cover state of art work in upstream components including DRM/i915, VFIO/mdev and KVM/qemu on current architecture for this mediated pass-through framework. It will cover vGPU device model details on how it manages shared GPU resource between virtual machines. Also explain current kernel interface based on VFIO/mdev (mediated device) framework for virtual GPU device assignment in VM and resource access. Current validation result on Intel server GPU will also be presented.
In this talk I will review the current status of various Open Source GPGPU API implementations, and discuss some possible directions in the future. I will be looking at the many OpenCL implementations and also what is out there for other APIs, like CUDA, OpenMP, ROCm etc. I will also cover the state of intermediate representations, like SPIR-V, and how these fit into to existing or future GPGPU solutions. And finally I'll discuss how we can support more GPGPU APIs with mesa.
During this technical talk session, the state of The OpenChrome Project will be discussed. OpenChrome is a FOSS device driver stack targeting Linux and BSD based OSes for VIA Technologies Chrome family of IGPs (Integrated Graphics Processors). Topics covered will include the history of The OpenChrome Project, personal episodes related to the development, and the current status of OpenChrome graphics device driver stack. In addition to that, the developmental philosophy behind OpenChrome and the presenter’s own experience of dealing with the development will be discussed as well. Finally, the presenter will discuss the status of drm-openchrome (the next generation OpenChrome DRM with Kernel Mode Setting support), the developmental approach and challenges of developing drm-openchrome, and other graphics device driver development projects the presenter plans to work in the future.
Ever hooked up a Linux Computer to a monitor only to experience...nothing? DP is far from being a dumb cable and requires that the entire graphics stack works together to gracefully handle mode failures and recover them. Achieving DP compliance requires that the kernel drivers, hotplug events and the userspace compositors all work together to render every frame at requested rate e.g by handling a link failure. The Linux Kernel's modesetting infrastructure on the other hand is a daunting beast of its own and understanding how all the pieces interact is a challenge in itself. In this talk Manasi will present the ultimate technical solution for DP compliance ensuring a successful modeset that is recently upstreamed. She will share her journey through iterating designs and working together with upstream maintainers, collaborating with X-server community, learning all about how KMS works and ramping up on the graphics subsystem.
I've been working on FrameRetrace, a new performance analysis tool which identifies costly draw calls in an OpenGL frame. Until recently, FrameRetrace was dependent on GPU performance counters which were not upstream in Mesa and the Linux kernel.
Now that performance counters are available in drm-tip, FrameRetrace is ready to be shared with the Linux graphics community. While FrameRetrace is still an initial implementation, it has identified several performance issues in the i965 driver.
FrameRetrace features that may interest XDC attendees:
Description and some screenshots are available at: https://github.com/janesma/apitrace/wiki/frameretrace-branch
I'd like to get feedback and suggestions as I continue to develop FrameRetrace. If possible, I'd like to collaborate with others to add support for non-Intel hardware. Any immediate rendering platform with GPU performance counters will benefit from FrameRetrace's per-draw-call analysis.
My current efforts are focused on the use cases for Mesa driver developers, as we identify and close performance gaps. However, FrameRetrace can help a game developer debug performance and rendering problems with any GL application. Developers from Unity3d and Feral Interactive have stated to me that lack of basic frame analysis tools are an impediment to developing games on Linux. My hope is that with proper hardware support, FrameRetrace will fill this gap.
In the past year, the continuous integration of the i915 driver has been picking up and is massively improving the state of the driver by doing both pre- and post-merge testing.
During the summer, we have made a big effort to publicly provide timely, stable, and actionable reports in order to improve the developers' involvement. Not only did it successfully change the way Intel developers are working (more focus on bug fixing), and made the drm-tip tree more stable, but it also lead to bigger involvement in the IGT test suite development as well.
In this talk, I would like to show i915 developers what is currently available to them, what's coming next, and inspire other teams working on other drivers to provide similar service through sharing our key learnings and tools.
Since 2 years we've switched to a commit rights model for the drm/i915 kernel driver, and since one year we've also maintained the drm-misc tree in the same fasion. This talk will dive a bit the "dim" maintainer script tooling and documentation we're using, and cover testing, process and tooling challenges that result from trying to retrofit a modern developement flow onto the kernel community.
As the manager of the Mesa i965 team at Intel for the past 6 years, I have witnessed Mesa gradually move from the back of the pack to the very front of 3D Linux drivers. This talk will be a recounting of some of the key learnings and personal observations from this journey.
The road to industry leadership was a tough but ultimately satisfying one for the community. The presentation will touch on the factors that led the success of Mesa i965. Looking forward there are many challenges that remain in front of the community in expanding the reach of open source graphics driver and their deployment.
It took a determined community to push Mesa to the forefront of 3D computing. It is up to the same community to band together to tackle these new challenges and ensure the long term success of Mesa and open source graphics. The goal is to bring forward a day when closed source graphics drivers are talked about only in history books!
Linux has almost achieved world domination. However, most of the world is stuck on ancient releases, which is not only a security issue, it is also fragmenting the development effort as features and bugs need to be backported to ancient releases, and additional support written on these kernels are unlikely to be upstreamed.
At best, when making a new device, device vendors fork the upstream Linux kernel. At worst, they have to base their work on a non-upstream kernel, probably coming from the company providing the SoC being used, which is often already ancient, even before the device comes out. In both cases, they then add support for the missing features, do the device validation and ship the kernel (and its source) in their devices.
Some device vendors are nice-enough to also upstream their changes, but this process is time consuming and may require the re-design of the code. When the changes actually land, it is quite likely that they will get broken despite the strong non-regression rule of Linux. This is because of the limited amount of users using the upstream kernel on their devices, which means developers are not aware that they are regressing some plaforms. This pretty much means that device vendors have to re-do the bring-up of the device on a subsequent release, which somewhat makes the upstreaming investment close to useless.
In this presentation, I will present motivate the testing of the kernel from a graphics perspective, the current projects doing kernel testing, and propose ways of providing pre-merge and post-merge testing on vendor devices.
Started at LCA last year in Hobart, the new DRM Leasing mechanism allows applications to take over a set of display resources from the window system and drive them directly. These changes involved modifications to the Linux kernel, X window system and Mesa Vulkan implementation. This new system brings proposed Vulkan extensions for direct display operation to the DRM environment.
The presentation will discuss the design and implementation of the system, along with highlights of the development process and a live demonstration of the resulting system.
All of this free software was developed under contract with Valve, who are using it to provide support for the HTC VIVE HMD.
Your secretary delivering the yearly report of the X.org Foundation.
Since last years presentation lot of progress has been made in the drm_hwcomposer ecosystem, and it is now getting close to being shipped in actual products.
It has been successfully brought up on Freedreno and Etnaviv based platforms, and has seen attention from a wide array of vendors. Support for the HWC2 protocol was added as a product of Gustavo Padovan's fence work, which drm_hwcomposer was the first user of, and it is in the progress of being upstreamed. The HWC2 work has seen contributions from Zach Reizner, Sean Paul, Rob Clark, Kalyan Kondapally, Gustavo Padovan and myself.
The bringup process has been relatively painless in terms of drm_hwc, but there is still work that needs to be done in terms of stability, ironing out some bugs, but also potentially increasing the feature set.
Futher hardware bringup work is needed for much of the hardware that is supported by mesa, and good targets like the Raspberry Pi / VC4 are ripe for the picking.
This talk aspires to raise awareness of drm_hwc and start a dialogue about the future it:
Libglvnd is a vendor-neutral dispatch layer for OpenGL that forwards OpenGL, GLX, and EGL function calls to one or more vendor-specific OpenGL implementations. This allows multiple drivers and their OpenGL implementations to coexist on the same filesystem, even within a single process.
The GLX and EGL client libraries are now implemented and are supported by both Mesa and the NVIDIA driver. However, server-side GLX still only allows one vendor implementation at a time.
This presentation will give a brief overview of the EGL and GLX client libraries. It will then focus on vendor neutral dispatching of server-side GLX. Combined with the existing GLVND client libraries, vendor neutral dispatch of server-side GLX will enable different vendors' GLX implementations on different X screens within an X server.