CGo Ownership
Quand le GC Go peut ou ne peut pas déplacer la mémoire pendant un appel C. Runtime pinning automatique.
Systèmes Bas Niveau · GPU Computing · En cours
Photoshoplike
Go + C + OpenCL
Moteur de traitement d'images zéro-copy entre Go, C et GPU. Chaque pixel manipulé manuellement — aucune librairie image, gestion directe de la mémoire via CGo et OpenCL. Projet personnel en cours de développement.
Go
C / CGo
OpenCL 3.0
Zero-copy
En cours
Pipeline Architecture
-
Browser
Upload image
-
Go Server
net/http · decode RGBA
-
CGo Bridge
unsafe.Pointer zero-copy
-
C Engine
malloc · pixel ops
-
OpenCL GPU
parallel kernels
Pourquoi ce projet
Les librairies comme Pillow ou libvips abstraient tout. Ce projet m'oblige à comprendre ce qui se passe réellement quand on applique un filtre — gestion de la mémoire, ownership à travers deux langages, et parallélisme GPU.
Le défi technique
Faire communiquer Go et C sans copie mémoire, puis déléguer le calcul pixel au GPU via OpenCL. Chaque étape impose de comprendre ce qui possède quelle mémoire — un concept invisible dans les frameworks haut niveau.
Lien avec l'IA
Les frameworks IA (PyTorch, JAX) reposent sur exactement ce type de pipeline GPU. Comprendre le bas-niveau rend le haut-niveau plus lisible. Objectif v2 : y industrialiser une inférence OpenVINO pour corriger automatiquement la lumière — du service web jusqu'à la carte.
En conditions réelles
Mon Core Ultra 7 255H (Arrow Lake-H, 2025) était si récent que le runtime OpenCL par défaut ne reconnaissait pas son GPU. J'ai dû mettre à jour le compute runtime Intel (NEO) pour qu'OpenCL puisse cibler la carte — débogage d'une chaîne driver / runtime, au plus près du métal.
25 M
pixels traités en parallèle (photo 25 Mpx)
~100 Mo
transférés en zero-copy (4 o/pixel)
Concepts Explorés
Memory Model OpenCL
Host vs device buffers, transferts clEnqueueWriteBuffer, synchronisation des kernels.
Parallélisme GPU
Pourquoi les filtres d'image sont embarrassingly parallel — chaque pixel est indépendant.
C Memory Discipline
malloc/free lifecycle, éviter les leaks à travers la frontière CGo, gestion manuelle des pointeurs.
Injection de dépendance
Moteur GPU créé une seule fois au démarrage et réutilisé à chaque requête (GPU-resident), au lieu de le reconstruire à chaque appel.
Concurrence
Le serveur HTTP traite chaque requête dans sa goroutine ; un mutex sérialise l'accès au GPU partagé contre les data races.
Voir aussi
NNFS — Réseau Neuronal from Scratch (Python/NumPy)