Optimalisatie van een wavelet video-encoder/decoder in software gebruik makend van multimedia-instructies

Transcriptie

1 Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. J. Van Campenhout Optimalisatie van een wavelet video-encoder/decoder in software gebruik makend van multimedia-instructies door Christophe Colman Promotor: prof. dr. ir. D. Stroobandt Thesisbegeleider: dr. ir. M. Christiaens Afstudeerwerk ingediend tot het behalen van de academische graad van burgerlijk ingenieur computerwetenschappen. Academiejaar

2

3 Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. J. Van Campenhout Optimalisatie van een wavelet video-encoder/decoder in software gebruik makend van multimedia-instructies door Christophe Colman Promotor: prof. dr. ir. D. Stroobandt Thesisbegeleider: dr. ir. M. Christiaens Afstudeerwerk ingediend tot het behalen van de academische graad van burgerlijk ingenieur computerwetenschappen. Academiejaar

4 Dankwoord Ik wens iedereen te bedanken die mij geholpen heeft bij de totstandkoming van dit afstudeerwerk. Meer bepaald wil ik mijn begeleiders Mark Christiaens en Hendrik Eeckhaut bedanken. Toelating tot bruikleen De auteur geeft de toelating dit afstudeerwerk voor consultatie beschikbaar te stellen en delen van het afstudeerwerk te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit de scriptie. 28 mei 2004 i

5 Optimalisatie van een wavelet video-encoder/decoder in software gebruik makend van multimedia-instructies door Christophe Colman Afstudeerwerk ingediend tot het behalen van de graad van burgerlijk ingenieur computerwetenschappen Academiejaar Universiteit Gent Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. J. Van Campenhout Promotor: prof. dr. ir. D. Stroobandt Thesisbegeleider: dr. ir. M. Christiaens Samenvatting In dit eindwerk worden enkele mogelijke optimalisaties beschreven voor een wavelet gebaseerde video-codec. Deze optimalisaties maken voornamelijk gebruik van de SSE2-instructies uit de instructieset van de Intel Pentium 4 processor. Voor het meest tijdkritische deel van de video-codec, de bewegingsschatting, word met behulp van deze optimalisaties een versnelling bekomen van een factor 6 tov. de originele code. Naast een beschrijving van deze optimalisaties wordt ook de werking van de video-codec samen met de architectuur van de Intel Pentium 4 processor uitgelegd. Trefwoorden: video-codec, bewegingsschatting, Pentium 4, multimedia-instructies ii

6 Inhoudsopgave 1 Inleiding Doelstelling Wavelet video-codec RESUME-project Encoder Decoder Tijdkritische onderdelen encoder Profilering encoder Full-search Intel Pentium 4 processor Keuze processor Micro-Architectuur Multimedia-instructies Optimalisaties Optimalisaties in C-code Alignatie data op 16 Byte grenzen Rand rond beelden Hypothese 2 bij bewegingsschatting Optimalisaties in assembler Berekening SAD-waarde Verwerking 4x4-blok Berekening van gemiddelde bij Hypothese iii

7 4.2.4 Gebruik van accumulator Inlezen niet-gealigneerde data Conclusie Profilering geoptimaliseerde code Mogelijke uitbreidingen A Broncode 30 Bibliografie 31 iv

8 Lijst van figuren 1.1 Schema encoder Bewegingsschatting: resulterende foutbeelden Discrete Wavelet Transformatie van 1 ste orde Schema decoder Bewegingscompensatie: temporele decompositie Zoekruimte voor macroblok Intel Netburst Micro-Architectuur Uitvoeringseenheden Pentium SIMD-instructie Intel Pentium 4 SSE2 uitvoeringsomgeving Origineel beeld met rand errond PSADBW-instructie bij gebruik met MMX-registers PUNPCKLBW-instructie PACKUSW-instructie v

9 Lijst van tabellen 2.1 Profilering originele code Profilering geoptimaliseerde code vi

10 Hoofdstuk 1 Inleiding 1.1 Doelstelling Zoals de titel van dit afstudeerwerk reeds laat vermoeden, is het doel van deze thesis het optimaliseren van de C-code van een wavelet-gebaseerde video-codec. Deze codec is ontwikkeld aan de VUB in het kader van het RESUME-project. Voor de optimalisaties zal gebruik gemaakt worden van multimedia-instructies uit de instructieset van de Intel Pentium 4 processor. Ik beoog een versnelling van een factor 4 te behalen. 1.2 Wavelet video-codec RESUME-project De afkorting RESUME staat voor Reconfigurable Embedded Systems for Use in scalable Multimedia Environments [9]. Hiermee wordt dan ook het belang van deze video-codec aangegeven, namelijk de temporele en spatiale schaalbaarheid van de videostroom bij het decoderen. Het is de bedoeling dat dezelfde videostroom op verschillende apparaten afgespeeld kan worden. Deze apparaten, gaande van PC tot palmtop en zelfs GSM, hebben allen verschillende beperkingen wat de weergave van deze videostroom betreft en bij het decodeerproces moet er dus rekening gehouden worden met deze beperkingen. Het is hierbij dat de hierboven genoemde schaalbaarheden van pas komen. Deze zullen dan ook nog aan bod komen in de verdere bespreking van de codec. 1

