_index

XDC2015 Program

Topics

As usual, we are open to talks across the layers of the graphics stack, from the kernel to desktop environments, and about how we make things better for the developers who build them. if you're not sure if something might fit, mail or add it anyway, and find out if there's room in the schedule.

If you don't want to follow the formal talk submission with the CFP you can also just list your talk below. Some proposals are marked as "formally accepted", this means they got submitted to the board of directors before the deadline and got accepted by the election committee.

Usually, all the proposals we get receive a slot during the conference, but this is not guaranteed. Selection will be done by the program director based on content and submission date.

Talks

Atomic Modesetting for Drivers

Atomic has finally landed and a bunch of drivers are converted or in the process of being converted. This talk will look at the internals from a driver's writer pov, covering the atomic helper library, how it all can be (ab)used for certain cases and how to implement certain common hw features. It'll feature lots of examples from existing atomic drivers, too.

Slides, Youtube

Presenter: Daniel Vetter

An Introduction to PS/2 and ps2emu

The project I'm hoping to present is ps2emu, a set of userspace tools and a kernel module that allow userspace communication with the kernel's serio, the low-level interface for input devices that go across serial protocols like PS/2, driver. The userland tools allow for the recording and playback of PS/2 devices to aid with the development of input drivers and potentially to aid with regression testing.

You can find the current git repository for the userland ps2emu tools here: https://github.com/Lyude/ps2emu and you can find the git repository with the kernel patches here: https://github.com/Lyude/ps2emu-kmod

Slides, Youtube

Presenter: Stephen Chandler Paul

Status update of NVIDIA's performance counters for Nouveau

Hardware performance counters are a set of special registers which store hardware-related activities. They are are used by developers to identify performance bottlenecks in their applications. NVIDIA hardware exposes two kinds of counters that provide data directly from various points of the GPU. Compute counters are mostly used by CUDA/OpenCL, while graphics ones give detailed information about how the OpenGL/Direct3D pipeline is used. CUPTI and respectively PerfKit expose those counters on both Linux and Windows for the first and only on Windows for the latter. For Nouveau I had to implement the whole infrastructure from the kernelspace to the userspace in order to expose them in a decent manner for the end-users. In this talk, I'll explain how I RE'd perf counters on NVIDIA hardware, as well as the interface being made available to access them. I'll talk about how they are implemented in Nouveau and Mesa. And I'll describe two different user-friendly APIs which can be used to monitor these performance counters in OpenGL applications. Lastly, I'll describe what work remains to be done and next steps.

Slides, Youtube

Presenter: Samuel Pitoiset

State of the X.Org Foundation

The annual update. Expect thrill, excitement, confetti, balloons, a pink elephant or none of the above.

Slides, Youtube

Presenter: Peter Hutterer

X.Org Board Meeting

This is not a talk, consider this a placeholder in the program to leave some time for the X.Org board meeting. Preferably at the end of a session; before lunch, or at the end of the day.

libinput update

An update on the current state of libinput and related bits.

Slides, Youtube, LWN recap

Presenter: Peter Hutterer

Status of the drm and kms (i915) drivers for Solaris

This talk will present the current status of existing drm/kms drivers on Solaris and porting of the current code and drivers to Solaris.

It will provide some history on the source base, some of the challenges in providing the current driver and porting to recent sources, as well as open discussion on how future work might be more efficient.

Slides, Sources, Youtube

Presenter: Randy Fishel

Handling shader recompiles in Radeon

Many drivers can’t compile shaders when applications load them and must resort to compiling shaders on the first use. This is due to the fact that many OpenGL API states are not supported by the underlying hardware and must be emulated using shader instructions. Compiling shaders on the first use results in unpleasant application stuttering and frame rate drop, because all OpenGL processing must stop while shaders are being compiled. A solution that works for the Radeon Graphics Core Next (GCN) hardware will be presented. It’s based on the idea that the shader code of OpenGL states that can be emulated at the beginning or end of shaders (e.g. alpha-test) can be separated into small independent shader binaries. Such binaries can be generated from current OpenGL states using a simple shader assembler accepting native shader instructions instead of using a complete shader compiler backend. This should enable very fast compilation. The resulting binaries can be concatenated with application-supplied shaders either at their beginning or end, depending on where they belong. This frees the application shaders from the state dependencies and allows them to be compiled when the application expects it. All OpenGL shader state dependencies that occur with Radeon GCN ranging from OpenGL 1.1 to 4.0 and how to handle them will be described in detail, including how to deal with various challenges resulting from the GCN hardware design.

