Procesamento multimedia acelerado por hardware con ... · 2. DEFINICION DO PROXECTO Igalia S.L. tar m ais de dous procesadores, permitiendo o procesamento paralelo para a aceleraci

Procesamento multimedia aceleradopor hardware con GStreamer para

plataformas OMAP4

Xunta de Galicia

Procedemento Administrativo PR520A

Lına de actuacion A1: Fogar Dixital

A Coruna, 26 de outubro do 2011

INDICE Igalia S.L.

Indice

1. Licenza do documento 11.1. Licenza do documento . . . . . . . . . . . . . . . . . . . . . . 1

2. Definicion do proxecto 22.1. Descricion do proxecto . . . . . . . . . . . . . . . . . . . . . . 42.2. Obxectivos do proxecto . . . . . . . . . . . . . . . . . . . . . . 62.3. Tecnoloxıa utilizada . . . . . . . . . . . . . . . . . . . . . . . . 92.4. Licenzas de codigo . . . . . . . . . . . . . . . . . . . . . . . . 9

3. Realizacion do proxecto 113.1. Planificacion do proxecto . . . . . . . . . . . . . . . . . . . . . 113.2. Descricion do traballo realizado . . . . . . . . . . . . . . . . . 12

3.2.1. Analise . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2.2. Desenvolvimento . . . . . . . . . . . . . . . . . . . . . 18

4. Normalizacion na execucion e control 254.1. Metodoloxıa empregada . . . . . . . . . . . . . . . . . . . . . 254.2. Documentacion e resultados xerados . . . . . . . . . . . . . . 264.3. Execucion e control contınuo . . . . . . . . . . . . . . . . . . . 27

4.3.1. Actas de coordinacion mensuais . . . . . . . . . . . . . 274.4. Acceso publico a informacion sobre o control do proxecto a

traves de Internet . . . . . . . . . . . . . . . . . . . . . . . . . 344.5. Publicidade do cofinanciamento . . . . . . . . . . . . . . . . . 35

i

1. LICENZA DO DOCUMENTO Igalia S.L.

1 Licenza do documento

1.1. Licenza do documento

Este documento ten copyright de Igalia S.L. e licenza Creative Commons-Reconecemento-CompartirIgual 3.0 Espana.

http://creativecommons.org/licenses/bysa/3.0/es/

1

2. DEFINICION DO PROXECTO Igalia S.L.

2 Definicion do proxecto

Distintos metodos intentaron mellorar o desempeno xeneral dos disposi-tivos embebidos, tal como incrementar a velocidade de reloxo do procesador,estender o conxunto de instrucions, agregar aceleradores de hardware, e in-troducir da tecnoloxıa multi-nucleo. Con estas melloras, o rendemento do osdispositivos embebidos axustarıase as demandas de desempeno..

Os dispositivos embebidos funcionan de diferente que os ordenadores. Osordenadores son ferramentas de proposito xeral, e no fondo do tipo ”mellor-esforzo”. Isto e, que poden executar varias aplicacions, pero o desempenodas aplicacions non esta garantida. Por exemplo, cando un inicia o navega-dor Web mentres o reproductor de vıdeo esta executandose, poderıas expe-rimentar perda de fotogramas na proxeccion da pelıcula ou movementos depaxina estranos na pantalla do navegador. Pola contra, as aplicacions dosdispositivos para o fogar dixital son case sempre fixas, e esperamos que ca-da aplicacion desempenese de feito correcto dentro de calquera combinacionprovida pola especificacion. Mais aında, aında cando a aplicacion se tope cunbug severo, o sistema completo non deberıa colgarse.

O enfoque multi-nucleo poderıa permitirnos alcanzar o desempeno es-perado, asignando tarefas especıficas a cada procesador. Tamen, dado queprocesamiento paralelo xeralmente conduce a un baixo consumo de enerxıa,o enfoque multi-nucleo xustifıcase.

O tipo de procesamiento paralelo mais conecido e o multi-procesamientosimetrico (SMP), amplamente utilizado en ordenadores e servidores. Con to-do, o kernel e monolıtico, operando a mesma instancia en todos os nucleos,xa que logo, si un virus ou un bug colga a un nucleo, os outros CPUs, con-trolados pola mesma instancia de sistema operativo, poden tamen pasmarse,conxelando ası todo o sistema. Hai reportes que indican que os chips SMPconsumen mais enerxıa e os seus custos de producion adoitan ser mais alto,facendo que estes sexan inadecuados para os sistemas embebidos.

Para reducir a dependencia entre CPUs, podese executar unha instanciadiferente do sistema operativo en cada nucleo, onde cada un deles esta total-mente separado a nivel de hardware. Este modelo paralelo e chamado multi-

2


procesamiento asimetrico (AMP , polas suas siglas en ingles). No AMP , unproblema nun kernel nun nucleo non afectara ao seu vecino, e o sistemacontinuara operando aında cando alguns dos nucleos colguense.

Con todo, o modelo AMP leva consigo tres problemas que hai que resol-ver:

Compatibilidad do software. Os programas nun sistema AMP debenusar unha API especial de comunicacion diferente a aquela utilizadanos sistemas operativos tradicionais dun so CPU.

Xestion dos recursos de hardware. Debido a que cada sistema operativoen cada CPU corre independientemente, podense conceder erroneamen-te accesos simultaneos aos mesmos recursos de hardware, o que podecausar inconsistencias e obter resultados incorrectos.

Consumo da memoria do kernel. Podemos necesitar grandes areas dememoria para correr tantas instancias independentes de sistemas ope-rativos como o numero de nucleos.

Debido a que, neste esquema de multi-procesamiento, un sistema opera-tivo controla a un so nucleo, a sua contorna de software e compatible cossistemas operativos tradicionais, excepto na comunicacion entre os nucleos.E necesaria unha capa de software no sistema operativo que se encargue dacomunicacions entre procesadores (IPC , polas suas siglas en ingles).

Unha configuracion de hardware usual do AMP e un conxunto de nucleosque comparten un area de memoria comun. Polo tanto, cada kernel que con-trola un nucleo debera rexistrar dita area de memoria para ser usada paracomo medio de IPC . Hai que ter en conta que tamen se deben de contarcon mecanismos para controlar o acceso a estes obxectos en memoria, paraevitar, como xa se mencionou, a corrupcion destes.

Esta area de memoria compartida sera utilizada para dous tipos de co-municacion:

Paso de mensaxes, que son estrutura pequenas, que indican unha acti-vidade a realizar polo nucleo remoto.

Memoria compartida, que son areas de memoria onde un nucleo po-dera copiar segmentos grandes de informacion que logo seran consumi-dos e procesados por un nucleo remoto.

Desde o punto vista loxico, a configuracion habitual dun sistema AMPe ter un nucleo mestre ou anfitrion, quen e o encargado da interaccion cousuario e que, polo tanto, despacha solicitudes de tarefas aos nucleos remotosen funcion do requirido polo usuario.

3


Figura 2.1: Espazo de memoria global accesible por todos os nucleos. Unonucleo podese comunicar con outro escribindo no area de memoria globalonde o outro pode lelo.

2.1. Descricion do proxecto

Texas Instrument, na sua lina de procesadores OMAP, apostou polo usoda arquitectura AMP para paralelizar as operacions de codificacion e decodi-ficacion multimedia, con unidades coma DSPs ou coprocesadores, liberandoası o procesador principal (anfitrion) para executar outras tarefas, coma axestion da interaccion co usuario a traves de unha interfaz grafica, permitindounha experiencia de usuario mais suave e rica para aplicacions multimedia.

No que respecta o software, o problema comeza a nivel do kernel do sis-tema operativo, xa que este debe proporcionar un mecanismo para reservarareas de memoria que seran compartidas polos os distintos procesadores,bloquear esta area de memoria o resto dos procesadores mentras un delesesta operando sobre ela ou xestionar o paso de mensaxes entre os diferen-tes nodos implicados. Para isto, Texas Instrument estivo traballando nunmecanismo de procesamento asıncrono (AMP) y de comunicacion entre pro-cesadores (IPC ), que na sua ultima version leva o nome de SysLink1.

Do lado do procesador anfitrion, SysLink comprende un modulo do kernelde Linux, un servizo do sistema (demonio) e unha biblioteca que provee deuna interfaz de programacion, todo baixo licencias libres de software; mentrasque do lado dos coprocesadores, o sistema operativo e propietario e especıficode cada tipo de unidad de procesamento. Esta outra parte e a que conten osprogramas adicados a codificacion e decodificacion dos datos multimedia.