11 Figuur 1.1: Schema encoder Encoder De videostroom bestaat uit een opeenvolging van beelden. Vooraleer de videostroom geëncodeerd wordt, wordt hij opgedeeld in groepen van 16 beelden, zogenaamde GOP s (Group of Pictures), die aan de encoder aangeboden worden. Zoals weergegeven in Figuur 1.1 bestaat de encoder uit 3 grote blokken: ME: bewegingsschating of Motion Estimation DWT: Discrete Wavelet Transformatie QT-cod: QuadTree- en Entropie-codering De uit de bewegingsschatting bekomen bewegingsvectoren (Motion Vectors, aangeduid in Figuur 1.1 met MV) worden na encodering (MVC in Figuur 1.1) opgenomen in de uiteindelijke bitstroom. Bewegingsschatting Bewegingsschatting heeft tot doel een beeld op te bouwen uit blokken van referentiebeelden om zo enkel de vectoren van deze blokken te bewaren i.p.v. het volledige beeld. Indien de schatting niet perfect is dient ook nog een foutbeeld bijgehouden te worden. Zo bekomt men een compressie van de videostroom. De 16 beelden van de huidige GOP en het eerste beeld van de volgende GOP worden onderverdeeld in referentiebeelden (beelden met even nummer in Figuur 1.2 samen met R1 en R2) en beelden waarvan de bewegingsschatting bepaald zal worden. Voor elk van deze te schatten beelden wordt naast de bewegingsvectoren ook het foutbeeld bepaald, dat het verschil is tussen het originele en het geschatte beeld. Deze foutbeelden worden in Figuur 1.2 aangeduid met Hi. Na schatting van 2

12 Figuur 1.2: Bewegingsschatting: resulterende foutbeelden de beelden met oneven nummer worden de referentiebeelden opgedeeld in nieuwe referentiebeelden en te schatten beelden. Dit herhaalt zich tot er maar 2 referentiebeelden (eerste beeld van huidige en volgende GOP) en 1 foutbeeld overblijven. De pijlen in de figuur duiden de referentiebeelden aan die gebruikt worden voor de bewegingsschatting en de bepaling van het foutbeeld waarnaar de pijlen verwijzen. Voor de laatste GOP van de videostroom is R2 gelijk aan R1, omdat er na de laatste GOP natuurlijk geen GOP meer volgt. Elk te schatten beeld wordt opgedeeld in blokken van 16 op 16 pixels (macroblokken) en in de 2 aangrenzende referentiebeelden wordt voor elk macroblok naar het best gelijkende blok gezocht. De coördinaten van dit blok bepalen dan de bewegingsvector. Om een betere schatting te kunnen bekomen wordt ook de bewegingsschatting bepaald voor sub-macroblokken van 8 op 8 pixels en kan het te schatten beeld ook nog geïnterpoleerd worden zodat een beeld opgebouwd wordt uit de tussenliggende pixels van het originele beeld. De bewegingsschatting kan bestaan uit een (sub-)macroblok uit 1 van de referentiebeelden (hypothese 1), maar kan ook bestaan uit een uitmiddeling van (sub-)macroblokken uit beide referentiebeelden (hypothese 2). Na bepaling van de bewegingsvectoren wordt het foutbeeld berekend en wordt dit foutbeeld doorgestuurd naar het DWT-blok. De bewegingsvectoren worden opgenomen in de uiteindelijke bitstroom. 3

13 Discrete Wavelet Transformatie De discrete wavelet transformatie bestaat uit een laag- en een hoog-doorlaatfilter. Het laagdoorlaatfilter verwijdert de details uit een beeld en het hoogdoorlaatfilter verwijdert de vlakke gebieden uit het beeld zodat enkel de details behouden blijven. Bij beide filters bevat het resultaat slechts de helft van het aantal pixels. Door deze filters zowel in horizontale als in vertikale richting toe te passen bekomt men een beeld zoals in Figuur 1.3. De linker bovenhoek van de figuur bevat het laagdoorlaat gedeelte van zowel vertikale als horizontale transformatie, en verschilt weinig van de originele figuur. Enkel de grootte is gehalveerd. De overige gebieden bevatten een hoogdoorlaat component, wat resulteert in gebieden met veel zwart. De codec ondersteunt een wavelet transformatie van 3 de orde. Het resultaat wordt doorgestuurd naar de QuadTree- en entropie-encoder. QuadTree- en Entropie-codering De bekomen waveletcoëfficiënten worden opgesplitst in bitvlakken, d.w.z. in de binaire voorstelling van de waveletcoëfficiënten levert de minst beduidende bit van elke coëfficiënt een bitvlak op en zo voor elke andere bit van de coëfficiënten. In zo een bitvlak wordt dan via de quadtree-encoder elk vierkant van nullen voorgesteld door 1 nul en dit tot op het niveau van een enkele bit. Zo bekomt men een vrij grote compressie daar het resulterende beeld van de wavelettransformatie grote zwarte gebieden bevat. Het resultaat van de quadtree-codering wordt via de entropieencoder omgezet in een enkel vlottend komma getal. Voor meer over de wavelettransformatie en de entropie-codering verwijs ik naar de eindwerken van Inge Doms[4] en Michiel D Haene[3]. Zoals verderop duidelijk zal worden ligt de nadruk van dit eindwerk op de bewegingsschatting Decoder Zoals blijkt uit Figuur 1.4 bestaat ook de decoder uit 3 grote blokken die de inverse transformaties uitvoeren van de encoder: MC: bewegingscompensatie of Motion Compensation IDWT: Inverse Discrete Wavelet Transformatie 4

14 QT-dec: QuadTree- en Entropie-decodering De schaalbaarheden waarvan hierboven sprake was en die in de transformaties intrinsiek aanwezig zijn, zijn hier van belang. Ten eerste zorgt de inverse discrete wavelet transformatie voor spatiale schaalbaarheid. Indien men de inverse transformatie slechts doorvoert tot op bijvoorbeeld 1 ste orde en dan de linker bovenhoek van het beeld beschouwd (zoals in Figuur 1.3), dan hebben we ons origineel beeld maar dan in een kleinere resolutie en van iets mindere kwaliteit. Via de inverse wavelettransformatie kunnen we dus de resolutie van de film bepalen in verhouding tot de originele resolutie. In deze codec zijn verhoudingen van 1/1, 1/2, 1/4 en 1/8 mogelijk. Ten tweede zorgt de bewegingscompensatie voor temporele schaalbaarheid. Zoals aangegeven in Figuur 1.5 kan er via bewegingscompensatie bepaald worden hoeveel beelden er van een GOP gedecodeerd worden. Indien men bijvoorbeeld wenst dat de framerate slechts de helft bedraagt van de originele framerate dan decodeert men tot op het voorlaatste niveau en bekomt men enkel de beelden met even nummer uit de originele GOP. De pijlen in de figuur duiden aan welke beelden er gebruikt worden om het beeld te reconstrueren. R1 en R2 zijn respectievelijk het eerste beeld van de huidige en van de volgende GOP. Voor de laatste GOP is R2 gelijk aan R1. De beelden aangeduid met Hi zijn hier de gereconstrueerde beelden en niet de foutbeelden zoals bij de bewegingsschatting. 5