Slides, Youtube

Presenter: Marek Olšák

Getting rid of select(2) in the X server

Olivier Fourdan and Adam Jackson fixed the server to allow for run-time selection of MAXCLIENTS. The requisite change in xproto ended up breaking the un-patched X server. This event raised a bunch of issues around how the X server manages file descriptors, in particular the use of file descriptor masks related to the select interface.

The current FD_ and XFD_ macros hard-code the maximum file descriptor that the server can use for blocking I/O operations. And, the current driver interfaces expose the related data structures throughout the server, so changing that value affects the ABI.

This talk will present a sequence of simple API/ABI changes that will make it possible to remove the select masks from the public interfaces, and then switch from using select to poll, epoll or kqueue so that the range of file descriptor values is no longer a factor for the server code.

No slides, Youtube

Presenter: Keith Packard

amdgpu updates

An update on the current status of amdgpu and our plans going forward.

Slides, Youtube, LWN recap

Presenters: Alex Deucher and Jammy Zhou

Memory Residency (Cancelled)

Open source GPU drivers are seeing use in areas which used to be the exclusive domain of out-of-tree binary drivers. Binary drivers had no restrictions on pinning/locking memory from userspace, and the ability to do so has been baked into userspace drivers and the APIs they expose - sometimes for convenience, but sometimes for performance or application programming flexibility. Recent hardware advances such as userspace command queues bring similar challenges. This talk will summarize the issues we have encountered and describe our plans for dealing with them.

Presenter: John Bridgman

Hardware-accelerated graphics on microkernels

The Tanenbaum-Torvalds debate continues, with academics promoting the security and reliability advantages of microkernels, while practitioners continue folding drivers into ring 0 in the name of performance. But in the realm of 3D graphics specifically, the open source graphics stack already looks remarkably like what you'd expect if it were running on a microkernel—not just for greater security and reliability, but also for performance reasons.

I'll give a brief introduction to microkernels and to Genode, which is building a userspace that's portable to a half-dozen different microkernels. Then I'll talk about experiments making Mesa and the Linux i915 driver run on Genode.

Slides, Youtube

Presenter: Jamey Sharp

Pitfalls of benchmarking graphics applications for performance tracking

Tracking the performance of our complex graphics stack is a necessity to avoid unintentional regressions in the performance of the most important games and benchmarks. Such regressions lead to unhappy open source gaming enthusiasts and wasted developer time who need to track down performance regressions sometimes months after they got introduced. Fixing such performance issues may also be a challenge as the code that introduced them may have become a dependency for newer features.

The need for performance tracking is becoming more and more critical as the complexity of our open source drivers increases to reach a performance comparable to their closed-source equivalent. This increased complexity makes it more and more likely for commits to accidentally break the performance of some benchmark/games on some platforms that the developer may not have convenient access to.

In an effort to detect performance regressions before they even hit mainline, automation should be increased. However, when it can take up to an hour to test the performance of one commit on one benchmark, it becomes clear that we will never have the necessary hardware to be able to test all the commits found on the mailing lists and we will have to be smarter than this.

In this presentation, I will describe the different challenges found in benchmarking, some surprising results, some tricks to reduce the variance between runs and what is my current plan for improving our performance QA by automatically tracking the performance, bisecting performance changes and letting everyone know about them by auto answering on the mailing list.

Slides, Youtube, LWN recap

Presenter: Martin Peres

Freeing one more SoC: Etnaviv status update

This presentation will give an overview about what has been going on in the Etnaviv community, where we are today and what we hope the achieve in the coming months.

Slides, Youtube, LWN recap

Presenter: Lucas Stach

Continuous Integration of Mesa at Intel

I've been working on Intel's Mesa team for the past year, setting up a continuous integration system to run piglit on all supported Intel hardware. This system has become an integral part of the tool set used by Intel's Mesa developers, with most engineers electing to test patches on the system before sending to the list.

A brief list of the features:

• automation is freely available, hosted at https://github.com/janesma/mesa_jenkins