SysLink ofrece unha interfaz para IPC tanto no procesador anfitrion co-ma nos procesadores remotos ou escravos. E facilmente escalable para sopor-

1http://omappedia.org/wiki/Syslink Project

4


tar mais de dous procesadores, permitiendo o procesamento paralelo para aaceleracion multimedia. Cada procesador escravo e visto por o procesadoranfitrion coma un dispositivo mais no sistema, co unha entrada no directorio/dev.

Algunas das funcionalidades clave de SysLink son:

Mensaxerıa: Habilidade para intercambiar mensaxes de tamano fixo cosco-procesadores.

Manexo dinamico da memoria: Capaz de mapear dinamicamente fichei-ros no espacio de direccions do co-procesador.

Carga dinamica: Pode cargar dinamicamente novos componentes nosco-procesadores en tempo de execucion.

Xestion da enerxıa: Xestion de enerxıa estatica e dinamica para o DSP.

Memoria compartida con copia-cero: Pode “pasar” buffers de datosa outros procesadores simplemente proporcionando a sua posicion enmemoria compartida.

Asignacion de memoria baseada en losas: Asignar buffers en 2-D conopcions de copia-espello e rotacion, adecuadas para vıdeo.

Chamadas a funcions remotas: Un procesador puede invocar funcionsnoutro procesador remoto.

Subindo cara as capas superiores da pila, necesitamos unha bibliotecaque ofreza unha interfaz de programacion o desenvolvedor de aplicacions.Texas Instrument ofrece una implementacion da interfaz de programacionOpenMAX 2, que e parte de Khronos3, consorcio que agrupa diferentes in-terfaces de programacion estandar. Non obstante, esta interfaz en concretotodavıa non ganou moita aceptacion por parte da maiorıa de desenvolvedo-res de software, en especial os desenvolvedores que traballan sobre Linux, oscales estan mais acostumados a traballar con GStreamer, o estandar de factopara o procesamento de informacion multimedia en sistemas Linux.

GStreamer4 e unha biblioteca que permite a construccion de grafos parao manexo de informacion multimedia, sendo moi flexible nos backends dereproducion que se poden usar e en como utilizalos.

2http://www.khronos.org/openmax/3http://www.khronos.org4http://www.gstreamer.net/

5


O marco de desenvolvemento de GStreamer fai posible escribir cualqueiratipo de aplicacion multimedia, dende simples reproductores ata editores nonlineais de vıdeo e mesturadores de audio.

GStreamer esta desenado para facer sinxelo o desenvolvemento de aplica-cions multimedia. A sua principal ventaxa e que os componentes son “en-ganchables” e poden ser interconectados formando tuberıas (pipelines) arbi-trarias de procesamento multimedia. Estes componentes enganchables, cono-cidos coma elementos, proveen de distintos codificadores, decodificadores eoutras funcionalidades.

O obxectivo deste proxecto, a grandes rasgos, e desenvolver unha alterna-tiva a interfaz OpenMAX, ofrecida por Texas Instrument para a explotaciondos recursos hardware presentes na sua plataforma OMAP4. Esta alternativaproporcionara una interfaz directa entre SysLink y GStreamer.

Para entender a necesidade desta nova interfaz e importante revisar oacontecido no pasado recente: A tecnoloxıa antecesora a SysLink, chamadaDSPBridge5. Tal coma agora, Texas Instrument unicamente proveıa os susclientes de unha interfaz baseada en OpenMAX. Non obstante, de manei-ra independente, desenvolveuse unha interfaz para GStreamer conecida comagst-dsp6, a cal foi elixida por Nokia en lugar de OpenMAX por ter maiorestabilidade, simplicidade de deseno y mellor rendemento derivados de unhacomunicacion mais directa co hardware multimedia. O obxectivo deste pro-xecto e replicar o exito de gst-dsp en procesadores OMAP3 sobre DSPBridgeempregando SysLink para procesadores OMAP4.

O desenvolvemento deste proxecto non partio de cero: Rob Clark, unprogramador de Texas Instrument, desenvolveu, de maneira independente,unha proba de concepto de elementos de GStreamer que empregan SysLinkpara o procesamento multimedia. A este conxunto de elementos chamounosgst-ducati7. Igalia tomara o seu traballo coma punto de partida, coa intencionde ter un producto tan maduro como e gst-dsp para DSPBridge.

2.2. Obxectivos do proxecto

Escribir unha biblioteca lixeira para o acceso dende o espazo de usuariopara os servizos do modulo do kernel de SysLink.

Texas Instrument prove un conxunto de bibliotecas moi grandes e com-plexas para exponer ao espazo de usuario as facilidades de SysLink. Con

5http://omappedia.org/wiki/DSPBridge Project6https://code.google.com/p/gst-dsp/7https://github.com/robclark/gst-ducati

6


todo, consideramos que esta complexidade e innecesaria e vai en detri-mento do desempeno e do mantemento da biblioteca.

Por iso proponemos unha nova biblioteca, mais lixeira e simple, cunhaAPI mais clara e sinxela de usar, alinada coa filosofıa de Unix, asignan-do responsabilidades claras a cada elemento e traballando co obxectivode que todas as interfaces sexan obvias, sen o ocultamento de infor-macion presente noutras APIs, tal coma manter un estado interno convariables globais internas a biblioteca.

Esta nova biblioteca tera unha API diferente, simplificada e mais lexiblepara o seu mantemento posterior. Esta API segue o espırito de gst-dsp,onde se busca que as funcions sexan, na sua maiorıa, idempotentes eos seus efectos secundarios mınimos.

Ademais, esta biblioteca se manterıa coma unha API interna o pro-xecto e non coma unha bilbioteca compartida, evitando ası, mentrassexa posible, mantener un contrato de ABI/API con outros usuarios.Isto da moita liberdade para mellorar de maneira continua a bibliote-ca e adaptarnos dinamicanente os constantes cambios que suceden nokernel.

Portar o demonio para inicializar a contorna de SysLink utilizando anova biblioteca.

Co fin de utilizar os servizos de syslink hai que poner o subsistemade AMP nun estado inicial despois de arrincar o sistema operativo donucleo anfitrion.

Ese estado inicial implica comunicarse cos procedores remotos e cargar-lles os seus respectivos sistemas operativos para que poidan comezar aoperar.

Logo, rexıstranse as areas de memorias privadas dos distintos nucleosremotos para poder intercambiar buferes e mensaxes entre eles.

Para rematar, rexıstranse retrochaamadas a estados de erro. E dicir,cando un dos nucleos escravos entra nun estado de erro, manda unhamensaxe que sera recibida polo demonio e procedera a desmantelar amemoria privada dos nucleos e apagalos. Deste xeito podera reestable-cerse o subsistema sen ter que reiniciar o procesador anfitrion.

Debido a que este program debe permanecer escoitando e actuandoante mensaxes de erro dos procesadores escravos en todo momento,e necesario que se desevnolva coma un demonio do sistema, cun ciclode vida que se extende ao longo do uso do subsistema AMP .

7


Este programa servira coma guıa estructural para o desenvolvementoda biliblioteca do punto anterior, facilitando o deseno de unha APIcoherente co uso que se lle da.

Desenvolver unha aplicacion de proba para decodificacion de vıdeo.

Unha vez levantado o servizo de SysLink, os procesadores escravos estanlistos para atender solicitudes de decodificacion.

O seguinte paso consiste no desenvolvemento de unha aplicacion deproba, co obxectivo de decodificar un fluxo de vıdeo. Con isto compro-baremos que a biblioteca esta implementada correctamente e que a suaAPI e coherente coa tarefa a que esta destinada, que e o procesamentomultimedia.

Escribir os elementos de GStreamer que procesen os buferes de vıdeocon AMP usando as bibliotecas desenvolivdas.

Cos pasos anteriores terıase toda a infraestructura necesaria para im-plementar elementos de GStreamer que usen estes servizos de decodifi-cacion remota.

Deste xeito poderemos utilizar, transparentemente, a decodificacionacelerada de vıdeo en outras aplicaciones xa desenvolvidas que utili-zan GStreamer como fundamento para o procesamiento de multimedia.