15 Figuur 1.3: Discrete Wavelet Transformatie van 1 ste orde Figuur 1.4: Schema decoder 6

16 Figuur 1.5: Bewegingscompensatie: temporele decompositie 7

17 Hoofdstuk 2 Tijdkritische onderdelen encoder 2.1 Profilering encoder Om te weten te komen welk onderdeel van de encoder de meeste tijd in beslag neemt, heb ik met behulp van gprof een profilering van de code gemaakt. De resultaten van deze profilering zijn terug te vinden in tabel 2.1 waarin enkel de meest tijdkritische functies opgenomen zijn. De profilering is uitgevoerd voor de encodering van 1 GOP in qcif-formaat. Dit formaat gebruikt beelden met een resolutie van 176 op 144 pixels. Zoals uit de tabel op te merken is, neemt de full-search-functie de meeste tijd in beslag. Dit is dan ook de functie waaraan ik de meeste aandacht besteed heb bij de optimalisatie van de code. Verder is op te merken dat de full-search-functie een onderdeel is van de bewegingsschatting en dat daarom ook de ME-functie in de tabel opgenomen is met een relatief kleine tijdsduur. Deze is te wijten aan het feit dat enkel de tijd in rekening gebracht wordt die effectief aan een functie besteed is zonder rekening te houden met de tijd gespendeerd in de functies die door die bepaalde functie opgeroepen worden. De encodering van de GOP nam seconden in beslag, niettegenstaande er in tabel 2.1 staat dat de cumulatieve duur seconden bedroeg. Dit is waarschijnlijk te wijten aan de aanroeptijd van de verschillende functies en die niet in rekening gebracht wordt in de profilering. Deze aanroeptijd van een functie omvat ondermeer het gereed maken van de stapel met de functieparameters en het op de stapel zetten van de waarden van registers die in de functie overschreven zullen worden. 8

18 % tijd cumulatief # sec. # sec. functie full search(... ) Interpolate frame int(... ) max valid partition(... ) prune mb(... ) rate est(... ) ME(... ) overige functies Tabel 2.1: Profilering originele code 2.2 Full-search Omdat aan deze functie de meeste aandacht besteed wordt, zal ik hier dieper ingaan op het algoritme van het zoeken naar de best gelijkende macroblok. Alhoewel de functienaam doet vermoeden dat beide referentiebeelden volledig afgezocht worden naar het best gelijkende macroblok, is dit toch niet het geval. In het algoritme van de VUB-codec wordt gezocht in de nabije omgeving van de huidige macroblok. Men gaat er namelijk vanuit dat het verschil tussen 2 opeenvolgende beelden gering is en dat het meest gelijkende macroblok dus in de buurt van het huidige macroblok moet liggen. Binnen deze zoekruimte bepaalt men een kleinere zoekruimte rond het macroblok waarin een eerste bewegingsschatting gezocht wordt. Rond deze eerste oplossing bepaalt men dan opnieuw zo een kleine zoekruimte waarin naar een betere oplossing gezocht wordt. Men herhaalt dit proces tot er geen betere oplossing meer gevonden wordt. Er wordt wel voor gezorgd dat deze kleinere zoekruimten zich steeds binnen de grotere zoekruimte bevinden. Het gebruikte algoritme is dus een Steepest Descent -methode. In tegenstelling tot een volledige zoektocht die altijd het optimale resultaat zal vinden, gebruikt men dus een algoritme dat een sub-optimale oplossing vindt indien de optimale oplossing zich buiten de zoekruimte bevindt. En zelfs indien de optimale oplossing zich in de zoekruimte bevindt, dan nog bestaat de kans dat deze niet gevonden wordt doordat het zoekpad zich in een andere richting begeeft weg van de optimale oplossing. Het criterium waarmee er bepaald wordt of een oplossing geschikt is of niet, is de SAD-waarde. Dit is de som van absolute verschillen of Sum of Absolute Differences tussen de pixels uit het huidige macroblok en de pixels uit het blok 9

19 van het referentiebeeld. Indien deze waarde kleiner is dan deze van een voorgaande oplossing dan wordt de bewegingsvector aangepast aan deze van het nieuwe blok. Vooraleer gezocht wordt in de referentieblokken kan de bewegingsvector voor het huidige macroblok benaderd worden door eerst te zoeken in een gesubsampelde versie van de referentiebeelden. Omdat deze beelden kleiner zijn dan de originele beelden zal men sneller tot een sub-optimale oplossing komen die dan als start gebruikt kan worden voor de zoektocht in de originele referentiebeelden. Voor de zoektocht in de gesubsampelde beelden wordt ook geen rekening gehouden met de geïnterpoleerde referentiebeelden, terwijl voor de zoektocht in de volledige beelden wel gezocht wordt in de geïnterpoleerde referentiebeelden. Voor de volledige referentiebeelden wordt eerst gezocht zonder rekening te houden met de geïnterpoleerde referentiebeelden. In een volgende stap wordt ook in de geïnterpoleerde referentiebeelden met interpolatiefactor 1/2 gezocht, maar wordt de kleinere zoekruimte ook verkleind. Dit wordt herhaald tot men de maximale interpolatiefactor van 1/8 bereikt heeft. Deze zoektocht wordt eerst voor hypothese 1 uitgevoerd, wat dus wil zeggen dat slechts een van de twee referentiebeelden gebruikt zal worden voor de bewegingsvector. Daarna herhaald men de zoektocht voor hypothese 2 waarbij dus het gemiddelde van de blokken uit beide referentiebeelden gebruikt wordt. Voor beide hypothesen worden de gevonden bewegingsvectoren bijgehouden. De full-search-functie wordt opgeroepen voor zowel de macroblokken van 16 op 16 pixels als voor de sub-macroblokken van 8 op 8 pixels. De gevonden bewegingsvectoren worden voor beide bijgehouden en pas later, in de prune mb-functie wordt bepaald welke bewegingsvectoren er gebruikt zullen worden. In Figuur 2.1 wordt de initiële toestand van de verschillende zoekruimtes voor een macroblok (MB) aangegeven. De grote zoekruimte wordt bepaald door de parameter search range, aangeduidt met SR op de figuur. De kleinere zoekruimte is ook afhankelijk van deze parameter en kan variren van de maximale zoekruimte tot een zoekruimte die langs alle zijden 1 pixel breder is dan het macroblok. Voor macroblokken die langs de rand van het beeld liggen, worden de randpixels gebruikt voor de pixels die in de zoekruimte buiten het beeld vallen. Zo krijgt men als het ware een rand met breedte gelijk aan de search range rond het beeld, die bestaat uit de randpixels van het originele beeld (Figuur 4.1). 10

