path: root/Events/XDC2017/Program.mdwn

# XDC2017 Program

## Tuesday

[[!table header="no" data="""
19:00 | Pre-conference social event @ [Bierhaus](https://www.google.com/maps/place/Bierhaus/@37.3919626,-122.0793324,16.45z/data=!4m8!1m2!2m1!1sbierhaus!3m4!1s0x808fb73397be65f3:0xd65609045ee62dc6!8m2!3d37.3914239!4d-122.0801603)
"""]]

## Wednesday: Buffer Management, Testing

[[!table header="no" data="""
09:00 | Check In / Badge Pickup / Coffee / Opening Session
09:45 | [[Ben Widawsky (Intel) - Modifiers and implementing end to end compression on Intel|Program#ben_widawsky]]
10:30 | Break / Morning Snack
11:00 | [[James Jones (NVIDIA) - Unix Device Memory Allocation Update|Program#james_jones]]
12:00 | Lunch @ Google
13:00 | [[Laura Abbott (Red Hat) - Ion future and open discussion|Program#laura_abbott]]
14:00 | [[Alex Goins (NVIDIA) - DeepColor: On-screen HDR Drawables in X|Program#alex_goins]]
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|Program#martin_peres]]
16:30 | [[Mark Janes (Intel) - Frame Analysis with GPU Performance Counters|Program#mark_janes]]
17:30 | Demos
17:30 | Gwan-gyeong Mun - Mesa for Tizen Platform ([Video](https://www.youtube.com/watch?v=g5T5wSCXkH4&t=8h02m25s))
17:40 | Pierre-Loup A. Griffais - gpuvis, a Visual Debugging Tool for GPU Scheduling ([Video](https://www.youtube.com/watch?v=g5T5wSCXkH4&t=8h11m05s))
17:50 | Kevin Brace - OpenChrome demo ([Video](https://www.youtube.com/watch?v=g5T5wSCXkH4&t=8h26m57s))
18:00 | Google Hosted Happy Hour @ Google
"""]]

## Thursday: Driver Reports, Upstream Development 1/2

[[!table header="no" data="""
09:00 | Opening Session / Coffee
09:15 | [[Kaveh Nasri (Intel) - Mesa i965: Scenes from a Quiet Revolution|Program#kaveh_nasri]]
10:00 | Break / Morning Snack
10:30 | [[Eric Anholt (Broadcom) - Status of the Broadcom's vc4 driver|Program#eric_anholt]]
11:30 | [[Daniel Vetter (Intel) - dim tooling and commit rights|Program#daniel_vetter]]
12:00 | Lunch @ Google
13:00 | [[Zhenyu Wang (Intel) - Full GPU virtualization in mediated pass-through way|Program#zhenyu_wang]]
14:00 | [[Tom Stellard (Red Hat) - Current state of Open Source GPGPU|Program#tom_stellard]]
15:00 | Break / Afternoon Snack
15:30 | [[Kevin Brace (The OpenChrome Project maintainer / developer) - Reviving the Development of OpenChrome|Program#kevin_brace]] 
16:15 | [[Manasi Navare (Intel) - A Journey through Upstream Atomic KMS to achieve DP Compliance|Program#manasi_navare]]
17:00 | X.Org Board Meeting
18:00 | Collabora Hosted Happy Hour @ [Steins Beer Garden](http://steinsbeergarden.com/mountainview/)
"""]]