Outra vantaxe da integracion con GStreamer e que facilita a adopcionda biblioteca por terceiros desenvolvedores, xa que GStreamer e a bi-blioteca standard de facto para o desenvolvemento de funcionalidadesmultimedia en sistemas Linux.

Ademais dos obxectivos puramente funcionais, existen outros obxectivosrelacionados coa difusion dos resultados do proxecto. En concreto:

Publicitacion dos avances e resultados do proxecto, a traves deponencias en eventos relevantes do sector, en particular:

• GStreamer Conference 8

Publicacion de noticias e artigos nos principais medios de di-fusion da tecnoloxıa e sistemas propios:

• Planet Maemo (blogs de desenvolvedores e usuarios de Maemo)9.

• Planet Igalia (blogs de desenvolvedores de Igalia)10.

8http://gstreamer.freedesktop.org/conference/9http://maemo.org/news/

10http://planet.igalia.com

8


2.3. Tecnoloxıa utilizada

As ferramentas empregadas son as comuns no desenvolvemento dun pro-xecto de Software Libre, todas elas con licenzas FLOSS. As principalmenteempregradas, dende o punto de vista do proxecto, foron as seguintes:

git: outra ferramenta libre de control de versions. En oposicion a an-terior tratase dun sistema distribuido onde non existe o concepto deservidor central. http://git-scm.com

GNU/Emacs: Entorno de desenvolvemento flexible e potente abondo co-mo para poder ser empregado nun entorno complexo de traballo.http://www.gnu.org/software/emacs

Autotools: conxunto de ferramentas para a xestion de compilacions deproxectos grandes e complexos.http://www.gnu.org/software/autoconf

http://www.gnu.org/software/automake

gcc / g++: compiladores libres das linguaxes C e C++ do proxectoGNU. http://gcc.gnu.org

gdb: depurador libre para codigo obxecto xerado coas linguaxes C eC++ do proxecto GNU. http://www.gnu.org/software/gdb sistemapara a xestion de incidencias. http://trac.edgewall.org

2.4. Licenzas de codigo

Todo o codigo de GStreamer atopase licenzado baixo licenzas FLOSS detipo LGPL. Por outro lado, todo o codigo desenvolvido por Igalia para isteproxecto tamen esta baixo a licenza LGPL.

A eleccion da licencia do software foi realizada dende o punto de vista deque se cumpriran as catro liberdades da definicion de Software Libre da FreeSoftware Foundation:

A liberdade para executar o programa, para calquera proposito.

A liberdade para estudar como funciona o programa, e adaptalo asnecesidades. O acceso o codigo fonte e unha precondicion para isto.

A liberdade a redistribuır copias para ası axudar ao vecino.

9


A liberdade a mellorar o programa, e publicar as melloras para que acomunidade poida aproveitalas. O acceso o codigo fonte e unha precon-dicion para isto.

Tamen se tivo en conta para a eleccion da licencia final do software aslicencias dos componentes software e bibliotecas que se empregaron duranteo desenvolvemento. De entre as licenzas propostas pola Free Software Foun-dation, elixiuse a licencia LGPL v3 (Lesser General Public License v3), quetendo en conta que se garantıa a compatibilidade de licencias, se amosabacomo unha mellor opcion para evitar que empresas de software privativo pui-desen sacar proveito dos desenvolvementos realizados no mesmo sen obrigalosa publicar.

A compatibilidade entre licenzas garantese trala explicacion dada polaFSF indicando que e posible combinar modulos separados ou arquivos decodigo liberados baixo calquera das licencias nun so proxecto.

10

3. REALIZACION DO PROXECTO Igalia S.L.

3 Realizacion do proxecto

3.1. Planificacion do proxecto

Este proxecto comezou a primeiros de Marzo de 2011 e rematara a finaisde Outubro de 2011, en total 8 meses de traballo. O calendario de execuciondo proxecto foi o seguinte:

1. Marzo - Abril: Analise, deseno e definicion de obxectivos.

Os obxectivos definidos foron os delindos na seccion 2.2, e xurdiron trasa analise do sistema de software SysLink e a plataforma de hardwareOMAP4330, e marcaron os pasos para acadar o obxectivo final destetraballo: o desenvolvimento dunha biblioteca de espazo de usuario quepermita a terceiros desenvolvedores a explotacion dos recursos hardwa-re multimedia proporcionados polo servizo SysLink do Kernel de formaoptima.

2. Maio - Setembro: Desenvolvimento do traballo en fases iterativasmensuais, implementacion e probas de cada unha das partes, con in-formes mensuais do traballo e progresos realizados.

En concreto, abordouse o desenvolvimento da biblioteca base, o demo-nio do sistema, a aplicacion de probas e o elemento de GStreamer.

Tamen, se incluiron aquı tarefas de difusion dos resultados por mediode blog posts e o envıo de propostas de ponencias a eventos relevantes,conseguindo a aceptacion no Congreso de GStreamer que tera lugar enPraga1.

3. Outubro: Probas de integracion finais de todos os elementos desenvol-vidos e prepacions para a ponencia e difusion dos resultados obtidos noCongreso de GStreamer.

1http://gstreamer.freedesktop.org/conference/gstreamer-conference-timetable.

html

11


Por outro lado, as planificacion en canto a tarefas a realizar para cada undos integrantes do equipo foron as seguintes:

Iago Toral: Encargado da coordinacion xeral, a definicion e revision doobxectivos, ası coma o analise previa e o seguimento da planificacion.

Vıctor Jaquez: Colaboracion no analise previa. Encargado do disenoe implementacion do software e tamben das probas e a difusion dosresultados.

3.2. Descricion do traballo realizado

Neste capıtulo descrıbese o traballo realizado ao longo deste proxecto.Comezamos coa analise da arquitectura de SysLink e implementacion no pro-cesador OMAP4330, que e o procesador instalado nos Panda Board, a placasobre a que se probaron os desenvolvimentos realizados durante o proxec-to. Ademais explicaranse outros servizos do kernel que axudan a SysLink acumprir co seu obxectivo de procesar datos de forma asıncrona.

Posteriormente explicarase o realizando en canto aos obxectivos funcionaisdescritos ao principio deste documento, na seccion 2.2, que son:

Escribir unha biblioteca lixeira para o acceso desde o espazo de usuariopara os servizos do modulo do kernel de SysLink.

Portar o demonio para inicializar a contorno de SysLink utilizando anova biblioteca.

Desenvolver un programa de proba para decodificacion de vıdeo.

Escribir os elementos de GStreamer que procesen os buferes de vıdeocon AMP usando as bibliotecas desenvolvidas.

3.2.1. Analise

Antes de comezar o desenvolvimento do software proposto nos obxectivos,foi necesario entender os conceptos usados por SysLink e o seu funcionamentointerno en terminos xerais.

Ademais, podese consultar os blog post publicados como resultado destalabor de analise: 2 3.

A continuacion se explican en detalle o contexto software/hardware doproxecto froito desta analise:

2http://blogs.igalia.com/vjaquez/2011/06/08/syslink-chronology/3http://blogs.igalia.com/vjaquez/2011/07/13/diving-into-syslink-v2/

12


Ma

rzo

Ab

ril

Ma

ioX

uñ

oX

ull

oA

go

sto

Se

te

mb

roO

utu

bro

11

Co

ord

ina

ció

n0.7

2 A

ná

lise

2.1

An

áli

se

do

SysLin

k0.8

0.25

2.2

An

áli

se

do

pro

ce

sa

do

r O

MA

P4

33

00.5

0.15

2.3

Pu

esta

do

esp

azo

de

tra

ba

llo

0.3

2.4

An

áli

se

do

ke

rne

l e

de

pe

nd

en

cia

s0.3

3 D

ese

nvo

lve

me

nto

do

de

mo

nio

pa

ra S

ysLin

k3

.1 P

rob

as d

o g

st-d

uca

ti

0.5

3.2

Im

ple

me

nta

ció

n d

o b

ibli

ote

ca

0.5

0.4

3.3

Im

ple

me

nta

ció

n d

o d

em

on

io0.5

3.4

Do

cu

me

nta

ció

n0.1

4 D

ese

nvo

lve

me

nto

do

acce

so

a D

CE

4.1

An

áli

se

do

DC

E0.4

4.2

Im

ple

me

nta

ció

n d

a p

rob

a0.5

0.9

0.3

0.1

4.3

Pro

ba

s4

.4 D