20 Figuur 2.1: Zoekruimte voor macroblok 11

21 Hoofdstuk 3 Intel Pentium 4 processor 3.1 Keuze processor Voor de herimplementatie van de tijdskritische full search-functie met behulp van multimedia-instructies heb ik gekozen om de instructieset van de Intel Pentium 4 processor te gebruiken. Ik heb deze keuze gemaakt omdat op het moment van schrijven de Pentium 4 een van de meest verkochte processors is en ik dus zo kan testen in hoeverre de processor uitgerust is om de encoder uit te voeren. 3.2 Micro-Architectuur Om de lezer een idee te geven van de architectuur van de Intel Pentium 4 processor geef ik hier een korte inleiding. Een schema van de architectuur is gegeven in Figuur 3.1, waarbij de architectuur aangeduid wordt met de naam Intel Netburst Microarchitectuur[5]. Enkele belangrijke kenmerken zijn: Snelle uitvoering van instructies: ALU s (Arithmetic Logical Unit) werken aan de dubbele frequentie van de processor Hyper-gepijplijnd: pijplijn bestaat uit 20 trappen Dynamische uitvoering van instructies: out-of-order uitvoering met sprongpredictie Quad-pumped bus interface om 4 keer de effectieve snelheid van de bus toe te laten 12

22 Figuur 3.1: Intel Netburst Micro-Architectuur 1 ste en 2 de level cache met cache-lijnen van 64 Bytes en een vertraging van 2 klokcycli voor 1 ste level cache De front-end van de pijplijn zorgt voor het ophalen (fetch) en vooraf ophalen (prefetch) van instructies en de decodering van deze instructies in micro-instructies. De front-end zorgt ook voor sprong-predictie, wat voor de code van de encoder van belang zal zijn, zie verder. De out-of-order uitvoering van instructies is al een belangrijke stap naar parallellisme omdat dit ervoor zorgt dat de processor de micro-instructies zo kan ordenen dat wanneer een micro-instructie wacht op uitvoering er toch al andere micro-instructies uitgevoerd kunnen worden. De verschillende uitvoeringseenheden zijn aangeduid in Figuur 3.2. De verwerkingseenheden waarbij dubbele snelheid staat, kunnen 2 microinstructies per klokcyclus uitvoeren. Via de poorten, die ook aangeduid zijn op de figuur, worden de instructies verdeeld over de verschillende verwerkingseenheden[7]. 13

23 Figuur 3.2: Uitvoeringseenheden Pentium 4 Om ervoor te zorgen dat het lijkt alsof de instructies in programmavolgorde uitgevoerd zijn, wordt de toestand van de processor in de retirement-eenheid volgens programma-volgorde aangepast alhoewel de micro-instructies out-of-order uitgevoerd worden. 3.3 Multimedia-instructies De belangrijkste eigenschappen van de Intel Pentium 4 voor dit eindwerk zijn de SSE2-instructies. SSE2 staat voor Streaming SIMD Extensions versie 2, waarbij met de afkorting SIMD Single Instruction Multiple Data bedoeld wordt. Met deze term wil men aanduiden dat een enkele instructie in parallel op verschillende data kan inwerken, zoals aangegeven op Figuur 3.3. Stel bijvoorbeeld dat de operatie het optellen van 2 getallen is dan kunnen met een SIMD-instructie 4 paren van getallen in parallel opgeteld worden. Deze mogelijkheid wordt geboden door SSE2- instructies. De 2 in SSE2 duidt op een uitbreiding van de oorspronkelijke SSEinstructies, die op hun beurt een uitbreiding waren van de MMX-instructies. 14

24 Met behulp van de SSE2-instructies kunnen nu ook integer-bewerkingen uitgevoerd worden waarbij gebruik gemaakt wordt van de XMM-registers. Voorheen kon men voor integer-bewerkingen enkel de MMX-registers gebruiken. De XMMregisters zijn 128-bit groot zodat men dubbel zoveel data in parallel kan verwerken als mogelijk was met MMX-registers. Voor de code van de encoder zullen we vooral gebruik maken van volgende integer datatypes: Byte: 8 bits Woord: 16 bits Dubbel-Woord: 32 bits Quad-Woord: 64 bits Voor het parallel verwerken zullen vooral de datatypes Byte en Woord van belang zijn, terwijl Dubbel-Woord en Quad-Woord vooral voorkomen bij het inlezen en wegschrijven van data. Dit geeft dus de mogelijkheid om 8 of 16 Bytes en 4 of 8 Woorden parallel te verwerken. In Figuur 3.4 zijn de verschillende registers weergegeven die gebruikt kunnen worden met de SSE2-instructies. Het MXCSR- en EFLAGS-register op de figuur zijn 2 toestands- en controle-registers die voor de code van de encoder van geen verder belang zijn. De gebruikte instructies zullen verderop in het hoofdstuk over de optimalisaties uitgelegd worden. Het inlezen van 128 bit met behulp van de SSE2 MOVE-instructie vereist dat de data in het geheugen gealigneerd zijn op 16 Byte grenzen. Hoe dit opgelost is voor de code van de encoder is ook in het volgend hoofdstuk te lezen. 15

