xorg/ SummerOfCodeIdeas

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

NOTE: documentation-only tasks don't fall within the scope of GSoC, but if you're looking for documentation-related tasks, please see here.

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 "Writing a proposal", 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.

Potential Mentors

Some projects have one or more specific potential mentor(s) who are listed as part of the project idea itself. Otherwise a potential mentor might be found in the following list:

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.

Increase code coverage of the DRM code

  • Difficulty: Medium
  • Expected Size: 350 hr
  • Skils Required: C, Linux on the command-line
  • Useful skills: able to communicate on a public mailing list
  • Hardware/Software required: any Linux distribution

NOTE: the mentors for this project have a separate set of instructions regarding prerequisites and proposal guidelines which supersede all others. Please see this page for details.

Mentors: Maíra Canal, André Almeida, Tales Aparecida, Paulo Meirelles

Mesa

Vulkan GPU preference tool

  • Difficulty: Medium
  • Expected Size: 350 hr
  • Skills Required: Writing advanced GUI
  • Useful skills: C/C++
  • Hardware/Software required: A dual-GPU setup where both GPUs support Vulkan
  • Where to ask questions: mesa-dev@lists.freedesktop.org, #dri-devel on irc.oftc.net
  • Description: One of the problems facing users with multi-GPU setups on Linux is the fact that applications choose a GPU either through their own algorithm, by just selecting the first thing that comes up (which may not be stable across reboots), or provide an in-app GPU selection option in the game's menu. On Windows, most GPU vendors ship some sort of GPU selection tool to solve this problem by providing standardized lists of games which should run on the discrete GPU and letting the user provide custom rules for applications of their choice. Other applications such as web browsers and word processors default to the low-power integrated GPU. Linux has no such solution and it would be good to have something that is standard across all of Linux rather than individual vendors coming in and solving the problem with closed-source tools. At its core, it would likely be a file stored in $HOME/.config with a GUI tool to edit the file and add rules. Ideally, the GUI configuration tool would be available as a stand-alone and also seamlessly integrate with GNOME and KDE system settings. It would also be good if the GUI was the same as the DriConf tool mentioned above.

Possible mentors: Dave Airlie (airlied on IRC/OFTC) Jason Ekstrand (jekstrand on IRC/OFTC)

Freedreno (Open Source Adreno driver)

See also our Trello board.

Compiler: Spilling Registers

  • Difficulty: Difficult
  • Expected Size: 350 hr
  • Skills Required: C, Compilers
  • Hardware/Software required: Adreno 3xx, 4xx, or 5xx GPU
  • Where to ask questions: freedreno@lists.freedesktop.org, #freedreno on irc.oftc.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
  • Expected Size: 350 hr
  • Skills Required: C++
  • Useful skills: Compilers
  • Hardware/Software required: NVIDIA Fermi or later
  • Where to ask questions: nouveau@lists.freedesktop.org, #nouveau on irc.oftc.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
  • Expected Size: 350 hr
  • Skills Required: C
  • Useful skills: Reverse Engineering, Video formats
  • Hardware/Software required: NVIDIA Maxwell GM107, GM200, GM204 or GM208 chip (a GM108 desktop card might works as well, the mobile one won't)
  • Where to ask questions: nouveau@lists.freedesktop.org, #nouveau on irc.oftc.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
  • Expected Size: 350 hr
  • 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.oftc.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
  • Expected Size: 350 hr
  • 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, #nouveau on irc.oftc.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
  • Expected Size: 350 hr
  • 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, #nouveau on irc.oftc.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
  • Expected Size: 350 hr
  • Skills Required: C, C++, Python
  • Useful skills: Vulkan
  • Hardware/Software required: Any NVIDIA Kepler or newer
  • Where to ask questions: nouveau@lists.freedesktop.org, #nouveau on irc.oftc.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
  • Expected Size: 350 hr
  • Skills Required: C++
  • Useful skills: OpenCL, Compiler
  • Hardware/Software required: Any NVIDIA Tesla or newer
  • Where to ask questions: nouveau@lists.freedesktop.org, #nouveau on irc.oftc.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
  • Expected Size: 350 hr
  • Skills Required: C++
  • Useful skills: Compiler Optimizations
  • Hardware/Software required: Any NVIDIA Tesla or newer
  • Where to ask questions: nouveau@lists.freedesktop.org, #nouveau on irc.oftc.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
  • Expected Size: 350 hr
  • 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, #nouveau on irc.oftc.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)

Fixing eGPU hotplugging in Nouveau

  • Difficulty: Easy to Hard (depending on which scenario to fix)
  • Expected Size: 350 hr
  • Skills Required: C
  • Useful skills: linux kernel programming
  • Hardware/Software required: Any Nvidia GPU and an eGPU case
  • Where to ask questions: nouveau@lists.freedesktop.org, #nouveau on irc.oftc.net
  • Description: Using Nvidia GPUs through an eGPU case already works flawless. The only issue is, that unplugging the device causes the kernel to crash. The Nouveau driver needs to be taught to handle this situation. The easiest to fix is to unplug the GPU while no application is using it. The hardest scenario to fix is when X is doing reverse PRIME and an application is using the GPU for rendering.

Fix outstanding tearing issues

  • Difficulty: Medium-Hard
  • Expected Size: 350 hr
  • Skills Required: C
  • Useful skills: linux kernel programming, understanding of Xorg
  • Hardware/Software required: Any Nvidia GPU and two displays
  • Where to ask questions: nouveau@lists.freedesktop.org, #nouveau on irc.oftc.net
  • Description: In a couple of cases with the nvidia driver tearing still happens. One of such situations is when the user has two displays plugged in, but some also see it happen with PRIME. In order to fix specific cases of tearing, the cause needs to be figured out and fixed accordingly, be it in the kernel and/or the Nouveau DDX or Mesa driver.

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
  • Expected Size: 350 hr
  • 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.oftc.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

Improved Weston timeline debugging

  • Difficulty: Medium
  • Expected Size: 350 hr
  • 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
  • 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).

wlroots presentation scheduling

  • Difficulty: Hard
  • Expected Size: 350 hr
  • Skills Required: C
  • Useful skills: Wayland, KMS, OpenGL
  • Hardware/Software Required: Supports Wayland and KMS with open drivers
  • Where to ask questions: #wlroots on Libera Chat
  • Description: At the moment wlroots-based compositors render right after the GPU displays a new frame on screen (vblank). This isn't great from a latency point of view, because all client surface updates will be 1 frame worth of time late. There are multiple ways to improve this (Weston and Sway have a configurable fixed delay, Mutter has an adaptive delay). Research and implement a good mechanism to reduce latency without missing frames.

CI-tron / Bare-metal CI

The CI-tron project aims to make operating and sharing your local test machines with fellow developers directly or through forges a breeze! For less than $250, and half a day of setup, expose your test machines in GitLab in under an hour! The project is already in use to test AMD and NVIDIA GPUs in Mesa/DXVK and growing to support ARM single board computers.

Relevant links:

  • https://gfx-ci.pages.freedesktop.org/ci-tron/
  • https://mupuf.org/blog/categories/ci-setup-series/

Projects: To be defined