ocu

me

nta

ció

n0.1

0.25

5 D

ese

nvo

lve

me

nto

do

ele

me

nto

de

Gstre

am

er

10.35

5.1

An

áli

se

e d

ise

ño

5.2

im

ple

me

nta

cio

n

22

22

22

22

Figura 3.1: Cronograma de actividades.

13


Arquitectura de SysLink

Figura 3.2: Vista de componentes de SysLink.

Na figura 3.2 mostranse os componentes atopados en SysLink. Os dousprocesadores mostrados tenen diferentes componentes porque un xoga o pa-pel de anfitrion e o outro o de escravo. O anfitrion xa que logo necesita car-gar o sistema operativo no procesador escravo (loader), inicialo e executalo(ProcMgr), manexar o mapeo de memoria virtual (IOMMU), etc.

O componente principal de SysLink e o modulo de Mensaxerıa de Coman-dos Remotos (RCM polas suas siglas en ingles), o cal manexa as chamadasa funcions remotas. Usando o RCM, un nucleo anfitrion pode tomar vantaxedas funcions de procesamento no nucleo remoto. O anfitrion pode solicitara decodificacion dun bufer de audio ou de vıdeo a un procesador escravo,mentres que o procesador anfitrion pode ocuparse doutras tarefas do siste-ma. Deste xeito o sistema pode soportar a decodificacion de audio e vıdeo dealta definicion sen impactar no desempeno do anfitrion.

O diagrama 3.3 ilustra o proceso mediante o cal unha aplicacion no pro-cesador anfitrion executa unha funcion remota nun procesador escravo. Ex-plicado de xeito simplificado:

1. A aplicacion chama ao RCM cliente no procesador anfitrion para soli-citar a execucion dunha funcion remota.

2. O RCM cliente pasa a mensaxe de solicitude de funcion ao RCM ser-vidor remoto a traves da cola de mensaxes (MessageQ) local.

3. O MessageQ local pon a mensaxe na lista de mensaxes recibidas doMessageQ) remoto.

4. O MessageQ local solicita ao modulo de notificacion (Notify) enviarunha notificacion ao procesador remoto que unha mensaxe chegou.

14


Figura 3.3: Diagrama de actividades en SysLink.

5. O modulo de notificacion avisa o modulo de notificacion remoto.

6. O modulo de notificacion remoto di ao MessageQ remoto que revise asua lista de mensaxes recibidas.

7. O MessageQ remoto dalle ao RCM remoto a mensaxe recebida desolicitude de funcion remota.

8. O RCM servidor remoto executa a funcion remota.

Procesador OMAP4430

O procesador OMAP4430 esta orientado as aplicacions multimedia dealto desempeno. Esta composto polos seguintes subsistemas, entre outros:

Un microprocesador con dous nucleos tipo ARM R©Cortex-A9

Un subsistema cun procesador dixital de sinais (DSP)

Unha microprocesador con dous nucleos tipo ARM R©Cortex-M3

15


Un subsistema de aceleracion grafica 2D/3D (SGX )

Ambos procesadores tipo Cortex-A9 son usados como unha unidade deprocesamento anfitrion dentro da arquitectura AMP proposta. Mentres queos procesadores tipo Cortex-M3 e o DSP serıan os procesadores escravos.

Para os fins deste traballo so se empregaron os procesadores Cortex-M3,deixando o uso do DSP como traballo futuro.

O nome en codigo do subsistema formado polos procesadores Cortex-M3e o de Ducati. Ambos procesadores conecense como SysM3 e AppM3 respecti-vamente e a sua finalidade dentro do ambito deste traballo e o procesamentomultimedia. A figura3.4 mostra un diagrama de bloques simplificado destesubsistema, con frechas sinalando o sentido do fluxo seguido polo software.

Figura 3.4: Subsistema Ducati.

O procesador SysM3 xestiona as notificacions que venen do procesadoranfitrion para logo despacha-las no procesador AppM3. Xa que logo, o sis-tema multimedia enteiro executase neste ultimo. Cando o programa que seexecuta no procesador anfitrion invoca unha operacion remota de codifica-cion ou decodificacion de vıdeo ou de imaxe, esta executase no procesadorAppM3 dentro do subsistema IVA-HD ou do ISS. De xeito inverso, o nucleoAppM3 unicamente pode responder directamente ao procesador anfitrion.

IVA-HD significa Acelerador de Imaxe-Vıdeo de Alta-Definicion, polassuas siglas en ingles. Mentres que ISS significa Sub-Sistema de tratamen-to de Imaxes, polas suas siglas en ingles, e a sua funcion e a do procesamentode imaxes obtidas por medio dun sensor de imaxes externo ou da memoria.Este traballo so ten en conta o IVA-HD.

16


Distributed Codec Engine

DCE e unha biblioteca, escrita por Rob Clark, por encima do RCM, parainvocar remotamente os codificadores e decodificadores multimedia acelera-dos por hardware. Esta biblioteca prove dunha interfaz ao motor de codifi-cadores e decodificadores (DCE polas suas siglas en ingles) que se executano procesador escravo que procesa imaxe e vıdeo de alta definicion (un dosARMs M3 en OMAP4 conecido como Ducati).

Figura 3.5: DCE dentro de SysLink.

Desde o punto de vista do procesador remoto, o proposito do DCE e si-milar ao do Codec Engine en OMAP2 e OMAP3, so adaptado para OMAP4:un xeito simple para aceder aos distintos codificadores e decodificadores dis-ponibles en Ducati.

Texas Instruments, de xeito oficial e propietario, ofrece DOMX que e unhainterfaz mais complexa que DCE e adaptase a sua mais recente implemen-tacion de OpenMAX.

17


DMM e TILER

O modulo para a xestion de memoria dinamica (DMM polas suas siglasen ingles) e un componente de hardware de Texas Instruments. O DMMpermite ao procesador anfitrion, quen non ten acceso directo a rexion dememoria privada dos procesadores escravos, aceder aos datos almacenadosen devandita rexion restrinxida.

Dentro da DMM existe polo menos un componente de hardware de tipoTILER. O seu proposito e organizar a memoria de vıdeo ou imaxe de xeitobidimensional para limitar o ancho de banda do bus de memoria e reducir ocusto computacional das operacions de rotacion e espello. O modulo de TI-LER facilita a asignacion,e liberacion de bloques en 2D (areas) no contenedordo TILER. Tamen facilita a rotacion e a duplicacion dos bloques asignadosou de sub-seccions rectangulares.

Con todo, prevese que este modulo sera substituıdo por unha implemen-tacion de DRM (Xestor de Reproducion Directa, polas suas siglas en ingles),cuxa unica API aglutina a varios dispositivos.

De igual xeito o modulo de DMM podera ser substituıdo por algunhaoutra API que ofreza una mesma abstraccion para diferentes fabricantes dehardware.

3.2.2. Desenvolvimento

Nesta seccion se descreben as actividades realizadas para cumprir cosobxectivos funcionais, que foron o desenvolvimento da biblioteca, o demonio,o programa de probas da biblioteca e o elemento de GStreamer.

Biblioteca e Demonio para inicializar a contorno de SysLink

A biblioteca e o demonio foron desenvolvidos de xeito paralelo: o desenvol-vimento do demonio ıa demandando o deseno e implementacion da biblioteca.Neste proceso iterativo de desenvolvimento foi necesario investir un gran es-forzo na depurarcion do deseno para que fose o mais simple e directo posible,sen abstraccions innecesarias.

Dacordo a arquitectura AMP cun procesador anfitrion, este, unha vez quese iniciou satisfactoriamente, e o responsable de inicializar aos procesadoreshospedes. Tamen e responsable de restablecelos no caso de que entren nunestado inconsistente.

Polo tanto, este demonio ten as seguintes responsabilidades:

1. Abrir unha canle de comunicacion cos procesadores hospedes.

18


2. Poner no seu estado inicial ao subsistema de DMM. O demonio asignae delimita as rexions privadas dos procesadores escravos para que logopoidan ser usadas para o intercambio de informacion.

3. Unha vez inicializados os procesadores escravos e mapeadas as suaszonas de memoria dinamicas, carganse os sistemas operativos que con-trolaran a devanditos procesadores remotos.

Os sistemas operativos estan almacenados como ficheiros con formatoELF dentro do sistema de ficheiros do procesador anfitrion. O demonioenton extrae os segmentos a cargar do ficheiro e colocaos nas rexions dememoria convidas para que os procesadores escravos inicien operacions.

