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?", but including milestones and a project schedule is even better. See 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 or the dri-devel IRC channel.

2017 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.

Apitrace

Plug the core-apitrace support for performance counters to qapitrace

  • Difficulty: Medium
  • Skills Required: C++, Qt5
  • Helpful, but optional skills: CPU & GPU profiling
  • Where to ask questions: apitrace@lists.freedesktop.org, #apitrace on irc.freenode.net
  • Description: Apitrace is an open source program that allows tracing, replaying, inspecting and profiling OpenGL/Direct3D calls made by any application. During the previous GSoC, gl_retrace received support for listing and monitoring performance counters, and an experimental GUI was developed. The goal of this GSoC will be to finish the GUI and get it merged in Apitrace. With this work done, this will allow game and driver developers to find bottlenecks and inefficiencies in their code and then tune their code to get more performance. Some necessary items:
    1. Study the design proposed by last year's student, possibly propose some changes
    2. Polish the GUI and land it upstream before the end of the project

Possible mentor: Martin Peres (mupuf on IRC/freenode)

In-place shader editing in qapitrace

  • Difficulty: Medium
  • Skills Required: C++, Qt5
  • Helpful, but optional skills: general OpenGL familiarity
  • Where to ask questions: apitrace@lists.freedesktop.org, #apitrace on irc.freenode.net
  • Description: Apitrace is an open source program that allows tracing, replaying, inspecting and profiling OpenGL/Direct3D calls made by any application. The project idea is to enable editing any of the shader traces in a glDrawXYZ state view in qapitrace, so that the user could 'Lookup State' again and see the results from the trace replayed with the modified shader. Ie. qapitrace should edit the trace to insert the necessary GL calls to create the new shader and activate it for that particular draw. (Possibly w/ a checkbox to apply globally to all draws that use that particular gl program? In which case it would just edit the corresponding glShaderSource() call?)

Possible mentor: Rob Clark (robclark on IRC/freenode)

Mesa

Switch OpenMAX state tracker in Mesa/Gallium to use Tizonia

  • Difficulty: Easy-Medium
  • Skills Required: C
  • Useful skills: Mesa, OpenMAX, gstreamer programming
  • Hardware/Software required: driver supported by the OpenMax state tracker (radeon, nouveau)
  • Where to ask questions: mesa-dev@lists.freedesktop.org, #dri-devel on irc.freenode.net
  • Description: Currently the OpenMAX state tracker in Mesa/Gallium uses Bellagio. The project would be to use Tizonia instead. Bellagio has not been updated for a few years and only supports the OpenMAX IL 1.1 specification. Tizonia is actively maintained and also up to date with latest OpenMAX IL 1.2 specification. Also Tizonia supports OMX_UseEGLImage which would allow for zero-copy decoding/rendering. This work would benefit AMD and Nvidia hardware on Linux desktop. It would also help embedded developers by allowing them to develop feature on desktop first before to go to target. Testing can be done through gst-omx, the set of GStreamer plugins that wrap OpenMAX.
    1. Add support for Tizonia in Gallium/st-omx.
    2. Add zero copy support using OMX_UseEGLImage

Possible mentor: Julien Isorce

Implement remaining presentation features in the VDPAU state tracker

  • Difficulty: Easy-Medium
  • Skills Required: C
  • Useful skills: Mesa, image processing
  • Hardware/Software required: driver supported by the VDPAU state tracker (radeon, nouveau)
  • Where to ask questions: mesa-dev@lists.freedesktop.org, #dri-devel on irc.freenode.net
  • Description: The VDPAU state tracker in Mesa still lacks some nice to have features, like lanczos scaling, inverse telecine, luma keying and a temporal spatial deinterlacer. A possible task would be to implement some or all of those and get them into a state where we can add them to the main Mesa project.

Possible mentor: Christian König

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, #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)

Freedreno (Open Source Adreno driver)

See also our Trello board.

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, #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, #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, #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.

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, #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, #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, #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.

Kernel

DRM Kernel Janitor

You may find multiple ideas from the the DRM todo list page.

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, #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.

Potential Mentors

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

  • Rob Clark - Freedreno related projects, possibly general mesa or apitrace projects
  • Martin Peres - Apitrace, Power Management in Nouveau, xf86-video-modesetting or EzBench-related projects
  • Peter Hutterer - anything input-related