cassiersg commented 7 years ago

Proposition de plan. @anpar qu'en penses-tu ?

Client

Intro (1'30'')

Démonstration (screencast) + explication des fonctionalités :

Animation vidéo
Interactivité temps-réel
3D
- Perspective
- Eclairage
- Changement de point de vue
Intégration des photos des joueurs
Affichage de texte (générique, n'importe quelle police)

Fonctionnement global (2'00'')

Interface résau (1) <-> state machine du jeu (1) <-> Rendu (1,2)
                                         |               |      
                                          <-------->  Interface HW (device (2,4) / desktop (1) )
                                                                |                      |
                                                              Entrées                Affichage
(1) Python
(2) C
(3) OpenGL
(4) SystemVerilog

State machine: très simple, reflète l'état reçu du serveur (pas de logique à ce niveau, tout est dans le serveur).
Rendu: même image pour le PC et pour le device.
Interface HW: abstraction des caractéristiques du HW -> debug simple, flexibilité (mode spectateur).

Pipeline de rendu (1'00'')

Description haut-niveau (1) -> Rendu 3D (2,3) -> Ajout des décorations (texte, jauge) (1,2)

(1) Python
(2) C
(3) OpenGL

Affichage (device)

Contraintes (1'30'')

25 FPS
800x480 pixels
Décodeur simple
Encodage temps-réel
Chaque frame doit être parfaite -> pas de glitches, images retardées...
5 Mbits/sec
< 500 kbits onchip memory (SDRAM -> nios/µCOSII)
flexibilité sur les caractéristiques de l'image transmise (pas de sprites, etc.)

Taille de l'image (12 bits par pixel, precision de notre système): 4.6 Mbits, at 25 FPS: 115 Mbits/sec

11 fois trop grand pour la onchip memory
23 fois plus de débit que ce qui est disponible

Chaque frame est parfaite -> double buffering => seulement 250 kbits disponible par frame

En résumé, on a besoin d'un système de compression qui

compresse d'un facteur > 20
puisse être décodé au vol, pixel par pixel (pas de ram pour stocker l'image décompressée)

Solution 1: codage des répétitions de pixels (1'00'')

Image représentée par

(c_0, c_0, c_0, c_0, c_0, c_1, c_1, c_1, c_0, c_2, c_2, c_0, c_0, c_0, ...) \in P^{800 \cdot 480}

transformée en (c_i, l_i):

((c_0, 5), (c_1, 3), (c_0, 1), (c_2, 2), (c_0, 3), ...)

Solution 2: codage de Huffman (2'00'')

Encodage naïf: P <-> {0, 1}^{24}. On peut faire mieux: codage de Huffman

c_i -> h_{c,i}

Pour les longeurs: on peut faire de même:

l_i -> h_{l,i}

Ce qui donne (en concaténant les codes):

(h_{c,0}, h_{l,5}, h_{c,1}, h_{l,3}, h_{c,0}, h_{l,1}, h_{c,2}, h_{l,2}, h_{c,0}, l_{c,3}, ...)

On a donc deux arbres de Huffman distincts.

Taille des arbres de Huffman: longueurs

Longueurs possibles: entre 1 et > 50 000 => arbres très profond, et codes très rares. Difficile à implementer (taille de code source, nombre de LE FPGA, très longs mots de codes), et difficile d'estimer les probabilités. On peut donc limiter les longueurs des blocs, quitte à avoir ..., (c_0, 100), (c_0, 8),.... Mais mauvais taux de compression pour des zones uniformes => On ajoute des grandes valeurs. Expérimentalement,

1, 2, 3, 4, 5, ..., 16
32, 64, 128, 256, ..., 4096

donne un bon compromis (mots de code de max 6 bits).

Taille des arbres de Huffman: quantization des couleurs

Même problème si on veut supporter toutes les couleurs de l'écran: $256^3 > 16e6$. On veut pouvoir représenter toutes les couleurs (photos...) => on réduit la profondeur de couleur à 4 bits, ce qui donne 12 bits / pixel => codewords plus courts, et taille de la logique raisonnable.

Résultats (0'30'')

sans photos: ~ 33 kbits / frame
avec photos > 120 kbits / frame
benchmarks ?

Implémentation (1'30'')

arbres de Huffman (2^12 codes): code généré à la compilation: rendu d'images + stats
code C optimisé pour la compression
decompression: 100% en SystemVerilog -> state machine -> peut produire 1 pixel/cycle, pour n'importe quelle entrée
deux RAM pour le double-buffering
changement entre les deux commandé par SPI, synchronisé au signal end-of-frame

Interface HW desktop (0'30'')

Python, pygame library
debug + specateur
même image que l'interface device
entrées simulées au clavier

Interface HW device

SPI protocol / state machine (1'00'')

communication SPI 5Mbauds/sec, en régime ~ 5Mbits/sec

augmenter le débit utile du SPI:

pas de release du chip select entre mots de 32 bits
burst mode: asymtpotiquement: 0% de bits de contrôle
implémenté via états: lecture, ecriture (longueur associée), paramétrage de l'addresse d'écriture/lecture

Entrées (1'00'')

µCOSII
HW minimaliste, tout géré en SW
State machine pour le touch
tache pour detect touch -> tache pour envoi touch
tache pour accelerometre (lecture + envoi)
mutex spi
protocol spi haut niveau: unidirectionel FPGA -> rpi, no ack, handshake... => robuste, risque rater un touch event si events bcp plus rapides que rpi.

Photos des joueurs (1'30'')

Serveur jeu (1) <--- système de fichiers ---> Serveur web (1) <----- HTTP -----> PC/Smartphone (2) <---> webcam

(1) Python
(2) Javascript

Questions non-résolues

Mettre des benchmarks ?

anpar commented 7 years ago

Pour l'ordre, je ferais quelque chose comme ça:

Fonctionnalités
Fonctionnement global. Points à discuter en particulier selon moi: génération du rendu 3D commun à l'ordinateur et au device, abstraction de l'interface hardware commune à l'ordinateur et au device: cela offre une capacité de debug accrue car on peut entièrement simuer le système sans passer par le device (et ajoute un mode spectateur).
Ensuite on focus sur la fonctionnalité la plus importante: le rendu. Zoom sur le lien Renderer <-> Hardware interface <-> Device en spécifiant les objectifs (3D, animation, photos, etc) et les contraintes (débit du SPI, taille de la mémoire, etc) et enfin les solutions pour atteindre ces objectifs avec ces contraintes (color quantization, double buffering, run-length coding, Huffman, etc)
Un petit zoom ensuite sur l'obtention des photos pour le jeu, assez bref mais pour expliquer rapidement comment ça fonctionne.

Ce qui est moins intéressant selon (car commun à tout le monde) : touch detection, lecture de l'accéléromètre, etc. Ça doit vraiment être très bref car c'est pas très intéressant...