Update my list of ideas

1 files changed, 21 insertions, 1 deletions

diff --git a/SummerOfCodeIdeas.mdwn b/SummerOfCodeIdeas.mdwn
index bad0aa64..407d6e3c 100644
--- a/SummerOfCodeIdeas.mdwn
+++ b/SummerOfCodeIdeas.mdwn
@@ -16,7 +16,7 @@ If you have questions, feel free to contact us on the [[dri-devel mailing list|h
 
 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:
 
-* [Martin Peres](mailto:martin.peres@free.fr) - Apitrace, Power Management in Nouveau, xf86-video-modesetting or EzBench-related projects
+* [Martin Roukala](mailto:martin.roukala@mupuf.org) - CI-related projects
 * [Daniel Stone](mailto:daniel@fooishbar.org) - Wayland/Weston, EGL, KMS
 * [Karol Herbst](mailto:kherbst@redhat.com) - Nouveau
 * [Julien Isorce](mailto:julien.isorce@gmail.com) - OpenMAX
@@ -335,3 +335,23 @@ You may find multiple ideas from the the [DRM todo list](https://dri.freedesktop
 * _Hardware/Software Required_: Supports Wayland and KMS with open drivers
 * _Where to ask questions_: #sway-devel 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.
+
+
+### Valve-infra / Bare-metal CI
+
+The valve-infra 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, exposing more than 20 machines and testing RADV on 5 generations of hardware in Mesa and DXVK.
+
+Relevant links:
+
+ * https://mupuf.pages.freedesktop.org/valve-infra/index.html
+ * https://mupuf.org/blog/categories/ci-setup-series/
+
+#### Port the Valve Infra to Raspberry Pis (and other Single Board Computers)
+
+* _Difficulty_: Medium
+* _Expected Size:_ 350 hr
+* _Skills Required_: Bare-metal skills (pre-Linux boot sequence), C, u-boot/barebox/tow-boot/Tianocore
+* _Useful skills:_ Podman/Buildah, Ansible, Python, Jinja2
+* _Hardware/Software Required_: An assortment of single-board computers which can run mainline kernels
+* _Where to ask questions_: #valve-ci-sync on OFTC Chat
+* _Description_: While the Valve infrastructure can execute jobs on X86_64 both ARM64 computers, it currently requires to be run on an x86_64 gateway. In an effort to further reduce the upfront/electricity costs of the CI system, it would be great if we could use ARM64-based Single-Board Computers as gateways. The work would require getting iPXE running on whatever boards you have (**definitely not trivial**), then modifying the [ipxe-boot-server](https://gitlab.freedesktop.org/mupuf/valve-infra/-/tree/master/ipxe-boot-server) to allow generating bootable images for these boards, generating an ARM64 version of the valve-infra-container (Arch-Linux-based), and finally, packaging and documenting everything up so that running on ARM64 is as simple and transparent as possible.