## Friday: Upstream Development 2/2, Misc.
[[!table header="no" data="""
09:00 | Opening Session / Coffee
09:15 | [[Martin Peres (Intel) - Reducing the cost of upstream development to encourage collaboration|Program#martin_peres2]]
10:00 | Break / Morning Snack
10:30 | [[Robert Foss (Collabora) - drm_hwcomposer: A brief status update|Program#robert_foss]]
11:30 | [[Daniel Vetter (Intel) - State of the X.org|Program#daniel_vetter]]
12:00 | Lunch @ Google
13:00 | [[Keith Packard (Valve) - DRM Leasing|Program#keith_packard]]
14:00 | [[Kyle Brenneman (NVIDIA) - GLVND|Program#kyle_brenneman]]
15:00 | Break / Afternoon Snack
15:30 | Lightning Talks / Demos
15:30 | Michal Lukaszek & Lukasz Spintzyk - Partial Updates in DRM Atomic ([[Slides|display_link_partial_atomic.pdf]], [Video](https://www.youtube.com/watch?v=R2XHZd4uXRI&t=6h2m50s))
15:35 | Francisco Jerez - Improving Graphics Performance through Energy Efficiency ([[Slides|jerez_energy.pdf]], [Video](https://www.youtube.com/watch?v=R2XHZd4uXRI&t=7h17m11s))
15:50 | Karol Herbst & Martin Peres - Nouveau updates ([[Slides|herbst_peres_nouveau.pdf]], [Video](https://www.youtube.com/watch?v=R2XHZd4uXRI&t=22117))
16:00 | Dongseong Hwang - DRM Atomic and Hardware Overlays in Chrome OS ([Video](https://www.youtube.com/watch?v=R2XHZd4uXRI&t=6h21m8s))
16:10 | Brian Paul - Piglit Discussion ([[Slides|paul_piglit.pdf]], [Video](https://www.youtube.com/watch?v=R2XHZd4uXRI&t=6h32m30s))
16:25 | Adam Jackson - xserver 1.20 planning ([Video](https://www.youtube.com/watch?v=R2XHZd4uXRI&t=6h47m9s))
16:35 | Pierre-Loup A. Griffais - Mesa Regression Testing for Steam Games ([[Slides|griffais_gfx-ci.pdf]], [Video](https://www.youtube.com/watch?v=R2XHZd4uXRI&t=6h57m50s))
16:45 | Chad Versace - DRM Format Modifiers and dma-bufs in Vulkan ([draft specs](http://kiwitree.net/~chadv/vulkan), [[Slides|chadv-vulkan-drm-format-modifiers.pdf]], [Video](https://www.youtube.com/watch?v=R2XHZd4uXRI&t=7h51m35s))
16:45 | Closing Session
"""]]



## Buffer management track

<a name="ben_widawsky"></a>
### Ben Widawsky (Intel) - Modifiers and implementing end to end compression on Intel

