# Project Ideas for Google Summer of Code / X.Org Endless Vacation of Code programs


## Goal

The X.org board treats GSoC as an opportunity to teach new developers rather than a chance to get a pile of free code. With this perspective, if, in two months, the student actually has learned how to contribute to X Window System and its related projects, that's a huge step forward. Creating a project which guides this process with a maximal chance of success is the only tricky part.

When writing a proposal, please remember to make it detailed. Include at least the information called for in "[[What should a student proposal look like?|https://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page#5._What_should_a_student_proposal_look]]", but including milestones and a project schedule is even better.  See [[GSoCApplication|GSoCApplication]] for guidelines.

X.Org is a large and comprehensive project with a huge number of possible opportunities for interesting Google / X.Org Summer of Code projects.  This list contains a few of those opportunities that are particularly interesting to X.Org developers and potential mentors. Please note that these are just suggestions; if you have an idea for something else please ask.

If you have questions, feel free to contact us on the [[dri-devel mailing list|http://lists.freedesktop.org/mailman/listinfo/dri-devel]] or the [[dri-devel IRC channel|irc://irc.freenode.net/#dri-devel]].

## Ideas

Here are a list of projects proposed by X.Org developers. If you have ideas of your own, please post them on the relevant mailing lists.

### Mesa

#### DriConf replacement

* _Difficulty:_ Medium
* _Skills Required:_ Writing advanced GUI
* _Useful skills:_ C/C++
* _Hardware/Software required:_ Any GPU working with Mesa
* _Where to ask questions:_ [[mesa-dev@lists.freedesktop.org|mailto:mesa-dev@lists.freedesktop.org]], #dri-devel on irc.freenode.net
* _Description:_ Mesa users can set several driver options via an xml file in $HOME/.drirc or system /etc/drirc. With these files, the user can define behaviours for selected applications, like forcing vsync, picking a specific gpu in multi-gpu systems or enabling driver workarounds. DriConf is an user-friendly GUI to set these options, but it is outdated (old GTK, not multi-gpu compatible, and missing several features). Missing a good GUI to visualize and set driver settings is one of the recurring complaints from Mesa users. The goal of this GSoC would be to write an advanced configuration tool for Mesa drivers.

Possible mentor: Nicolai Hähnle (nha on IRC/freenode)

#### OpenMAX HEVC

* _Difficulty:_ Medium
* _Skills Required:_ C
* _Useful skills:_ Multimedia
* _Hardware/Software required:_ AMD Graphics Card supporting at least UVD6.0 or VCN (Fiji, Carrizo, Polaris, Vega, Raven) for HEVC decode, UVD6.3 or VCN for HEVC encode (Polaris, Vega, Raven)
* _Where to ask questions:_ mesa-dev@lists.freedesktop.org, #dri-devel on irc.freenode.net
* _Description:_ Recently Mesa's OMX gained support for Tizonia which one is an implementation of the OpenMAX IL 1.2.0 specification. It means that Mesa provides decoders and encoders in a form of components that can be used from an OpenMAX IL client (ex: gst-omx) by loading the Tizonia core library. The advantage of these components is that they are hardware accelerated by the GPU. The project goal is to add h265 support to Mesa's Tizonia components. Starting by the decoder for which some code can be taken from Mesa's omx Bellagio. The second task is to implement the h265 encoder, bridging the generic Mesa's PIPE VIDEO api to Tizonia. Depending on the progress the third task will be to add support for zero-copy in the h264 and h265 encoders taking reference from the Mesa Tizonia h264 decoder which supports OMX_UseEGLImage. Along the project, any code taken from Mesa's omx Bellagio will be refactored in Mesa omx common to be shared between Mesa Bellagio and Tizonia. For validation and testing the student will use gst-omx from the GStreamer project which already has wrappers for h265 decoder and encoder.

Possible mentor: Julien Isorce (capOM on IRC/freenode)

#### OpenMAX MJPEG decode

* _Difficulty:_ Medium
* _Skills Required:_ C
* _Useful skills:_ Multimedia
* _Hardware/Software required:_ AMD Graphics Card supporting UVD6.x from Carrizo, up to Polaris.
* _Where to ask questions:_ mesa-dev@lists.freedesktop.org, #dri-devel and #radeon on irc.freenode.net
* _Description:_ The MJPEG codec was implemented to MESA VA state tracker based on VA-API spec. Add that functionality for OMX/Bellagio&Tizonia. The implementation would need to parse MJPEG bitstream and extract all the information HW requires. The MJPEG spec could be referred for bitstream structure, and the VA-API implementation in MESA could be referred for HW interface requirements. 

#### Piglit for VA-API

* _Difficulty:_ Easy
* _Skills Required:_ C, Python
* _Useful skills:_ Multimedia
* _Hardware/Software required:_ AMD Graphics Card supporting UVD or VCN for decode and VCE or VCN for encode
* _Where to ask questions:_ mesa-dev@lists.freedesktop.org, #dri-devel and #radeon on irc.freenode.net
* _Description:_ Make mesa VA-API more robust with latest gstreamer-vaapi.  The goal is to provide an automated test framework for a variety of gst vaapi pipelines to catch regressions and find new bugs using something like piglit.  Use gst vaapi pipelines from popular apps such as vlc, mpv, mplayer, totem, and chromium as references.  Fixing some of the bugs found could be an additional stretch goal.

#### Piglit for OpenMAX

* _Difficulty:_ Easy
* _Skills Required:_ C, Python
* _Useful skills:_ Multimedia
* _Hardware/Software required:_ AMD Graphics Card supporting UVD or VCN for decode and VCE or VCN for encode
* _Where to ask questions:_ mesa-dev@lists.freedesktop.org, #dri-devel and #radeon on irc.freenode.net
* _Description:_ Make mesa OpenMAX more robust with latest gstreamer-omx.  The goal is to provide an automated test framework for a variety of gst omx pipelines to catch regressions and find new bugs using something like piglit.  Use gst omx pipelines from popular apps as references.  Fixing some of the bugs found could be an additional stretch goal.

#### Unit and performance tests for VA-API

* _Difficulty:_ Easy
* _Skills Required:_ C, Python
* _Useful skills:_ Multimedia
* _Hardware/Software required:_ AMD Graphics Card supporting UVD or VCN for decode and VCE or VCN for encode
* _Where to ask questions:_ mesa-dev@lists.freedesktop.org, #dri-devel and #radeon on irc.freenode.net
* _Description:_ Create a set of unit tests for VA-API to test all documented and undocumented details of the API and provide a set of performance tests for benchmarking.


### Freedreno (Open Source Adreno driver)

See also our [Trello board](https://trello.com/b/VC0IXzrq/freedreno).

#### Texture Tiling

* _Difficulty:_ Medium
* _Skills Required:_ C
* _Useful skills:_ 
* _Hardware/Software required:_ Adreno 3xx, 4xx, or 5xx GPU
* _Where to ask questions:_ [[freedreno@lists.freedesktop.org|mailto:freedreno@lists.freedesktop.org]], #freedreno on irc.freenode.net
* _Description:_ Add support for tiled textures. This will involve adding transfer handlers to perform the tiling, figuring out the various tiling options and when to use them, and to update all uses.

#### Compressed Textures

* _Difficulty:_ Medium
* _Skills Required:_ C
* _Useful skills:_ most of the work is in userspace (mesa), but some kernel experience wouldn't hurt, to also implement the display/scanout part
* _Hardware/Software required:_ Adreno 5xx GPU
* _Where to ask questions:_ [[freedreno@lists.freedesktop.org|mailto:freedreno@lists.freedesktop.org]], #freedreno on irc.freenode.net
* _Description:_ Starting with adreno 5xx, the hw supports rendering to and sampling (and scanning out) compressed textures to reduce memory bandwidth.  A bit more reverse engineering required about how this works for texture state, and how to do resolve blits.

#### Compiler: Spilling Registers
* _Difficulty:_ Difficult
* _Skills Required:_ C, Compilers
* _Hardware/Software required:_ Adreno 3xx, 4xx, or 5xx GPU
* _Where to ask questions:_ [[freedreno@lists.freedesktop.org|mailto:freedreno@lists.freedesktop.org]], #freedreno on irc.freenode.net
* _Description:_ Shaders with high register usage (see shadertoy) may fail register allocation stage, in which case load/store instructions need to be added to "spill" register values to memory.  This project would involve adding support to freedreno/ir3 compiler to determine which registers to spill, add necessary load/store instructions to save to local memory and restore from local memory (and then re-run scheduling and register allocation passes).

### Nouveau (Open Source NVIDIA driver)

A list of project is available on our [Trello board](https://trello.com/b/ZudRDiTL/nouveau).

#### Instruction Scheduler

* _Difficulty:_ Difficult
* _Skills Required:_ C++
* _Useful skills:_ Compilers
* _Hardware/Software required:_ NVIDIA Fermi or later
* _Where to ask questions:_ [[nouveau@lists.freedesktop.org|mailto:nouveau@lists.freedesktop.org]], #nouveau on irc.freenode.net
* _Description:_ Write an instruction scheduling pass for basic blocks in the nouveau codegen compiler. Create scheduling policies that improve performance.

#### Maxwell Accelerated Video Decoding

* _Difficulty:_ Medium
* _Skills Required:_ C
* _Useful skills:_ Reverse Engineering, Video formats
* _Hardware/Software required:_ NVIDIA Maxwell GM107 / GM108 chip
* _Where to ask questions:_ [[nouveau@lists.freedesktop.org|mailto:nouveau@lists.freedesktop.org]], #nouveau on irc.freenode.net
* _Description:_ RE the mechanism for video decoding in VP6 (the video engine iteration used in GM10x chips). Implement support for driving the engine.

#### Kepler Accelerated Video Encoding

* _Difficulty:_ Medium-Difficult
* _Skills Required:_ C
* _Useful skills:_ Reverse Engineering, Video formats
* _Hardware/Software required:_ NVIDIA Kepler GKxxx chip
* _Where to ask questions:_ [[nouveau@lists.freedesktop.org|mailto:nouveau@lists.freedesktop.org]], #nouveau on irc.freenode.net
* _Description:_ RE the video encoding component of Kepler chips and produce sufficient documentation for an open source implementation (while reusing blob firmware). A stretch goal would be to integrate something into nouveau to be able to drive the engine, and a toy user-space application to encode a video.

#### Dynamic Reclocking
 
* _Difficulty:_ Medium-Difficult
* _Skills Required:_ C
* _Useful skills:_ Modeling, control systems, and statistics
* _Hardware/Software required:_ A Kepler NVIDIA GPU with a super-reliable reclocking support and a power sensor
* _Where to ask questions:_ [[nouveau@lists.freedesktop.org|mailto:nouveau@lists.freedesktop.org]], #nouveau on irc.freenode.net
* _Description:_ Create a performance test rig that will test different use-cases we want to support for our dynamic reclocking.
This setup will need to be replicable and will serve as a benchmark for both power consumption and performance. The next step will be to experiment with different heuristics in the userspace that will poll the performance counters, and dynamically change the clocks to achieve the highest possible performance, at the lowest power consumption possible and with the simplest possible heuristic.

#### Enabling performance analysis on frameretracer

* _Difficulty:_ Medium
* _Skills Required:_ C, C++
* _Useful skills:_ Qt, OpenGL, Apitrace
* _Hardware/Software required:_ Any NVIDIA Tesla or newer
* _Where to ask questions:_ [[nouveau@lists.freedesktop.org|mailto:nouveau@lists.freedesktop.org]], #nouveau on irc.freenode.net
* _Description:_ Frameretracer is a wonderful tool to find and debug performance bottlenecks. However, it has been designed for Intel GPUs and requires changes in both Frameretracer and Nouveau in order to get the maximum out of the tool. The project would be to make the necessary changes in both Nouveau and Frameretracer to enable performance analysis on Nouveau.

#### Initial Nouveau Vulkan driver

* _Difficulty:_ Very Difficult
* _Skills Required:_ C, C++, Python
* _Useful skills:_ Vulkan
* _Hardware/Software required:_ Any NVIDIA Kepler or newer
* _Where to ask questions:_ [[nouveau@lists.freedesktop.org|mailto:nouveau@lists.freedesktop.org]], #nouveau on irc.freenode.net
* _Description:_ Write an initial vulkan driver, which should pass the most basic tests from the khronos CTS.

#### Helping out with Nouveau OpenCL driver

* _Difficulty:_ Very Difficult
* _Skills Required:_ C++
* _Useful skills:_ OpenCL, Compiler
* _Hardware/Software required:_ Any NVIDIA Tesla or newer
* _Where to ask questions:_ [[nouveau@lists.freedesktop.org|mailto:nouveau@lists.freedesktop.org]], #nouveau on irc.freenode.net
* _Description:_ Helping Pierre Moreau to get his current OpenCL Nouveau code to a usable state. This will include working a lot on the Nouveau compiler and improving the OpenCL Gallium state tracker Clover.

#### Adding new compiler optimization Passes to Codegen

* _Difficulty:_ Easy to Difficult
* _Skills Required:_ C++
* _Useful skills:_ Compiler Optimizations
* _Hardware/Software required:_ Any NVIDIA Tesla or newer
* _Where to ask questions:_ [[nouveau@lists.freedesktop.org|mailto:nouveau@lists.freedesktop.org]], #nouveau on irc.freenode.net
* _Description:_ Add new passes to Nouveaus codegen to improve the current generated code. This can mean adding a lot of trivial passes or a few complex one. A list of passes are in the "OpenGL Compiler Opts" list on the Nouveau Trello board: https://trello.com/b/ZudRDiTL/nouveau

#### Fixing outstanding reclocking issues on already reclockable GPUs

* _Difficulty:_ Medium-Difficult
* _Skills Required:_ C
* _Useful skills:_ Reverse Engineering
* _Hardware/Software required:_ Any NVIDIA Tesla, Kepler or Maxwell GPU
* _Where to ask questions:_ [[nouveau@lists.freedesktop.org|mailto:nouveau@lists.freedesktop.org]], #nouveau on irc.freenode.net
* _Description:_ We already support a handful of chipsets quite well. Fixing last outstanding issues on those would take us a step forward to actually having dynamic reclocking enabled by default (which we don't implement yet though)

### Kernel

#### DRM Kernel Janitor

You may find multiple ideas from the the [DRM todo list](https://dri.freedesktop.org/docs/drm/gpu/todo.html) page.

#### Improve the GPU scheduler to feed one entity into multiple run queues

* _Difficulty:_ Medium-Difficult
* _Skills Required:_ C
* _Useful skills:_ Kernel coding, scheduler basics
* _Hardware/Software required:_ Any AMD GPU
* _Where to ask questions:_ [[amd-gfx@lists.freedesktop.org|mailto:amd-gfx@lists.freedesktop.org]], #radeon on irc.freenode.net
* _Description:_ The GPU scheduler in drm is used by both amdgpu and etnaviv. It provides entities which allows userspace to push jobs into queues which are then execute by a hardware run queue. Now amdgpu have multiple identical hardware queues we currently map round robin to the software queues provided by the GPU scheduler when those are created. To better balance the load we could extend the scheduler to feed multiple hardware queues from just one software queue provided by the GPU scheduler.

Possible mentor: Christian König (ckoenig on IRC/freenode)

### libinput

#### Support for pressure-only bluetooth styli

* _Difficulty:_ Medium
* _Skills Required:_ C
* _Useful skills:_ Reverse Engineering, knowledge about Bluetooth/bluez
* _Hardware/Software  required:_ Touchscreen-capable laptop, bluetooth pen
* _Where to ask questions:_ [[wayland-devel@lists.freedesktop.org|mailto:wayland-devel@lists.freedesktop.org]], #wayland on irc.freenode.net
* _Description:_ Pressure-senstive style are commonly used with iPads and tablets. These styli usually only provide pressure, relying on the touchscreen for coordinates. To present such a stylus to an application, the touchscreen data and the stylus data have to be combined to a single event from the stylus device. libinput is perfectly suited to do exactly that. This project requires work in bluez to implement the stylus-specific protocol as a bluez plugin so the device shows up as kernel device (and, depending on the device, reverse engineering the protocol). This project requires work in libinput to extract and combine the data from both devices into a single virtual device.

### Wayland

#### LibWeston based console

* _Difficulty:_ Medium
* _Skills Required:_ C
* _Useful skills:_ LibWeston, Wayland.
* _Hardware/Software Required:_ Supports Wayland and KMS with open drivers
* _Where to ask questions:_
* _Description:_ Using libweston to write a "server" that only uses pixman-renderer and ensures there is always a terminal app running fullscreen at all times. When the console is inactive the terminals can be either terminated or made run in low resource mode so gfx resources can be freed.

#### Weston support for multiple KMS devices

* _Difficulty:_ Medium
* _Skills Required:_ C
* _Useful skills:_ KMS, Pixman/EGL
* _Hardware/Software Required:_ Supports Wayland and KMS with open drivers
* _Where to ask questions:_ 
* _Description:_ Weston supports multiple outputs, but currently limits them to a single GPU. Add support to Weston's DRM backend to open several KMS devices, with the ability to use outputs from all of them. To sidestep the problem of allocating buffers suitable for hardware acceleration across different GPUs, restrict this to the Pixman software renderer.

#### Improved Wayland timeline debugging

* _Difficulty:_ Medium
* _Skills Required:_ C
* _Useful skills:_ Performance profiling (including timeline and sample-based profilers), Wayland, toolkits, EGL / Vulkan WSI
* _Hardware/Software Required:_ Supports Wayland and KMS with open drivers
* _Where to ask questions:_ [[wayland-devel@lists.freedesktop.org|wayland-devel@lists.freedesktop.org]], #wayland-devel
* _Description:_ Weston currently has built-in support for timeline debugging, dumping JSON files with a visual representation of the timeline for showing client content on screen. This has a small client named Wesgr to render these to SVG. This project is somewhat open-ended, but there are many possibilities to improve it, including: implementing this protocol through more clients, a better renderer / timeline viewer with programmatic filtering (e.g. 'show me all frames which were late'), and integration with kprobes to instrument timings within the kernel stack (hardware/fence completion).

## Potential Mentors

Please add yourself below if you are willing to be a GSoC or EVoC mentor:

* [Rob Clark](mailto:robdclark@gmail.com) - Freedreno related projects, possibly general mesa or apitrace projects
* [Martin Peres](mailto:martin.peres@free.fr) - Apitrace, Power Management in Nouveau, xf86-video-modesetting or EzBench-related projects
* [Peter Hutterer](mailto:peter.hutterer@who-t.net) - anything input-related
* [Daniel Stone](mailto:daniel@fooishbar.org) - Wayland/Weston, EGL, KMS
* [Karol Herbst](mailto:karolherbst@redhat.com) - Nouveau
* [Julien Isorce](mailto:julien.isorce@gmail.com) - OpenMAX
* [Christian König](mailto:christian.koenig@gmail.com) - AMDGPU