Unha vez que o sistema operativo especıfico do nucleo remoto e alma-cenado, emıtese a mensaxe para que este inicie operacions.

4. Cando os nucleos remotos estan iniciados cos seus sistemas operativose as rexions de memoria privada mapeadas para o seu uso compartido,xa se poden configurar o espazo de memoria que sera empregado parao intercambio de mensaxes entre o nucleo anfitrion e os remotos.

Primeiro asıgnase un area de memoria dentro da rexion compartida erexıstrase dita area ao mecanismo de cola de mensaxes, ası, cando sesolicite unha area nova para transmitir unha mensaxe en forma dunhaestrutura de datos, a cola de mensaxes tomara a memoria desta arearexistrada.

5. Finalmente, e esta e a razon pola cal este programa e un demonioou servizo do sistema e non un programa normal co seu ciclo de vidatemporal: rexıstranse os eventos de erro que poidan ocorrer nos nucleosremotos, e ponse en estado de espera de calqueira deses eventos. Nocaso de que ocorrese un erro, o demonio libera os recursos de memoriaasignados e deten os procesadores escravos, deixando ao sistema deAMP e IPC nun estado seguro, permitindo o seu reinicio executandoo demonio de novo.

E importante comentar que o entorno de desenvolvimento e depuracionfoi bastante hostil, derivado do baixo nivel o que se esta a desenvolver, moicercano o hardware e o kernel, o que fai que as tecnicas habituais de de-puracion de software non sexan sempre validas, requerindo actuacions maisrudimentarias e laboriosas.

Coma exemplo desta situacion, atopamos que unha vez cargada a imaxedo sistema operativo no procesador escravo e necesario enviar unha mensaxepara que o nucleo remoto arranque e mude a un estado no que poida comezar

19


a recibir e procesar mensaxes, pero por algun motivo, cando enviabamos estamensaxe o sistema quedaba nun estado inconsistente.

Ante a falta de documentacion e de ferramentas de depuracion validas, aunica solucion que tinamos para atopar o problema foi o traceo da actividadecontra o kernel do demonio orixinal proporcionado por Texas Instruments, ea posterior comparacion manual, paso a paso, co noso demonio de remplazo,ası coma a lectura do codigo do kernel implicado neste proceso, co obxectivode intentar comprender a orixe do problema.

Finalmente, a solucion o problema pasou por facer unha inicializaciondo subsistema MMU, proporcionando unha area de memoria compartida eos mapeos de memoria correspondentes para poder operar cos procesadoresescravos, pero a labor e traballo adicados a atopar a orixe do erro foronconsiderables.

Unha vez desenvolvido o demonio, fixeronse probas de rendimento dainicializacion do mesmo, comparando o noso remplazo (implementado coaAPI mınima que estivemos a desenvolver) co demonio orixinal proporcionadopor Texas Instruments. Os resultados foron moi esperanzadores, xa o que onoso demonio de remplazo finaliza a sua inicializacion nun tempo moitısimomenor, coma se pode observar a continuacion:

Demonio Orxinal (Texas Instruments)

real 0m3.232s

user 0m0.063s

sys 0m0.602s

Demonio de Remplazo

real 0m1.224s

user 0m0.039s

sys 0m0.570s

Aplicacion de proba para DCE

O programa de proba ten coma obxectivo verificar a validez da bibliotecadesenvolvida e da API desenada para o desenvolvimento de aplicacions deprocesamento multimedia.

Este programa de proba limıtase a abrir un arquivo cun vıdeo de formatoH.264 cru, un croma YUV 420, de 30 cadros por segundo e cun bit-ratemaximo de 10 Mbits por segundo.

O programa espera recibir como parametros de entrada o ancho e altodos cadros.

A grandes linas o programa fai as seguintes tarefas:

20


1. Inicia a comunicacion co DCE en nucleo remoto vıa RCM e extrae asfuncions remotas disponibles.

2. Envıa unha mensaxe de solicitude para abrir unha conexion co decodi-ficador de vıdeo remoto.

3. Solicita ao modulo do TILER buferes que se usaran para configurar econtrolar a operacion do decodificador.

4. Finalmente entrase no ciclo de ler buferes do medio de entrada, copialosa unha area de memoria ofrecida polo modulo de TILER, solicitar a seudecodificacion remota e recibir un novo bufer cos datos decodificados.

Para poder lograr este obxectivo tıvose que analizar o proxecto DCE quee alternativa a solucion propietaria proporcionada tamen por Texas Instru-ments (DOMX ), descrita na seccion 3.2.1.

A necesidade de introducir novos elementos, como o *DCE e o TILER,para o desenvolvimento desta aplicacion de proba, derivaron nunha serie deretos tecnicos adicionais que axudaron a completar o desenvolvimento dabiblioteca. A continuacion se mencionan os mais relevantes:

Tras profundizar na implementacion de DCE fixemos unha proba na queo enlazamos co noso demonio de remplazo, co obxectivo de avaliar o funcio-namento conxunto de ambos componentes. Neste punto descobrimos a nece-sidade de implementar API s adicionais na nosa biblioteca relativas a xestionde areas de memoria compartida que eran requeridas para poder realizar estaproba conxunta.

Con todo, unha vez implementadas as APIs requeridas, as probas realiza-das mostraban problemas: o kernel bloqueabase intentando pechar un dispo-sitivo sen dar ningunha informacion relativa a orixe do problema, polo que,coma en casos anteriores, foi necesario meterse no codigo do kernel e intentardepurar a orixe do problema de forma bastante manual, derivado da faltade ferramentas mellores de apoio o proceso de depuracion. Tras unha difıcillabor de depuracion se chegou a conlusion de que non se estaban a xestio-nar correctamente as direccions da pila na cola de mensaxes, e procedeuse acorrixir o problema satisfactoriamente.

Corrixido o problema, acadamos unha primeira version completamentefuncional e probada do noso remplazo do demonio de SysLink.

Continuando co desenvolvimento do programa de probas de DCE baseadona nosa API atopouse tamen un erro na xestion da memoria compartidaasociada a cola de mensaxes que producıa un fallo de segmento e que de novopropiciou a necesidade de iniciar un procedimento de depuracion custoso,

21


tras o cal vimos que era necesario crear una mapeo para a zona de memoriaafectada de tal forma que o procesador anfitrion puidese facer uso libre dela.

Chegado este punto, xa era posible iniciar unha comunicacion coa parteremota e solicitar a lista de funcions disponibles.

A continuacion traballouse en engadir as funcions para solicitar a asig-nacion e liberacion de areas de memoria en 2D ao subsistema de TILER. Opunto complicado foi que, debido o xeito no que TILER define estruturas dedatos que contenen e descreben as areas de memoria asignadas, a nosa biblio-teca de DCE debe manter unha lista enlazada delas como cache e entregarao usuario so a area de memoria que casteara a estrutura de datos que estarequira. Ası, cando se pida liberar un bufer, a biblioteca de DCE buscara aestrutura que o conten na sua lista e podera ser manexado polo TILER.

Tras este traballo disponemos dun sinxelo programa de decodificacionde video baseado na nosa biblioteca funcional co que podemos verificar ocorrecto funcionamento do demonio e a biblioteca desenvolvidos.

Cabe salientar que tamen intentamos cubrir a parte de codificacion devideo, sen embargo finalmente Texas Instruments decidiu non proporcionarcodificadores de video funcionais para as placas Panda Board polo que nonpuidemos abordar esta funcionalidade.

Elemento de GStreamer

O ultimo obxectivo deste traballo foi o desenvolvimento de elementos deGStreamer que procesen frames de vıdeo utilizando SysLink, e ası aproveitaras vantaxes da arquitectura AMP .

Utilizaronse as bibliotecas desenvolvidas como sustento para construırestes elementos.

GStreamer esta baseado en plugins que proven de distintos codificadorese demais funciones. Os plugins contenen obxectos que se conectan entre sipara formar unha tuberıa (pipeline, en ingles). Estas tuberıas definen o fluxodos datos multimedia ao longo do seu procesamento.

A funcion basica de GStreamer e a de prover un marco de traballo para osplugins, para o fluxo dos datos e o manexo e negociacion dos tipos dos datosa procesar. Tamen prove dunha API para escribir aplicacions que fagan usodestas tuberıas.