[[Slides|widawsky_fb_modifiers.pdf]], [Video](https://www.youtube.com/watch?v=g5T5wSCXkH4&t=0h17m17s)

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.

<a name="laura_abbott"></a>
### Laura Abbott (Red Hat) - Ion future and open discussion

[[Slides|abbot_ion.pdf]], [Video](https://www.youtube.com/watch?v=g5T5wSCXkH4&t=3h32m30s)

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

<a name="james_jones"></a>
### James Jones (NVIDIA) - Unix Device Memory Allocation Update

[[Slides|jones_allocator.pdf]], [Video](https://www.youtube.com/watch?v=g5T5wSCXkH4&t=1h34m48s)

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.

<a name="alex_goins"></a>
### Alex Goins (NVIDIA) - DeepColor: On-screen HDR Drawables in X

[[Slides|goins_hdr.pdf]], [Video](https://www.youtube.com/watch?v=g5T5wSCXkH4&t=4h37m27s)

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.

## Driver report status track

<a name="eric_anholt"></a>
### Eric Anholt (Broadcom) - Status of the Broadcom's vc4 driver

[[Slides|anholt_vc4_vc5.pdf]], [Video](https://www.youtube.com/watch?v=F3uRpOI0xi0&t=1h47m)

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.

<a name="zhenyu_wang"></a>
### Zhenyu Wang (Intel) - Full GPU virtualization in mediated pass-through way

[[Slides|wang_gvt.pdf]], [Video](https://www.youtube.com/watch?v=F3uRpOI0xi0&t=4h3m3s)

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.

<a name="tom_stellard"></a>
### Tom Stellard (Red Hat) - Current state of Open Source GPGPU

[[Slides|Stellard_GPGPU.pdf]], [Video](https://www.youtube.com/watch?v=F3uRpOI0xi0&t=5h3m58s)

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.

<a name="kevin_brace"></a>
### Kevin Brace (The OpenChrome Project maintainer / developer) - Reviving the Development of OpenChrome

[[Slides|brace_openchrome.pdf]], [Video](https://www.youtube.com/watch?v=F3uRpOI0xi0&t=6h33m16s)

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.

<a name="manasi_navare"></a>
### Manasi Navare (Intel) - A Journey through Upstream Atomic KMS to achieve DP Compliance

[[Slides|navare_dp_conformance.pdf]], [Video](https://www.youtube.com/watch?v=F3uRpOI0xi0&t=7h19m26s)

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.


## Testing track

<a name="mark_janes"></a>
### Mark Janes (Intel) - Frame Analysis with GPU Performance Counters

[[Slides|janes_frame_retrace.pdf]], [Video](https://www.youtube.com/watch?v=g5T5wSCXkH4&t=7h07m31s)

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:

 - live shader experimentation allows for quick shader debugging
 - render target display for arbitrary draw calls
 - performance experiments for identifying bottlenecks
 - cross platform implementation allows A/B comparison with Windows GL
   drivers
 - leverages ApiTrace for reliable retracing
 - Client/Server implementation for instrumenting remote/embedded
   systems
 - displays uniform constants

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.

<a name="martin_peres"></a>
### Martin Peres (Intel) - Intel GFX CI - What services we provide, our roadmaps, and how to replicate our efforts for other drivers

[[Slides|peres_ci.pdf]], [Video](https://www.youtube.com/watch?v=g5T5wSCXkH4&t=6h02m24s)

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.

## Upstream development track

<a name="daniel_vetter"></a>
###  Daniel Vetter (Intel) - dim tooling and commit rights

[[Slides|vetter_dim.pdf]], [Video](https://www.youtube.com/watch?v=F3uRpOI0xi0&t=2h31m15s)

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.

<a name="kaveh_nasri"></a>
### Kaveh Nasri (Intel) - Mesa i965: Scenes from a Quiet Revolution

[[Slides|nasri_mesa.pdf]], [Video](https://www.youtube.com/watch?v=F3uRpOI0xi0&t=13m42s)

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!

<a name="martin_peres2"></a>
### Martin Peres (Intel) - Reducing the cost of upstream development to encourage collaboration

[[Slides|peres_upstream.pdf]], [Video](https://www.youtube.com/watch?v=R2XHZd4uXRI&t=1030)

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.

## Misc track

<a name="keith_packard"></a>
### Keith Packard (Valve) - DRM Leasing

[[Slides|packard_drm_lease.pdf]], [Video](https://www.youtube.com/watch?v=R2XHZd4uXRI&t=4h4m33s)

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.

<a name="daniel_vetter2"></a>
### Daniel Vetter (Intel) - State of the X.org

Your secretary delivering the yearly report of the X.org Foundation.

<a name="robert_foss"></a>
### Robert Foss (Collabora) - drm_hwcomposer: A brief status update

[Video](https://www.youtube.com/watch?v=R2XHZd4uXRI&t=1h33m)

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:

 - Should drm_hwc be a part of Mesa?
 - What is required of drm_hwc to viable for more platforms?
 - What are the current maintainers, Google, planning for it?
 - Is anyone working on bringing up more hardware?


<a name="kyle_brenneman"></a>
### Kyle Brenneman (NVIDIA) - GLVND

[[Slides|brenneman_GLVND.pdf]], [Video](https://www.youtube.com/watch?v=R2XHZd4uXRI&t=5h5m51s)

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.