25 Figuur 3.3: SIMD-instructie Figuur 3.4: Intel Pentium 4 SSE2 uitvoeringsomgeving 16

26 Hoofdstuk 4 Optimalisaties 4.1 Optimalisaties in C-code Alignatie data op 16 Byte grenzen Een van de eenvoudigste problemen was het aligneren van data op 16 Byte grenzen. Dit kan eenvoudig opgelost worden door 15 Bytes meer toe te wijzen dan nodig en daarna een nieuwe pointer laten verwijzen naar het eerste adres dat een veelvoud van 16 is. Om later het geheugen nog vrij te kunnen geven, moet zeker de eerste pointer bijgehouden worden. In het voorbeeld wordt weergegeven hoe het geheugen voor een matrix gealingneerd kan toegewezen worden. void matrix_alloc16(byte ** matrix,byte * matrix16,int row, int col) { BYTE *imptr; int i; matrix = (BYTE **)calloc(row,sizeof(byte *)); matrix16 = (BYTE*)calloc(row*col+15,sizeof(BYTE)); if (matrix16 == NULL) { printf("\nno memory in matrix allocate."); exit(-1); } imptr = matrix16 + (((int)matrix16) % 16); for (i = 0; i<row; ++i, imptr += col) matrix[i] = imptr; } 17

27 4.1.2 Rand rond beelden Zoals reeds eerder aangegeven, wordt voor macroblokken aan de rand van het beeld de zoekruimte aangevuld met randpixels, zoals in Figuur 4.1. In de originele code werd dit bekomen door gebruik te maken van volgende macro die de waarde van x satureert op de opgegeven onder- en bovengrens. SATURATE(x, lower, upper) (((x)<= (lower))? (lower) : (((x)>=(upper))?(upper):(x))) Omdat dit problemen geeft bij het in parallel berekenen van de SAD-waarde (zie verder), zorg ik ervoor dat de referentiebeelden met deze rand uitgebreid worden vooraleer met de bewegingsschatting begonnen wordt. samen met hun geïnterpoleerde beelden geeft dit de volgende C-code: Voor de referentiebeelden int border = search_range; //grootte van de rand int iref,rowshift,colshift,i,j; int row_b = frows + 2*border; int col_b = fcols + 2*border; for (iref=0; iref<total_refs;iref++) //aantal referentiebeelden for (rowshift=0;rowshift<interp;rowshift++) //aantal genterpoleerde beelden vertikaal for (colshift=0;colshift<interp;colshift++) //en horizontaal for (i=0;i<row_b;i++) for (j=0;j<col_b;j++) ref_frame_b[iref][rowshift][colshift][i][j] = ref_frame[iref][rowshift][colshift] [SATURATE(i-border,0,frows-1)] [SATURATE(j-border,0,fcols-1)]; Hypothese 2 bij bewegingsschatting Om te bepalen met welke referentieblok het gemiddelde genomen moest worden voor het bepalen van de bewegingsvectoren voor hypothese 2, werd volgende constructie gebruikt in de originele code: 18