Os elementos son o fundamento de GStreamer. Os elementos estan con-tidos dentro dos plugins e proven calqueira tipo de funcions, que, cando seconectan con outros elementos: Por exemplo, un elemento fonte prove os da-tos dun fluxo, e un elemento tipo filtro actua sobre eses datos e, para rematar,un elemento tipo destino desprega ou almacena os datos procesados.

Os elementos, como xa dixemos, son encasulados en plugins para que

22


GStreamer poida utilizalos. Un plugin e un bloque cargable en memoria, xe-ralmente unha biblioteca enlazada dinamicamente. Un plugin pode conter aimplementacion dun ou varios elementos.

No caso que nos incumbe, desenvolveuse un plugin que conten, polo mo-mento, un so elemento: un decodificador de H264 que soporta alta definicion,que e o que obtivemos da nosa proba do obxectivo anterior.

Neste momento o DCE en AppM3 so soporta tres decodificadores:

H264

JPEG

MPEG2

Por agora so implementaremos un elemento que decodifique H264. Nofuturo serıa posible estender o traballo realizado para soportar formatos adi-cionais, coma JPEG e MPEG2, aında que consideramos que dita tarefa e re-lativamente trivial unha vez se conta coa base desenvolvida durante esteproxecto.

Un dos primeiros problemas con que nos topamos e que, cando se solicitanbuferes ao TILER estes poden ser 1D ou 2D. O optimo serıa usar os buferes2D, para poder explotar as suas capacidades de rotacion ou espello, con todo,para poder realizar isto, o modulo requere manexar unha marxe ou stride eningles. Esta marxe, visto o bufer como un lenzo de duas dimensions, serıao espazo en branco, sen utilizar, antes de comezar os lımites do fotograma.Esta marxe e utilizada coma memoria intermedia para facer operacions sobreo bufer.

Desta maneira, cando se necesita pasar un bufer xerado polo TILER aoseguinte elemento conectado na tuberıa, este tera espazos en branco que nonsabera como procesar.

Por este motivo, Rob Clark propuxo un novo tipo de dato consinta4:“video/x-raw-yuv-strided”, mediante o cal se poida expresar a natureza dobufer emitido ou esperado polo elemento. Tamen, para converter de xeitoautomatico a marxe dos buferes, e poder mesturar elementos capaces deprocesar marxe ou non, Rob desenvolveu un elemento chamado GstStride-Transform5.

Co anterior, xa poderemos procesar os buferes que solicitemos ao TILER(1D ou 2D) de xeito transparente dentro de GStreamer.

4http://gstreamer-devel.966125.n4.nabble.com/proposal-support-for-row-stride-in-gstreamer-td973444.

html5https://gitorious.org/gstreamer-omap/gst-plugins-base/trees/v0.10.35+

ti/gst/stride

23


Outra sorpresa interesante foi descobrir que DCE procesa os buferes dexeito sıncrona. E dicir, solicıtase un bufer de entrada a TILER, copiaselle ainformacion a decodificar, executase a chamada remota de DCE para proce-sar o bufer e esperase o bufer de saıda.

O feito de ter que esperar polo bufer de saıda foi realmente sorprendente,xa que a experiencia anterior con DSPBridge en OMAP3, e de acordo cocomentado sobre DOMX, o procesamento dos buferes era asıncrono, e dicir,unha vez co bufer con datos envıase ao seu procesamento, non se espera porunha resposta, senon que se poden enviar mais buferes mentres haxa espazona memoria reservada. A resposta chega a traves dunha mensaxe emitidapolo procesador remoto ao procesador anfitrion, onde pode entregar un oumais buferes con datos xa procesados.

Que o procesamento de DCE sexa sıncrono simplifica moito o desen-volvimento de elementos de GStreamer, xa que o deseno base de GStreameresta fundado na sincronıa do filtro, sen limitar, claro, aos filtros asıncronos,pero para estes hai que usar certas tecnicas mais complexas.

Con este elemento e posible facer tuberıas para o procesamento de vıdeoen formato H264 a formato RAW codificado en YUV 420.

24

4. NORMALIZACION NA EXECUCION E CONTROL Igalia S.L.

4 Normalizacion na execucione control do proxecto

4.1. Metodoloxıa empregada

A metodoloxıa a empregar no desenvolvemento deste proxecto foi de tipoaxil. Nun contexto xeral, este termo refırese a un xeito de desenvolvemen-to de software baseado en iteracions, onde os requisitos e as solucions evo-lucionan por colaboracion entre os membros de equipos multidisciplinaresauto-organizados.1

Para a correcta implementacion deste metodo de traballo e preciso quecada membro tena asignadas responsabilidades claras para a realizacion dassuas tarefas.

Polo tanto definıronse tarefas e responsabilidades concretas para o desen-volvedor, quen rendirıa contas do seu traballo en reunions periodicas co co-ordinador do proxecto, posteriormente resumidas nunha paxina de accesopublico para a comprobacion por parte do organismo xestor2, coas seguintescredenciais (login / password): xunta / corphAv2.

Tratase dunha filosofıa de liderado que estimula o traballo en grupo, aauto-organizacion e, por suposto, a rendicion de contas ao resto dos membrosdo equipo, tıpico dos metodos agile, os cales promoven procesos de adminis-tracion de proxectos bastante disciplinados que promocionan a adaptacion ea inspeccion frecuente.

Outro medio de coordinacion empregado nalgunha ocasion, aında quenormalmente con un caracter mais informal por non ser tan necesario, eranas reunions presenciais para debater e tomar decisions a medio-longo prazo.

Non obstante, a forma mais usual de coordinacion entre os membros dogrupo (de caracter diario) tivo lugar a traves de medios electronicos, princi-palmente salas de chat, canles de IRC e mediante correo electronico, os calesdemostraron ser perfectamente axeitados.

1http://en.wikipedia.org/wiki/Agile software development2https://wiki-syslink.igalia.com

25


Podemos considerar estas practicas coma propias dunha enxenarıa maispractica, co fin ultimo de acadar un desenvolvemento acelerado de Softwarede alta calidade. Do mesmo xeito, dende o punto de vista empresarial, asmetodoloxıas axiles alinan desenvolvemento con necesidades de cliente e cosobxectivos da empresa.

En canto ao progreso realizado, todalas melloras e novos desenvolvemen-tos foron contribuidas a repositorios publicos, polo que a analise das contri-bucions realizadas durante o proxecto SysLink seran facilmente identificablese medibles. Ademais, todos os desenvolvementos realizados quedaron sem-pre claramente asignados a candanseu autor, o cal proporciona un nivel detransparencia e informacion maximo ao traballo realizado.

4.2. Documentacion e resultados xerados

As metodoloxıas agile caracterızanse por priorizar a consecucion de soft-ware que funcione sobre a elaboracion dunha extensa documentacion. Estefoi o principio que guiou en todo momento o traballo do grupo durante odesenvolvemento do proxecto.

Non obstante, esto non implica carencia de documentacion en absolu-to. Como se mencionou anteriormente, de forma periodica, se mantiveronreunions de seguemento onde se discutıa o progreso nas tarefas asignadas, oslogros obtidos na iteracion, os problemas mais importante atopados e o plande traballo e obxectivos primarios para a seguinte iteracion. Os resultadosdestas reunions, con caracter mensual, eran reflexados nas actas correspon-dentes 3.

Por outro lado, naqueles casos nos que era preciso xerar unha documen-tacion de caracter mais tecnico, ou simplemente no caso de que fose relevantepara outros desenvolvedores de SysLink alleos a este proxecto concreto, uti-lizouse a ferramenta OmapPedia4 do proxecto, a cal proporciona un sistemade tipo Wiki para tal fin.

Na paxina web do repositorio de codigo deste proxecto 5, podese atoparsempre a ultima version do mesmo.

Por ultimo, unha ultima vıa de publicacion dos resultados obtidos foronos blogs dos desenvolvedores de Igalia, os cales se encontran agregados nosprincipales medios relacionados, coma coma Planet Maemo6 e, por suposto,

3https://wiki-syslink.igalia.com (Credenciais na seccion 4.1)4http://omappedia.org5https://gitorious.org/vj-pandaboard/syslink/6http://planet.maemo.org

26


o Planet Igalia7, dotandoos de maior visibilidade no exterior.Tamen se logrou a aceptacion de unha ponencia nun dos eventos multi-

