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, that's a huge step forward. Creating a project which guides this process with a maximal chance of success is the only tricky part.

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.

Add support for performances counters in the profiling view

Description: Apitrace is an open source program that allows tracing, replaying, inspecting and profiling OpenGL/Direct3D calls made by any application. The goal of this task is to improve the profiling capabilities on the OpenGL side by leveraging the AMD_performance_monitor and INTEL_performance_query extensions, when available. Some necessary items:

Design the graphical interface (visualisation + signals selection)

Create an interface suitable to abstract any metric-collection system (CPU or GPU)

Description: There are a number of optimizaiton passes in the old GLSL
IR that we would like to see ported to NIR. This includes loop
unrolling, function inlining, any algebraic optimizations not yet in NIR,
and pretty much anything else that GLSL IR has but NIR does not. A good
proposal should identify 1-3 passes that the student wishes to port.

Description: Add a converter from an LLVM-like IR (e.g. SPIR) to nouveau/codegen IR (hw-independent). Add additional features required to expose compute support (hw-dependent). Add a way to make clover feed SPIR into the drivers.

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.

Freedreno

Android support

Difficulty: Medium

Skills Required: C

Useful skills: Android

Hardware/Software required: device with adreno a3xx or later; dev board (like ifc6410 or ifc6540) would probably be easier to work with, and therefore is recommended.

Description: Some groundwork has been done to ensure mesa at least builds for android, although gralloc/hwcomp parts need some update for more recent android versions. The preference would be to get things working with the upstream drm/kms driver, as that would benefit the other mesa drivers as well. (The drawback being, we don't yet have support for DSI in the upstream driver, which rules out most phones/tablets... however we expect to have DSI support in the coming months.) The other option is a custom gralloc/hwcomp that uses the downstream msm android kernel drivers, which would more easily support existing phones/tablets where the kernel cannot easily be replaced.

Description: Adreno 4xx adds support for full dx11 pipeline, with additional shader stages. We need to r/e and document how to use the additional pipeline stages (compute/geom/tess/etc). Additionally fp64 support and image/buffer support.

NOTE blob gles 3.1 drivers do not seem to be widely available, and there is the additional restriction of EULA that is required in order to download newer drivers from qualcomm. There are some things that could possibly be figured out with blob opencl drivers (like fp64.. if current blob opencl drivers already support this)

Shader Compiler

Difficulty: Difficult

Skills Required: C, Compilers

Useful skills: OpenGL, Reverse Engineering

Hardware/Software required: device with adreno a3xx or later; dev board (like ifc6410 or ifc6540) would probably be easier to work with, and therefore is recommended.

Glamor Performance Tuning

Glamor is a helper library that uses OpenGL to accelerate X rendering. The goal of this task would be to improve the the performance of Glamor by profiling problematic areas and improving the. Some possible ideas:

Mesa's GLSL compiler contains a large number of optimization passes. Each pass may change the code of a shader, and this may result in opportunities for other passes to make more changes. As a result, we run all of our optimization passes in a loop until the shader code stabilizes. This is expensive, and, though we have never observed this in the wild, it is possible that a shader may never stabilize.

Find a static ordering, with possible repeats, of optimization passes that does not compromise the quality of the generated code. Measure the before and after speed of compiling a large set of real-world shaders.

This project is pretty straightforward: Pick an application and fix bugs or implement missing features in clover and/or the gallium drivers until it works. In order to come up with a good proposal for this project a student will need to first investigate their chosen application to determine what needs to be done to get it working. Some possible applications:

Fix colormaps with RandR 1.2 capable Xorg drivers

X11 colormaps (including pseudocolor support) have been broken with RandR 1.2 capable Xorg drivers for over 5 years, see bug #27222. The most prominent symptom caused by this is gamma settings having no effect in games using SDL, which uses colormaps for that. The solution would involve factoring the active colormap into the per-CRTC gamma lookup tables. Bonus points for factoring in the pre-RandR gamma factor(s) exposed e.g. via XFree86-VidModeExtension, xorg.conf and the Xorg command line as well.