28 Figuur 4.1: Origineel beeld met rand errond for (hyp_no=0; hyp_no<max_hypothesis; hyp_no++) { // For all the possible hypotheses for (hyp=0; hyp<=hyp_no; hyp++) { // iterate to modify the vectors of all the existing hypotheses... //The prev. hypotheses of the current hypothesis estimation for (hyp_i=0; hyp_i<hyp; hyp_i++)... // The next hypotheses for (hyp_i=hyp+1; hyp_i<=hyp_no; hyp_i++)... } } Echter indien er geweten is dat MAX HYPOTHESIS altijd 2 is dan kan deze ingewikkelde constructie vervangen worden door een simpele if-instructie. Indien hyp no gelijk is aan 0 dan is hyp ook 0 en worden beide binnenste for-lussen niet uitgevoerd. 19

29 Enkel indien hyp no gelijk is aan 1 worden ze uitgevoerd waarbij de tweede for-lus uitgevoerd wordt wanneer hyp gelijk is aan 0 en de eerste for-lus uitgevoerd wordt wanneer hyp gelijk is aan 1. Dit geeft dan volgende code. for (hyp_no=0; hyp_no<max_hypothesis; hyp_no++) { // For all the possible hypotheses for (hyp=0; hyp<=hyp_no; hyp++) { // iterate to modify the vectors of all the existing hypotheses... if(hyp_no) // (hyp_no-hyp) gebruiken waar vroeger hyp_i stond... } } 4.2 Optimalisaties in assembler Voor de optimalisaties in assembler-code maak ik gebruik van de mogelijkheid van de GCC-compiler om inline-assembler-code te gebruiken. Dit wil zeggen dat enkel voor de tijdskritische delen de C-code vervangen wordt door assembler-instructies. De assembler-instructies kunnen met de functie asm(... ) tussen gewone C-code geplaatst worden[2] Berekening SAD-waarde Voor de berekening van de SAD-waarde bevat de instructieset van Intel Pentium 4 volgende instructie: PSADBW[6]. In Figuur 4.2 wordt aangegeven hoe de instructie werkt. Het resultaat bij gebruik van MMX-registers komt in het minst beduidende woord terecht en kan via de MOVD-instructie, die een dubbel-woord verplaatst, naar een van de algemene registers gekopieerd worden daar alle overige Woorden in het doel-mmx-register een nul bevatten. Voor XMM-registers is de situatie iets ingewikkelder omdat daar de SAD-waarde van de laagste 8 Bytes in het 1 ste Woord terecht komt en de SAD-waarde van de hoogste 8 Bytes in het 5 de Woord terecht komt. Om de uiteindelijke SAD-waarde te bekomen heb ik ervoor gekozen het 2 de quad-woord naar het 1 ste quad-woord van een nieuw XMM-register te kopiëren en daarna de som van beide te nemen, waarna het uiteindelijke resultaat wederom met de MOVD-instructie naar een algemeen register gekopieerd kan worden omdat de 20

30 Figuur 4.2: PSADBW-instructie bij gebruik met MMX-registers hoogste 16 bits van het 1 ste dubbel-woord slechts een nul bevatten. Dit levert dan volgende inline assembler-code, waarbij %0 het algemene register aanduidt en de AT&T-syntax gebruikt wordt. PSADBW %xmm0, %xmm1 MOVHLPS %xmm1, %xmm2 PADDUSW %xmm2, %xmm1 MOVD %xmm1, % Verwerking 4x4-blok Bij de bewegingsschatting van het gesubsampelde beeld worden voor de sub-macroblokken blokken van 4 op 4 pixels vergeleken. Om hiervan de SAD-waarde te berekenen lezen we de 1 ste rij van 4 pixels in in een XMM-register en door de 128 bits te verschuiven over 4 Bytes naar links kunnen we dit register combineren met het register waarin de 2 de rij ingelezen is via de POR-instructie, die een bitsgewijze logische OF uitvoerd. Dit kunnen we dan herhalen voor de volgende rijen. In assembler-code ziet dit er als volgt uit. Hierbij bevatten %1 en %2 de adressen van het huidige macroblok en het referentie-macroblok. %3 en %4 bevatten de rijlengte van de matrix die het huidige en het referentiebeeld bevat. %0 is het algemene register. 21

31 MOVD (%1), %xmm1 //rij 1 huidig beeld PSLLDQ $4, %xmm1 //verschuiven over 4 Bytes naar links MOVD (%1,%3,1), %xmm2 //rij 2 huidig beeld POR %xmm2, %xmm1 LEAL (%1,%3,2), %eax //adres volgende rij MOVD (%2), %xmm3 //rij 1 ref.-beeld PSLLDQ $4, %xmm3 MOVD (%2,%4,1), %xmm4 //rij 2 ref.-beeld POR %xmm4, %xmm3 LEAL (%2,%4,2), %edx //adres volgende rij PSLLDQ $8, %xmm1 MOVD (%eax), %xmm2 //rij 3 huidig beeld PSLLDQ $4, %xmm2 MOVD (%eax,%3,1), %xmm4 //rij 4 huidig beeld POR %xmm4, %xmm2 PSLLDQ $8, %xmm3 MOVD (%edx), %xmm5 //rij 3 ref.-beeld PSLLDQ $4, %xmm5 MOVD (%edx,%4,1), %xmm6 //rij 4 ref.-beeld POR %xmm6, %xmm5 POR %xmm2, %xmm1 //rijen huidig beeld samenvoegen POR %xmm5, %xmm3 //rijen ref.-beeld samenvoegen PSADBW %xmm3, %xmm1 //SAD-waarde MOVHLPS %xmm1, %xmm2 PADDUSW %xmm2, %xmm1 MOVD %xmm1, % Berekening van gemiddelde bij Hypothese 2 Bij het bepalen van de bewegingsvectoren voor hypothese 2 moet het gemiddelde bepaald worden vooraleer de SAD-waarde berekend kan worden. Voor de berekening van het gemiddelde kan er echter geen gebruik gemaakt worden van packed Bytes (Bytes in XMM of MMX register) omdat er 22

32 Figuur 4.3: PUNPCKLBW-instructie geen deling en geen shift right bestaat voor packed Bytes bij het optellen van 2 Bytes veel kans bestaat op overflow Zelfs door gebruik te maken gesatureerd optellen, waarbij bij overflow de bovengrens van het data-type genomen wordt (in dit geval 255), bekomt men nog steeds een verkeerd resultaat indien men de deling door 2 zou kunnen uitvoeren. Neem bijvoorbeeld het gemiddelde van 255 en 255. Het correcte resultaat is 255, werkt met met gesatureerd optellen voor Bytes dan bekomt men 127 omdat de som van 255 en 255 als uitkomst 255 heeft. Er moet dus een andere manier gevonden worden om het gemiddelde te bepalen. De oplossing bestaat erin om de Bytes om te zetten naar Woorden, hierop de bewerkingen toe te passen en daarna de Woorden terug om te zetten naar Bytes daar de PSADBW-instructie voor de berekening van de SAD-waarde enkel met packed Bytes kan werken. De omzetting van Byte naar Woord gebeurt met de PUNPCKLBWinstructie[6]. Als men als bronregister een register met allemaal nullen neemt, dan kunnen de 4 of 8 laagste Bytes van het doelregister omgezet worden naar Woorden door elk Byte door een Byte met nullen vooraf te laten gaan zoals weergegeven in Figuur 4.3. Voor de omzetting van de hoogste 4 of 8 Bytes kan de PUNPCKHBWinstructie gebruikt worden. Deze doet hetzelfde als de PUNPCKLBW-instructie met als enig verschil dat de hoogste Bytes van het doelregister naar Woorden omgezet worden. Eens de Bytes omgezet zijn naar Woorden kunnen de Woorden gesatureerd opgeteld worden met de PADDUSW-instructie, waarna de deling door 2 uitgevoerd kan worden door elk woord over 1 bit naar rechts te verschuiven met de PSRLWinstructie, waarna de Woorden terug omgezet dienen te worden naar Bytes om de SAD-waarde te berekenen. Deze omzetting kan met de PACKUSWB-instructie[6] 23

33 Figuur 4.4: PACKUSW-instructie die 4 of 8 gehele Woorden (signed integers) omzet naar 4 of 8 natuurlijke Bytes (unsigned Bytes) door gebruik te maken van saturatie. Omdat na optelling van de Woorden getallen ontstaan van maximaal 9 bits lang (som van 2 Bytes resulteert in 9 bits) en dus na het verschuiven naar rechts de getallen nog maximaal 8 bits lang zijn, is er geen probleem bij het omzetten van de Woorden naar Bytes daar de hoogste 8 bits van een Woord steeds nul zullen zijn. De omzetting wordt geïllustreerd in Figuur 4.4. Merk op dat de Woorden van het doelregister op de laagste Bytes en de Woorden van het bronregister op de hoogste Bytes terecht komen. Voor de berekening van de SAD-waarde voor 2 rijen uit een 8x8-sub-macroblok bekomen we dan volgende assembler-code. %0, %1 en %2 bevatten respectievelijk de adressen van het huidige sub-macroblok en van de referentie-sub-macroblokken. %3 en %4 bevatten de rijlengte van de matrix die het huidige en het referentiebeeld bevat. %0 is het algemene register waarin de uiteindelijke SAD-waarde terechtkomt. PXOR %xmm0, %xmm0 //XMM0 op nul zetten MOVQ (%0), %xmm1 //1ste rij huidig beeld MOVQ (%1), %xmm2 //1ste rij ref. beeld 1 PUNPCKLBW %xmm0, %xmm2 //lage Bytes -> Woorden MOVQ (%2), %xmm3 //1ste rij ref. beeld 2 PUNPCKLBW %xmm0, %xmm3 //lage Bytes -> Woorden PADDUSW %xmm3, %xmm2 //Woorden optellen MOVQ (%0,%3,1), %xmm4 //2de rij huidig beeld PSRLW $1, %xmm2 //Woorden delen dr. 2 MOVQ (%1,%4,1), %xmm5 //2de rij ref. beeld 1 PUNPCKLBW %xmm0, %xmm5 //lage Bytes -> Woorden MOVQ (%2,%4,1), %xmm6 //2de rij ref. beeld 2 PUNPCKLBW %xmm0, %xmm6 //lage Bytes -> Woorden PADDUSW %xmm6, %xmm5 //Woorden optellen PSLLDQ $8, %xmm4 //2de rij huidig beeld 24

34 //over 64 bits nr. links //verschuiven PSRLW $1, %xmm5 //Woorden delen dr. 2 PACKUSWB %xmm5, %xmm2 //Woorden -> Bytes POR %xmm4, %xmm1 //rijen huidig beeld //samenvoegen PSADBW %xmm2, %xmm1 //SAD-waarde MOVHLPS %xmm1, %xmm0 PADDUSW %xmm1, %xmm0 MOVD %xmm0, % Gebruik van accumulator Om te voorkomen dat voor elke iteratie waarin de SAD-waarde van 1 of 2 rijen van een macroblok berekend wordt, deze waarde ook nog eens opgeteld wordt bij de sum-variabele zoals dit oorspronkelijk gebeurde, wordt de SAD-waarde voor elke iteratie opgeteld bij een accumulator-register en wordt de uiteindelijke SAD-waarde pas na alle iteraties weggeschreven naar de sum-variabele. Voor de berekening van de SAD-waarde voor 8x8-macroblokken levert dit een besparing van 2 MOVE-instructies per iteratie, zoals duidelijk wordt uit volgend voorbeeld. Hierin is het MM0-register het accumulator-register dat eerst op nul gezet wordt. Indien geen accumulator-register gebruikt zou worden dan moet de sum-variabele ingelezen worden, de SAD-waarde erbij optellen en daarna terug wegschrijven naar de sum-variabele. Dit zou 2 instructies per iteratie meer opleveren, daar het optellen nog steeds moet gebeuren. asm("pxor %%mm0,%%mm0":); for(inblock_i = 0; inblock_i < 8; inblock_i+=2) { asm ( "MOVQ (%0),%%mm1 \n\t" //rij 1 "PSHUFW $0xE4,(%1),%%mm2 \n\t" "PSADBW %%mm2,%%mm1 \n\t" "MOVQ (%0,%2,1),%%mm3 \n\t" //rij 2 "PSHUFW $0xE4,(%1,%3,1),%%mm4 \n\t" "PSADBW %%mm4,%%mm3 \n\t" "PADDUSW %%mm3,%%mm1 \n\t" "PADDUSW %%mm1,%%mm0 \n\t" : 25

35 :"r" (&curr_frame[block.br+inblock_i][block.bc]), "r" (&ref_frame_b[search_di+inblock_i][search_dj]), "r" (fcols), "r" (col_b) ); } asm("movd %%mm0,%0" :"=r" (sum) ); In bovenstaand voorbeeld wordt de PSHUFW-instructie gebruikt ipv. de MOVQinstructie om een rij van 8 Bytes in te lezen. Dit is gedaan om zoveel mogelijk parallellisme te bekomen. De PSHUFW-instructie maakt namelijk gebruik van een andere verwerkingseenheid dan de MOVQ-instructie (zie vorig hoofdstuk) en in het beste geval levert dit een wachttijd (latency) die de helft is van de wachttijd die men bekomt bij het gebruik van 2 opeenvolgende MOVQ-instructies. Voor de berekenig van de SAD-waarde voor 16x16-macroblokken worden er zelfs 3 MOVE-instructies en 1 ADD-instructie bespaard per iteratie, omdat het voor elke iteratie niet meer nodig is om de SAD-waarde van de hoogste Bytes op te tellen bij de SAD-waarde van de laagste Bytes. Dit hoeft nu enkel nog te gebeuren na de laatste iteratie, zoals in volgend voorbeeld aangegeven wordt. Hierbij is het huidige beeld op 16 Byte grenzen gealigneerd en is het XMM0-register het accumulator-register. asm( "PXOR %%xmm0,%%xmm0" :); for(inblock_i = 0; inblock_i < 16; inblock_i++) { asm( "MOVQ 8(%1),%%xmm1 \n\t" "PSLLDQ $8,%%xmm1 \n\t" "MOVQ (%1),%%xmm2 \n\t" "POR %%xmm2,%%xmm1 \n\t" "PSADBW %0,%%xmm1 \n\t" "PADDUSW %%xmm1,%%xmm0" : :"m" (curr_frame[block.br+inblock_i][block.bc]), "r" (&ref_frame_b[search_di+inblock_i][search_dj]) ); } 26