• Broad selection of hardware from g33 to Skylake tested.

• dEQP tests run on selected hardware, on a nightly basis (in progress).

• developers force-push to a branch on their personal mesa repositories to trigger a test build.

• automated bisection of failures.

• filtering of failures caused by a stale branch point.

• git backup of CI configuration

• fully documented system configuration

• fully automated build/test machine installation and configuration

• standard Jenkins CI features (test history, notification, visualization, reliability)

I'd like to provide a tour of the system, describe the design choices that were made in setting it up, and describe the costs and benefits of this type of tool. Features that we have added to piglit and dEQP may encourage others to set up similar systems.

Additionally, I'd like to have a conversation about how this resource can be improved:

• additional test targets or platforms

• availability for Mesa developers outside of Intel.

• improved test machine configuration with salt

• performance improvements

Mesa developers have been disciplined and diligent in creating thousands of piglit tests. The piglit suite is reliable, stable, and broad. Intel's CI leverages the high quality of piglit, to the great benefit of the engineering team. I hope this system can provide a case study demonstrating the power of automated developer tests and continuous integration. Perhaps other teams will increase their focus on writing tests, or set up similar systems to leverage their existing test suites.

Slides, Youtube

Presenter: Mark Janes

State of the graphics stack in DragonFly

During the last few years, I have been trying to make DragonFly more successful in professional environments by benchmarking its performance, making it able to use some common technologies and porting various pieces of software.

In particular, I have been working since 2012 on porting drm/kms graphic drivers. I am also generally involved in various discussions about graphics in the DragonFly community.

I'd like to give a small talk about the state of the graphics stack, its various components, how some of the new kernel drivers have been first ported to DragonFly and the exciting changes which occurred during the last year.

Slides, Youtube

Presenter: Francois Tigeot

GSoC - Enabling Freedreno on Android (Cancelled)

The talk will cover the Android graphics stack and describe the issues faced while getting Freedreno to work with kitkat-x86 on an IFC6410, ranging from platform specific problems to the design decisions made.

Presenter: Varad Gautam

libratbag - a generic library to support configurable mice

We have been working on a generic library to provide an unified way to configure programmable mice. This API is vendor independent and provides a central point to describe the capabilities of a mouse. This way, we can support programmable mice in Gnome, KDE or any other desktop environment without having to introduce a vendor specific API for each mouse in the desktop environments.

During this talk, we will give an overview of the features and capabilities of libratbag. Hopefully, there will be a demo of its current state.

Slides, Youtube

Presenters: Peter Hutterer & Benjamin Tissoires

How to debug a broken input device?

Input devices have evolved quite a lot since the one keyboard and one single button mouse per computer. We now have several buttons on the mice, touchpads, touchpads that can report actual touch events, touchscreens, etc...

Usually, hardware makers tend to complicate our task of supporting their device in very creative ways. This generally leads to users complaining that their device is broken, or that the behavior is not the expected one.

In this talk, I will try to explain the various tools that the community has developped to be more efficient at spotting the problems. Tools like evemu, evtest, hid-replay or ps2emu will be presented and we will try to show real examples of their use.

Slides, Youtube, LWN recap

Presenter: Benjamin Tissoires

Gated-Trunk Hardware Development and DevOps

Hardware development is becoming more and more similar to software development every day. HDLs (Hardware Description Lanugauges) like System Verilog support things like classes, inheritance and method overrides. Just like in software, teams are becoming larger and more geographically diverse. The codebase has same challenges as software development and many of the same development methodologies can be applied.

In this talk, I will try to give a brief overview of how we use trunk gating and Devops to stay sane while developing ASICs at my company.

Slides, Youtube

Presenter: Matt Dew

Nouveau - Status update

The usual status update for the Nouveau project!

Slides, Youtube, LWN recap

Presenters: Alexandre Courbot & Martin Peres

Sustaining X development

Slides, Youtube

Presenter: Keith Packard

GLSL compiler: Where we've been and where we're going

Slides, Youtube

Presenter: Matt Turner

• Events/XDC2015/Program/hutterer_board_directors_satus
• Events/XDC2015/Program/hutterer_libinput
• Events/XDC2015/Program/hutterer_tissoires_libratbag
• Events/XDC2015/Program/tissoires_input_debug_tools