media de software libre mais importantes, a GStreamer Conference, a finaisdo mes de Outubro en Praga, onde se difundiran os resultados do proxecto.

4.3. Execucion e control contınuo

A principal ferramenta empregada para o control de versions e o reposi-torio git do proxecto8. O uso deste repositorio non precisou da instalacionde ningunha aplicacion adicional nos recursos de Igalia.

Este proxecto emprega un conxunto de bibliotecas pertencentes ao proxec-to GStreamer que tamen precisan de certo traballo, especialmente desenvolve-mento de novas funcionalidades. Este codigo atopase aloxado nun repositoriopublico git9

No relativo o control do progreso e a planificacion, ademais do contactodiario entre os membros do equipo, realizaronse reunions mensuais de se-guimento mais intensas nas que se revisaban en detalle a planificacion e osobxectivos do proxecto, avaliando o avance con respecto ao planificado. Des-tas reunions redactaronse actas que se atopan no wiki do proxecto, pero quetamen incluımos a continuacion para maior comodidade.

4.3.1. Actas de coordinacion mensuais

Marzo

Primeira reunion para definir o alcance do proxecto, obxectivos e plande traballo.

Temos no noso poder un Panda Board proporcionado por Texas Ins-truments que incorpora un procesador OMAP4330.

Texas Instruments esta a traballar en proporcionar codecs OpenMAXpara achegar as capacidades multimedia do procesador os desenvolve-dores.

Segundo a nosa experiencia ca familia OMAP3, esta aproximacion nonsera capaz de explotar o 100 % das capacidades do hardware derivadodo “overhead” que a implementacion de OpenMAX vai introducir.

7http://planet.igalia.com8https://gitorious.org/vj-pandaboard/syslink/9http://cgit.freedesktop.org/gstreamer/

27


No caso da familia OMAP3, o proxecto gst-dsp (empregado por Nokiaen lugar do OpenMAX proporcionado por Texas Instruments) eviden-ciou que a solucion baseada en OpenMAX vina con serios problemasde rendemento e estabilidade.

A aproximacion de gst-dsp para OMAP3 basouse en facer una inter-face no espazo de usuario moi lixeira que interactua directamente comodulo do kernel que proporciona os servicios multimedia (dsp-bridge),reduzindo a “overhead” de software o mınimo perdendo a teorica por-tabilidade multi-plataforma proporcionada por OpenMAX.

O noso obxectivo co OMAP4 e a creacion dunha capa software lixeiraque proporcione mellor rendemento e resultados que a version Open-MAX, de forma similar o obtido por Nokia con gst-dsp para OMAP3.

OMAP4 ten novo hardware multimedia e unha nova interface no kernel(mediante o modulo SysLink), polo que sera necesario partir dende cero.

O plan de traballo para este mes marca dous obxectivos:

• Evaluar en detalle as capacidades do OAMP4330 que temos enxeral, e as capacidades multimedia en particular.

• Analizar mecanismos que nos permitan construir imaxes de soft-ware modificadas (para uncluir os nosos componentes de software)que poidamos executar no Panda Board.

Abril

Tenemos un conecemento adecuado das capacidades hardware da Pan-da Board, polo menos as relevantes para os nosos obxectivos neste pro-xecto.

O hardware multimedia resulta bastante mais complexo que no caso deOMAP3.

O OMAP4 proporciona un procesador ARM principal con dous nucleosARM Cortex-A9, un DSP e un procesador especializado en multimediacon dous nucleos ARM Cortex-M3.

Syslink e o modulo do kernel que proporciona mecanismos IPC co ob-xectivo de implementar multi-procesamento asıncrono nestes procesa-dores.

28


En multi-procesamento asıncrono cada procesador e independente ecorreo o seu proprio sistema operativo.

Neste sistema existe un procesador maestro encargado de controlar oderivar traballo os procesarores escravos.

O programa que corre no procesador maestro e o Remote CommandMessaging client, mentres que nos procesadores escravos temos a parteservidora.

O noso traballo conssistira en facer una fachada no espazo de usuariopara a interfaz exposta por syslink.

Tamen fixemos progresos no campo de habilitar imaxes propias na Pan-da Board. Finalmente decidimos partir da base dunha imaxe de Ubun-tu, que ademais proporciona binarios optimizados para ARMV7.

Traballamos en preparar una imaxe booteable desta version de Ubuntuno Panda Board.

Foi particularmente laborioso a configuracion do kernel para o empregode SysLink. Neste campo foi necesario buscar repositorios mais ou me-nos oficiais de Texas Instruments, xa que os parches de Ubuntu estabanmoi por detras do desenvolvemento por parte de Texas Instruments, oproblema aquı e que, sendo un desenvolvemento moi novo, o soportetodavıa non e oficial, polo que e necesario progresar mediante proba eerror.

Unha vez habilitado o kernel e creada a imaxe arrancable e fixemos undiagnostico basico das capacidades hardware disponibles na placa (red,video, audio, etc).

O seguinte paso foi a preparacion dun entorno de desenvolvementoque nos permita xerar binarios compatibles coa arquitectura hardware,para isto foi necesario establecer un sistema de compilacion cruzada(que xeramos empregando OpenEmbedded).

O plan de traballo para mes conssite en:

• Probar libdce e gst-ducati.

• Deseno da API mınima do espazo de usuario.

29


Maio

Compilamos, instalamos e probamos libdce e gst-ducati, desenvolvidospor Rob Clark (Texas Instuments) coma proba de concepto orientada ahabilitar codecs GStreamer non baseados en OpenMAX para OMAP4.

Revisamos o codigo dos dous proxectos para estudiar o seu funciona-mento e adquirir conecemento da forma na que os programas de usuariose comunican con SysLink.

Unha vez rematado o analise comezamos a desenar e implementar unhaAPI mınima co obxectivo de reducir a complexidade das solucions an-teriores.

Coma proba de concepto, comezouse a implementacion dun reemplazopara o demonio de Syslink, que e o encargado de cargar os sistemasoperativos de cada un dos procesadores escravos e establecer os mapeosde memoria necesarios (os procesadores escravos que non tenen MMU).

Os obxectivos para este mes son a finalizacion do demonio e probasde funcionamento ası como a continuacion do desenvolvemento da APImınima.

Xuno

Atopamos problemas tecnicos que estan retrasando o desenvolvementodo demonio.

Unha vez cargada a imaxe do sistema operativo no procesador escravoe necesario enviar unha mensaxe para que o nucleo remoto arranque emude a un estado no que poida comezar a recibir e procesar mensaxes,pero por algun motivo, cando enviamos esta mensaxe o sistema rompe.

Ante a falta de documentacion, a unica solucion que atopamos paraencontrar o problema e o traceo da actividade contra o kernel do de-monio orixinal proporcionado por Texas Instruments, e comparar pasoa paso co noso remplazo ası coma a lectura do codigo do kernel paraintentar comprender a orixe do problema.

Finalmente se conseguiu resolver o problema, que pasaba por faceruna inicializacion do subsistema MMU, proporcionando unha area dememoria compartida e mapeos de memoria correspodentes para poderoperar cos procesadores escravos.

30


A traceo da actividade e un proceso laborioso e complicado e por esemotivo se esta a retrasar o desenvolvemento mais do previsto.

Se comezou co traballo de diseminacion do proxecto escribindo un blogpost sobre a evolucion da plataforma OMAP no relativo a multimediacubrindo o paso por OMAP3 (dsp-bridge) e OMAP4 (SysLink). A ideaaquı e facer una serie breve de posts explicando o contexto tecnoloxicoe o traballo que esta sendo realizado por Igalia neste campo e difun-dilos a traves de Internet (mediante planets) para que os obxectivose os resultados do noso traballo cheguen os actores de interese (TexasInstruments e os seus clientes).

Fixeronse probas de rendemento da inicializacion de demonio de sys-link, comparando o noso remplazo (coa API mınima que estamos adesenvolver) co demonio orixinal proporcionado por Texas Instruments.Os resultados son moi positivos, xa o que o noso demonio de remplazofinaliza a sua inicializacion nun tempo moitısimo menor.

Tamen se comenzaron conversas co desenvolvedor de libdce e gst-ducatipara intercambiar impresions e obter informacion relativa o futuro doproxecto SysLink. Habera alguns cambios no kernel e aparentementeQualcomm poderıa estar interesada en empregar partes destes modulosIPC. Son boas noticias, ya que indican que o interese neste campotecnoloxico e solido e mais actores poden unirse os esforzos a medio oulongo prazo.