36 asm( "MOVHLPS %%xmm0,%%xmm1 \n\t" "PADDUSW %%xmm1,%%xmm0 \n\t" "MOVD %%xmm0,%0" :"=r" (sum) ); Inlezen niet-gealigneerde data Zelfs wanneer de referentiebeelden op 16 Byte grenzen gealigneerd zijn, moeten we bij het vergelijken van 16x16-macroblokken nog steeds niet-gealigneerd inlezen omdat 15 van de 16 keer het begin van een 16x16-blok niet op een 16 Byte grens begint. Omdat niet-gealigneerd inlezen veel trager gebeurd dan gealigneerd inlezen, moet er hiervoor een oplossing gevonden worden. Een eerste mogelijkheid zou zijn om 2 aangrenzende gealigneerde rijen van 16 Bytes in te lezen en daarvan het gewenste deel te extraheren door het verschuiven naar links en rechts van de rijen en deze dan te combineren. Dit is echter niet mogelijk omdat de PSLLDQ of PSLRDQ een XMM-register slechts over een constant aantal posities kan verschuiven[6] en dit aantal posities op voorhand niet geweten is. De tweede optie is om met behulp van de MOVQ-instructie de laatste 8 Bytes van de rij in te lezen, het XMM-register over 8 Bytes naar links verschuiven met behulp van de PSLLDQ-instructie en dan dit register te combineren met het register dat de eerste 8 Bytes van de rij bevat via de POR-instructie. Deze manier van werken wordt geïllustreerd in het bovenstaande voorbeeld. Door op deze wijze een rij van 16 Bytes in te lezen verhelpen we een ander probleem, namelijk de vertraging die optreedt indien de in te lezen Bytes over de grenzen van een cachelijn lopen[8]. In de veronderstelling van een uniforme verdeling van de bewegingsvectoren dan zou deze vertraging gemiddeld 1/4 van de tijd optreden. Door slechts met 8 Bytes per keer in te lezen wordt deze kans met de helft verlaagd tot 1/8 wederom in de veronderstelling van een uniforme verdeling. Er zou natuurlijk getest kunnen worden op de positie van de 8 Bytes tov. 64 Byte grenzen, maar gezien de lage kans van optreden zou dit enkel extra sprong-instructies met zich meebrengen en tegelijkertijd de extra vertragingen opgeleverd door verkeerde sprongvoorspellingen. 27

