summaryrefslogtreecommitdiff
path: root/Events/XDC2014/Program.mdwn
diff options
context:
space:
mode:
authormperes <mperes@web>2014-09-07 12:36:52 -0700
committerxorg <iki-xorg@freedesktop.org>2014-09-07 12:36:52 -0700
commit1e189a7cf623c985df4db50aac4549cbd97f3a71 (patch)
tree57694472d311e3438421e27f3952238c413b113c /Events/XDC2014/Program.mdwn
parentb8452f10192d732bbb55d149c760b6872d21bd97 (diff)
Add a bunch of talks
Diffstat (limited to 'Events/XDC2014/Program.mdwn')
-rw-r--r--Events/XDC2014/Program.mdwn42
1 files changed, 42 insertions, 0 deletions
diff --git a/Events/XDC2014/Program.mdwn b/Events/XDC2014/Program.mdwn
index ea8211f2..01109746 100644
--- a/Events/XDC2014/Program.mdwn
+++ b/Events/XDC2014/Program.mdwn
@@ -43,3 +43,45 @@ While we'll be sharing our experience and efforts to-date, we also hope for
audience discussion contributing to further improvements.
Authors: Theo Hill & Jamey Sharp
+
+### Project REclock: Extending Nouveau with Voltage and Frequency Scaling for NVA3/5/8
+
+Over the years Nouveau has grown to become a serious open-source alternative for the closed-source binary drivers provided by NVIDIA, offering support for most graphics cards up to the current generation, nearing OpenGL 4.0 compatibility, supporting VDPAU accelerated video and even some form of Linux support for DirectX 9. Despite its broad API support, the most heard complaint about Nouveau is poor performance. In an attempt to bridge the performance gap between nouveau and NVIDIA's binary driver, I have worked on an EVoC project in an attempt to deliver clock and voltage adjustment for the GeForce Gx2x0 and Gx3x0, hopefully paving the way for future generations of GPUs.
+The process of adjusting clocks touches many areas of the GPU: subcomponents must be paused correctly, a vast amount of parameters for the memory subsystem need to be determined and correct synchronisation with the display subsystem is required to prevent buffer underruns during scanout. On some GPUs, this work has already resulted in a 50% increase in framerate for serious OpenGL workloads. In this presentation I attempt to give a high level insight in the full process of reclocking at the best of my understanding, give a status update on what does and does not work with the kernel patches I have prepared and I hope to conclude with some benchmark results while I push the boundaries of my braveness with a demo of reclocking on the GeForce G210m.
+
+Author: Roy Spliet
+
+### Graphics beyond the main compositor
+
+Most of the graphics development is targeted at the main session
+compositor. This is reasonable, as it is the interface that is used by
+far the greatest part of the time. However, there is a lot of
+interesting development going on beyond the main desktop environments,
+including boot-loader graphics, initrd UIs, emergency terminals and
+late-shutdown screens. While the graphical demands in those situations
+are rather low, we have to deal with a different, unique set of
+problems: accessing graphics via generic drivers, smooth transition to
+a full-featured driver, reducing memory footprint and loading-time to
+a minimum, claiming resources in emergency-situations and more.
+
+A lot of work has already been done to solve these problems, but
+challenges keep coming it. As only very few people actively work on
+those problems, this talk will walk through the different projects,
+describe the challenges and what future work is being planned.
+Eventually, our goal is to reduce moments off the main session to a
+minimum, make them as unobtrusive as possible and smoothly integrate
+into the different desktop environments.
+
+Author: David Herrmann
+
+### Adding tablet devices support to the Wayland protocol
+
+ * A brief explanation of the parts that needed to be worked on in order to get tablet support in Weston (libinput, the wayland protocol, and weston itself)
+ * The changes that were made to libinput, and the thinking behind the design choices that were made.
+ * The changes we've proposed for the wayland protocol in order to allow for tablet support, and the thinking behind the design choices that were made with the protocol.
+ * The changes that were made to weston along with the design choices that were made. This part's going to be a lot more brief then the last two since it's not in regards to an API or a protocol.
+ * A brief summary of the work that still needs to be done
+ * Questions, suggestions, etc.
+
+Author: Stephen Chandler Paul
+