O plan para o seguinte mes centrarase no analise de DCE (DistributedCodec Engine) coma alternativa a DOMX e a continuacion das tarefasde diseminacion proponendo una presentacion do noso traballo nun doseventos multimedia mais importantes no panorama de Software Libre,a GStreamer Conference.

Xullo

Analizouse o proxecto DCE desenvolvido individualmente por Rob Clark(traballador de Texas Instruments) coma alternativa a solucion propie-taria proporcionada tamen por Texas Instruments (DOMX).

SysLink proporciona un mecanismo para o intercambio de mensaxesentre os diferentes nucleos e un protocolo asociado para esta comu-nicacion (RCM). Sobre este mecanismo de intercambio de mensaxese necsario establecer un protocolo ası coma unha parte cliente e servi-dora para a labor concreta multimedia (codificacion e decodificacion).

31


Texas Instruments proporciona un protocolo propietario conecido comoDOMX (Distributed OpenMAX), e Rob Clark desenvolveu un proto-colo diferente conecido coma DCE (Distributed Codec Engine) comaalternativa libre a solucion propietario de Texas Instruments.

Tras profundizar na implementacion de DCE fixemos unha proba naque o enlazamos co noso demonio de reemplazo para avaliar o funcio-namento conxunto de ambos componentes.

Descubrimos a necesidade de traballar mais no demonio e implementarAPIs adicionais para a xestion de areas de memoria compartida parapoder realizar esta proba.

Unha vez implementadas as APIs requeridas, as probas realizadas mos-traron problemas (o kernel bloquease intentando cerrar un dispositivo).

De novo, coma no caso anterior, e necesario meterse no codigo do kernele intentar depurar a orixe do problema para poder continuar, o quenovamente esta a requerir bastante traballo pola nosa parte.

No relativo a diseminacion dos resultados do proxecto, avanzouse enduas frentes:

• Se redactou e enviou a proposta para a presentacion do noso tra-ballo na GStreamer Conference e a Embedded Linux Conference.Conseguimos a aceptacion da presentacion na GStreamer Confe-rence, a presentar a finais de Outubro.

• Publicouse un segundo blog post, nesta ocasion centrado en Sys-Link v2 e as vantaxes do multiprocesamento asıncrono, DCE e onoso traballo nunha API lixeira para SysLink.

O plan parao proximo mes consiste en resolver o problema tecnicodetectado, completar as probas do noso demonio e comenzar a portaro test de decodificacion con SysLink e DCE a nosa API.

Agosto

No se consegiu facer grandes progresos neste mes.

A analise do problema que atopamos nos tests con DCE e o noso demo-nio foi moi dificil de resolver, ainda que o final conseguimos encontrara raiz do problema.

32


Aparentemente, cometimos un erro na maneira na que asignabamos adireccion da pila para a cola de mensaxes.

Correxido o erro todo comezou a funcionar adecuadamente.

Neste punto temos unha primeira version completamente funcional eprobada do noso remplazo do demonio de SysLink v2.

O seguinte paso no proxecto e reemplazar o programa de probas deRob Clark usa con DCE cunha version funcionalmente equivalente queusa a nosa API mınima para a interactuacion con SysLink.

Septembro

Durante o desenvolvemento da nova version do programa de probas deDCE baseado na nosa API atopuse de novo con un problema tecnico,xa que na xestion da memoria compartida asociada a cola de mensaxesobtemos un fallo de segmento. De novo temos que volver a depurar oque esta pasando con paciencia.

En paralelo co analise da razon para o noso fallo de esegmento, apro-veitouse para buscar e adoptar una version do kernel mais recente eestable para soportar o desenvolvemento.

Finalmente obtıvose unha nova version do kernel a traves de Linaro.Fixeronse unhas probas basicas e efectivamente esta version parece sermais estable que a version anterior.

Todavıa non se consegui resolver o problema do fallo de segmento, poloque sera necesario continuar co proceso de analise durante o mes queven con absoluta prioridade, xa que este problema esta a bloquear anosa capacidade para avanzar no desenvolvemento e queremos avanzaro maximo posible antes da presentacion en Outubro na GStreamerConference.

Outubro

Finalmente, e de novo tras un largo e lento proceso de depuracion,encontrouse a solucion o problema do fallo de segmento.

E necesario crear una mapeo para a zona de memoria afectada de talforma que o procesador anfitrion poida facer uso dela.

33


Neste punto e posible iniciar unha comunicacion coa parte remota esolicitar a lista de funcions disponibles, sen embargo neste punto ato-pamos un novo problema (se recibıa un erro).

A continuacion comezouse co desenvolvemento do protocolo/API defi-nido por DCE en termos da nosa API mınima para SysLink.

Investigouse sobre o manexo de buferes con marxes (strides) en GS-treamer, ası como o control sıncrono de DCE.

Comezouse a traballar no elemento de GStreamer para decodificacionde H.264 utilizando as nosas bibliotecas de syslink e clientes de DCE eTILER.

Tıvose que crear un elemento GStreamer para o control dun anel debuferes, ası se poden reutilizar evitando a sobrecarga do TILER.

Este mes tamen se traballou na presentacion para GStreamer Confe-rence ası coma a asistencia a conferencia a finais de mes.

4.4. Acceso publico a informacion sobre o con-

trol do proxecto a traves de Internet

O acceso ao codigo fonte a traves do repositorio git e algo permanentee publico. Polo tanto, dende este punto de vista, a facilidade e a transparenciacoa que se fixo o desenvolvemento foron maximas.

En canto aos informes mensuais de seguemento, foron postos a disposiciondo organo xestor de forma centralizada a traves dun sistema con acceso webcifrado10.

En resumo:

Web principal do proxecto SysLink :http://omappedia.org/wiki/Syslink_Project

Web principal do proxecto DCE :http://omappedia.org/wiki/DistributedCodecEngine

Repositorio de codigo fonte principal:https://gitorious.org/vj-pandaboard/syslink/

10https://wiki-syslink.igalia.com (Credenciais na seccion 4.1)

34


Acceso aos informes mensuals (acceso privado11):https://wiki-syslink.igalia.com

No tocante a disposicion dunha version de demostracion do softwaredesenvolvido, hai que ter en conta que este proxecto esta ligado a disposiciondun hardware especıfico (a Panda Board) e a instalacion do software nestehardware require conecementos bastante avanzados, polo que non e posibleproporcionar unha version de demostracion a traves de Internet.

Ademais, o traballo realizado centrase no desenvolvemento dunha biblio-teca de software e non de unha aplicacion con interfaz visual, o que dificultaa demostracion dos resultados do proxecto.

En calqueira caso, e posible facer unha demostracion do correcto funcio-namento da biblioteca mediante o uso dos programas de probas desenvolvidosdurante o proxecto (o demonio de syslink e o programa de probas baseadoen DCE) para ilustrar o proceso de decodificacion multimedia dun arquivode entrada con vıdeo en formato H264, obtendo coma resultado un vıdeo desaıda en formato RAW. Por suposto, ponemonos a disposicion do organismorevisor para arranxar unha demostracion nas nosas oficinas deste proceso seası o consideran oportuno para verificar o traballo realizado.

4.5. Publicidade do cofinanciamento

Como se pode comprobar na web pulica do proxecto http://www.igalia.com12,os logotipos da Presidencia da Xunta de galicia e do FEDER indican publica-mente o cofinanciamento do proxecto a traves destas institucions de caracterpublico, se explican en detalle as caracterısticas da concesion e se adxuntaesta memoria para acceso publico.

inda que non forma parte dos requisitos, tamen se poden atopar os lo-gotipos da Xunta de Galicia e do FEDER no wiki privado do proxectohttps://wiki-syslink.igalia.com13, tal coma se pode aprociar na figura4.1.

11Credenciais na seccion 4.112http://www.igalia.com/nc/work/project/item/gstsyslink13Credenciais na seccion 4.1

35


Figura 4.1: Wiki interno do proxecto GstSysLink

36

Documents

Procesamento multimedia acelerado por hardware con ... · 2. DEFINICION DO PROXECTO Igalia S.L. tar m ais de dous procesadores, permitiendo o procesamento paralelo para a aceleraci