37 Hoofdstuk 5 Conclusie 5.1 Profilering geoptimaliseerde code Passen we de in het vorige hoofdstuk beschreven optimalisaties toe dan bekomen we de profileringsresultaten uit tabel 5.1 voor de encodering van 1 GOP van qcifbeelden. Deze encodering nam seconden in beslag. In vergelijking met de originele code is dit een versnelling van een factor 3 voor de encodering van de GOP en een versnelling van een factor 6 voor de full search-functie. De versnelling van de full search komt benaderd de beoogde versnelling, maar is nog ruim onvoldoende om een encodering in reële tijd te verkrijgen. Hiervoor moeten andere delen van de encoder nog verder bestudeerd worden. Verder moet opgemerkt worden dat de gebruikte methode van bewegingsschatting niet de meest geschikte is. Door het onregelmatige zoekpatroon wordt heel wat tijd besteedt aan de adresberekening van de blokken in de zoekruimtes van de referentiebeelden. Een regelmatiger zoekpatroon, zoals bijvoorbeeld een volledige zoektocht in een beperkte zoekruimte rond het te schatten macroblok, zou waarschijnlijk een snellere en toch even goede bewegingsschatting op leveren. Voor meer informatie hieromtrent verwijs ik naar het eindwerk van Peter Bertels[1]. 5.2 Mogelijke uitbreidingen Om het gegeven zoek-algoritme nog verder te versnellen, bestaan er nog een te onderzoeken mogelijkheden: 28

38 % tijd cumulatief # sec. # sec. functie full search(... ) Interpolate frame int(... ) max valid partition(... ) prune mb(... ) ME(... ) rate est(... ) overige functies Tabel 5.1: Profilering geoptimaliseerde code gebruik maken van de HyperThreading-technologie van de nieuwste Intel Pentium 4 processoren. Met behulp van HyperThreading wordt een dual-processor systeem gesimuleerd waardoor in het beste geval een versnelling van een factor 2 bekomen wordt. Aangezien het vergelijken van de macroblokken uit de referentiebeelden onafhankelijk van elkaar kan gebeuren, zou het toepassen van HyperThreading zeker een snelheidswinst opleveren. de nieuwste Intel Pentium 4 processoren ondersteunen ook SSE3-instructies, waarin misschien nog enkele instructies aanwezig zijn die nog een extra snelheidswinst kunnen opleveren het cache-gedrag van de code onderzoeken met behulp van geavanceerde analyse-programma s zoals bijvoorbeeld Intel VTune. 29

39 Bijlage A Broncode Voor de broncode van de originele en geoptimaliseerde wavelet video-codec verwijs ik naar de bijgevoegde CD-ROM, waarop ook nog dit eindwerk te vinden is. 30

40 Bibliografie [1] P. Bertels. Hardware-ontwerp van een bewegingsschatter voor video-compressie, [2] Clark L. Coleman. Using inline assembly with gcc. 20 [3] M. D Haene. Het ontwerpen van entropie-encodering op fpga als onderdeel van een wavelet-gebaseerde video-encoder, [4] I. Doms. Het ontwerpen van temporele en spatiale wavelet-transformaties op fpga als onderdeel van een wavelet-gebaseerde video encoder, [5] IA-32 Intel Architecture - Software Developer s Manual Volume 1: Basic Architecture Order number: [6] IA-32 Intel Architecture - Software Developer s Manual Volume 2: Instruction Set Reference Order number: , 23, 27 [7] IA-32 Intel Architecture Optimization - Reference Manual Order number: [8] Using Streaming SIMD Extensions in a Motion Estimation Algorithm for MPEG Encoding Version 1.2, Order number: [9] H. Devos H. Eeckhaut M. Christiaens F. Verdicchio D. Stroobandt and P. Schelkens. Performance requirements for reconfigurable hardware for a scalable wavelet video decoder. Ghent University, ELIS and Vrije Universiteit Brussel, ETRO. 1