postaa! ;d
Visualizzazione stampabile
Speriamo davvero rispondano xD
Ragazzi, vogliamo farvi partecipi tutti alla causa, per questo ho deciso di postare qui la bozza (non definitiva) di cui Rockguy40 ha già la copia.
Naturalmente invito tutti per contribuire a migliorarla (secondo me esiste ampio margine nell'includere anche le spiegazioni più tecniche riguardo ad eventuali suggerimenti per portare il prossimo kernel e il prossimo update a livelli prestazionali maggiori ).
Non preoccupatevi assolutamente, nel caso ci voglia una missiva più cazzuta, cancello e riscrivo tutto da zero.
Ricordiamoci tutti che in base a ciò che invieremo, i pezzi grossi ci potrebbero prendere in seria considerazione.
Eccovi il messaggio:
Edit: aggiunte e modifiche varie.Quote:
Buon giorno Sig. (nome contatto/i)
Innanzitutto la ringrazio moltissimo per la sua enorme disponibilità, cordialità e pazienza con la quale ha risposto alla mia missiva.
La ringrazio anche per la gentilezza con la quale la sua persona ha risposto alla questione relativa all'aggiornamento del kernel.
Per ciò che é in accordo a quanto da lei richiesto, le faccio presente questo link:
Android Jellybean “Project Butter – How It Works And What It Added” | Lokesh Venkateshaiah's Blog
Ho cercato in modo molto chiaro é il più semplice possibile e per quanto sono le mie conoscenze in merito, di presentarle i vantaggi del triple buffering con l'aggiunta del vsync su un sistema Android dotato di kernel che, previa compatibilità tecnica della gpu, abiliti tale miglioria.
Come potrà notare, vi sono diversi esempi nel processare i framebuffers con e senza vsync, partendo dal classico sistema in cui un kernel Linux, gestisce il tutto a partire dalla gpu e dai driver grafici e finendo con l'aggiunta del 3 frame buffer e la parallelizzazione cpu con vsync attivo.
Come lei confermerà certamente, il possibile vantaggio sarebbe quello di non avere lag (o cmq una diminuzione degli stessi) negli imput di sistema in generale (processati via gpu/cpu).
Ad esempio, diminuzione del ritardo tra un operazione qualsiasi delle impostazioni del SO (entrare nel taskmanager, avviare un applicazione, un gioco) e rientrare velocemente alla home di sistema utilizzando i softtouch (tasto home, back e tasto impostazioni), senza che questi comporti un ritardo di 1, 2 o più secondi, tra il passaggio delle varie operazioni, oppure con la transazione tra le diverse schermate della home(nonostante ICS siamo molto ottimizzato su SoC K3V2, molto più di un GoogleNexus, noto microlag nel passaggio tra una schermata all'altra, quando queste sono occupate dai widget e dai link alle applicazioni e il wallpaper semovente).
Altro vantaggio potrebbe essere quello di una risposta più naturale e più fluida nell'esperienza utente, anche con frequenze gpu/ddr/cpu basse (powersave).
L'estensione del vsync al framework Android porterebbe così un processo in parallelo tra cpu, gpu e i refresh a 60 hz del display, il touch responsiveness e una più elastica o aggressiva gestione del governor in base al carico di lavoro(in accordo ad un Pmqos più permissivo nella gestione delle policy di sistema? ).
Inoltre altre possibili migliorie potrebbero essere l'aggiunta del Costumization Center e del project runner (altre caratteristiche sulla customizzazione dell' interfaccia e dei consumi, portate dalla versione 4.2.2 di Jelly Bean).
Un po come succede con la Emotion UI (EMUI), versione sperimentale del prossimo update? (anche se di base, ha ancora kernel ICS a quanto ho capito).
Inoltre le vorrei chiedere, sempre che la cosa non la disturbi, se il kernel in lavorazione da lei e il suo team, includerà i nuovi driver gpu (o una nuova revisione degli stessi) con i vari fix per portare maggiore compatibilità alla gestione shaders/assets dei motori grafici Unity, Unreal Engine 3 ed altri motori grafici proprietari della EAGames e della Gameloft, per esempio (l'aspetto intrattenimento/compatibilità/supporto, credo sia il più importante).
Nel link a seguire, come potrà notare, vi sono i sorgenti non completi del kernel 3.0.8 ICS dell'Ascend D Quad/U9510, in fase di studio e di un probabile porting sul nostro dispositivo U9508, ad opera di un generoso e volenteroso utente( é possibile che i 2 kernel siano identici per supporto SoC K3V2 ma abbiano alcune differenze hardware nella componentistica tra i 2 terminali? ).
https://github.com/mangusta86/Huawei_U9508_kernel
Le linko anche l'header del Pmqos:
https://github.com/mangusta86/Huawei...m_qos_params.h
header cpufreq:
https://github.com/mangusta86/Huawei...cpufreq-k3v2.h
header mcu: https://github.com/mangusta86/Huawei...3v2/mcu_para.h
sorgente cpufreq k3hotplug : https://github.com/mangusta86/Huawei...eq_k3hotplug.c
sorgente ipps policy: https://github.com/mangusta86/Huawei...h-k3v2/ipps2.c
Link ai sorgenti ufficiali: http://www.huaweidevice.com/worldwid...oftid=NDcwOTU=
A questi aggiungo parte del contenuto del file system@app@Pmqos.apk@classes.dex;
le impostazioni di sto azzo di forum non mi permettono di stilare altri caratteri!!
Quello che umilmente mi permetto di chiederle, é se fosse possibile per suo tramite, oppure per terzi, anche il rilascio ufficiale, dei sorgenti del kernel 3.0.8 per il nostro dispositivo Ascend G615/Honor2-U9508.
In questo modo, a mio modesto parere, si potrebbe avere un maggior risalto e rilievo del piccolo gioiello di tecnica e progettazione che va a nome di SoC K3V2, un più grande interesse di quello che potrebbe rappresentare il trampolino di lancio verso un più alto prestigio in campo mobile a livello mondiale e non meno importante, l'enorme contributo della community di programmatori e sviluppatori esterni, chiave universale del successo dei SoC K3Vx a venire.
Distinti Saluti
Ciao mangusta86, un caloroso benvenuto da tutti noi e un immenso grazie nel contribuire alla causa! :D
Come puoi notare, ho appena postato la bozza che invieremo successivamente agli sviluppatori, se hai già qualche idea e modifica, sono a tua disposizione (anche in pm se gradisci la cosa) :)
Premetto: se mi ci metto posso essere un rompino assurdo, quindi essendo questa una cosa molto importante...Lo sarò
"Ho cercato in modo molto chiaro é il più semplice possibile "
Ehm...non dovrebbe essere una normale "e"? :o
"Come lei mi insegnerà certamente, il possibile vantaggio sarebbe quello di avere lag zero (o cmq molto diminuiti) "
Questa frase non mi convince... "insegnerà"?? Ma se lo stai dicendo ora...Cosa vorresti dire esattamente?
Secondo me lag zero ci sta male nel contesto...inizi con un linguaggio formale, e poi ci piazzi questa cosa così...Ora non mi viene il termine, ma credo ce ne sia uno più consono al contesto
il passaggio delle varie operazioni alle successive),
Chiudi una parentesi così, a buffo...
se il kernel da lei e il suo team, in lavorazione, includerà i nuovi driver gpu
Volevi dire "in lavorazione da lei e il suo team"? Se è così basta mettere a posto le parole...Se no cosa hai voluto dire?
Comunque mi piace, fai capire quello che vuoi, sempre formalmente, forse leggermente troppo diretto, ma non saprei come fare altrimenti
Grazie per la lezione di grammatica, qualche cosa sfugge, scrivendo da tastierino virtuale, qualche accento, qualche punteggiatura, niente che cmq pregiudichi la traduzione in inglese...
Per quanto riguarda il "insegnerà", secondo te, questi. signori, sono o non sono GIÀ a conoscenza di come funziona un Android e i possibili tips e trick su kernel e drivers? :p
Cmq, quello che chiedo é, se chiunque di voi mangia programmazione come i biscottini nel latte, ci serve personale che conosca a menadito il funzionamento. di un Kernel Linux.
Vi prego di farvi avanti, se esistete, ci dareste veramente un Gran Contributo e una Gran mano, nel parlare ai Guru Hisilicon :)
ps: cmq é sempre una bozza, quindi credo cambierà ancora, l'intento é quello di mantenermi il più possibile morbido (non sono un programmatore) ma anche diretto (senza girare intorno agli argomenti).
In questo modo credo, che il tutto venga cmq apprezzato dall'altra parte.