Dopo aver ripristinato le SDL di pandora, eccoti la lib che mancava....
libSDL2_gfx-1.0.so.0:
Poi, dopo aver fatto tutti i test (con la lib, usando le variabili in export, senza variabili e solo con una variabile), mi fai sapere se in uno dei tre modi (appunto senza variabili, con entrambe o con una) funziona...
Poi ho fatto pure una nuova versione di openbor ma che accede alla gpu mediante GL
openbor-gl:
Visto che ho tempo ti spiego un po' l'arcano (chiedimi pure lumi eventualmente, cerco di essere chiaro cmq)
Facciamo un po' di luce su questo strano chipset usato dalla pandora...
Sulla pandora spicca un bel Cortex A13 della allwinner, questo chipset è un sistema integrato che ha al suo interno CPU, GPU, DSP audio e persino un codec H265 nativo (quest'ultimo personalmente mai esplorato le possibilità).
CPU:
La CPU è un ARM compatibile con assembly cortex-a9-neon, questa informazione è davvero interessante... le estensioni neon permettono di creare programmi multimediali molto più veloci in quanto hanno molte primitive dedicate a calcoli matematici eseguite via hardware. Chiaro che per essere usate appieno serve codice assembler ottimizzato, molti progetti retroarch sono già compatibili (vedi l'emulatore PSX!), in ogni caso gcc/g++ permette di usare le direttive -marm -mcpu=cortex-a9 -mfpu=neon per migliorare anche codice C/C++ generico
Ultimo appunto sulla matematica float (che sappiamo essere molto usata negli su architetture ARM può essere implementata dal chipset via hardware o emulata da librerie software, parliamo di float-abi hard o float.... fortunatamente il nostro A13 ha al suo interno tutto il necessario per eseguire tutto via hardware, la direttiva al compilatore necessaria è quindi -mfloat-abi=hard
Oltre a queste di solito è migliorativo il classico -O3 (optimize livello 3) unita alla fast-math e omit-frame-pointer, ne consegue che per compilare su pandora la stringa CFLAGS consigliata è: -marm -mcpu=cortex-a9 -mfpu=neon -mfloat-abi=hard -fomit-frame-pointer -ffast-math -O3
La vita purtroppo non è così lineare, alcuni programmi o emulatori smettono di funzionare con queste stringhe e, con molto mal di testa, bisogna scoprire cosa togliere...
Di solito abbiamo avuta cura di mettere sul mio git un makefile per ogni programma compilato con le direttive usate.
GPU:
Qui la faccenda si fa ancora più complessa, dentro la allwinner c'è una mali mp400, una GPU 3D/2D non standard... per usarla a pieno regime serve un blob binario (libMali.so), una serie di link sulle EGL-2.0/EGL-3.0 che puntino al mali, e mettere negli header del compilatore tutta una serie di estensioni al set EGL standard!!! Ovviamente il nostro SDK è già pronto, ed è già pronta anche la /lib di pandora, prepararla però è stato un grosso mal di testa...
A complicare ancora di più c'è il fatto che non è compatibile ad opengl, ma EGL (un subset ridotto), e per giunta solo ad EGL-2.0 e, in parte al 3.0, niente 1.0!!!
Per accedere a queste funzioni i programmi hanno pià strade, usare EGL nativamente o farlo tramite SDL... se lo fanno nativamente chiramente compilando sul nostro SDK vengono presi gli header mali e tutto fila più o meno liscio, se invece accedono ad SDL... chiaro che serve una versione di SDL compilata con gli header e delle patch per accedere alla GPU! Le patch sono sul sito di retropie, ma anche qui altro mal di testa... pure queste non vanno bene, e abbiamo dovuto fare patch delle patch per far convivere SDL2 con SDL1 sulla mali!!!
https://github.com/RetroPie/SDL-mirror/tree/mali-2.0.8
https://github.com/RetroPie/SDL-mirror/tree/mali-2.0.7
https://github.com/RetroPie/SDL-mirror/tree/mali-2.0.6
dimenticavo, la DSP audio... è una ciofeca, ed è il vero limite della pandora! E' colpa sua se pandora ha rallentamenti... se disabilitiamo il DSP pandora diventa velocissima.
