Analyse van pixelgroepering en antiblokfiltering in een GPU-gedreven H.264/AVC-decoder

Transcriptie

1 Faculteit Ingenieurswetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. J. Van Campenhout Analyse van pixelgroepering en antiblokfiltering in een GPU-gedreven H.264/AVC-decoder door Pascal Torfs Promotor: prof. dr. ir. R. Van de Walle Thesisbegeleiders: lic. B. Pieters, lic. D. Van Rijsselbergen, dr. lic. W. De Neve Afstudeerwerk ingediend tot het behalen van de graad van Licentiaat in de Informatica Academiejaar

2 Dankwoord Een aantal mensen hebben een onmiskenbare bijdrage geleverd tot het voltooien van mijn thesis. Bij deze zou ik hen dan ook willen bedanken. Eerst en vooral wil ik mijn promotor prof. dr. ir. Rik Van de Walle bedanken voor mij de kans te geven om dit onderzoek uit te voeren. Mijn dank gaat ook uit naar mijn begeleiders Bart Pieters, Dieter Van Rijsselbergen en Wesley De Neve voor de vele uren die ze voor me hebben vrijgemaakt, zelfs tijdens de weekends. Ik zou ook mijn familie en vrienden willen bedanken voor hun steun en begrip. i

3 Toelating tot bruikleen De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie 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 deze scriptie. Pascal Torfs, 13 augustus 2007 ii

4 Analyse van pixelgroepering en antiblokfiltering in een GPU-gedreven H.264/AVC-decoder door Pascal Torfs Afstudeerwerk ingediend tot het behalen van de graad van Licentiaat in de Informatica Academiejaar Universiteit Gent Faculteit Ingenieurswetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. J. Van Campenhout Promotor: prof. dr. ir. R. Van de Walle Thesisbegeleider: lic. B. Pieters, lic. D. Van Rijsselbergen, dr. lic. W. De Neve Samenvatting In dit eindwerk wordt een bestaande GPU-gedreven decoder geoptimaliseerd met een techniek genaamd pixelgroepering. Door gebruik te maken van deze techniek wordt het gebruik van het videogeheugen gereduceerd. De decoder met pixelgroepering wordt vergeleken met de originele decoder om de omvang van de prestatiewinst te bepalen. Daarnaast wordt de bestaande encoder uitgebreid met de antiblokfilter gedefinieerd in de H.264/AVC-videodecoderingsstandaard. De filter wordt eveneens op de GPU uitgevoerd zodat uiteindelijk bewegingscompensatie, reconstructie, antiblokfiltering, kleurenruimteconversie en visualisatie door de GPU afgehandeld worden terwijl entropiecodering, quantisatie en de inverse transformatie op de CPU worden uitgevoerd. De uitgebreide decoder wordt vervolgens vergeleken met de decoder zonder de antiblokfilter. Op basis van deze vergelijking wordt vastgesteld dat de antiblokfilter zich niet leent tot een efficiënte implementatie op de GPU. Trefwoorden: antiblokfilter, bewegingscompensatie, Direct3D, GPU, H264/AVC, pixelgroepering, shaders iii

5 Analysis of Pixel Packing and Deblocking in a GPU-accelerated H.264/AVC-decoder Pascal Torfs Supervisor(s): B. Pieters, D. Van Rijsselbergen, W. De Neve, and R. Van de Walle Abstract In a paper by B. Pieters, the motion compensation, reconstruction and color space conversion from the H.264/AVC standard was implemented on the GPU. The paper included a suggestion to increase performance by using a technique called pixel packing. This technique was evaluated and implemented up to half sample precision providing a decoding speed increase when decoding high resolution video. The deblocking filter used in H.264/AVC, one of the most computationally intensive phases of the decoding process was also integrated into this decoder and it s performance was evaluated. Keywords GPU, shaders, H.264/AVC, pixel packing, deblocking I. INTRODUCTION STREAMING of multimedia is getting more and more commonplace. Several online services offer video on demand to a wide user base generating immense bandwidth usage. In order to reduce this bandwidth, it is important for these media to be encoded at low bitrates without compromising visual quality. The H.264/AVC standard provides a deblocking filter which can be used to increase visual quality while still maintaining low bitrate. The H.264/AVC decoding process and the deblocking filter in particular is computationally intensive to say the least. In [1] a decoder was developed making use of the GPU to offload the H.264/AVC motion compensation, reconstruction, and color space conversion phases, allowing realtime video decoding with minimal CPU usage. This paper discusses two topics related to this GPU-driven decoder. First a suggestion, made in the original paper, for a technique called pixel packing was explored to increase performance of the decoder when dealing with high resolution video. In the second part of this paper, a GPU-accelerated deblocking filter was implemented and integrated into the decoder. II. PIXEL PACKING The decoder uses 32 bit textures to perform motion compensation, reconstruction, and to store the decoded images in the image buffer. While assigning one 8 bit sample to each 32 bit texture element allows for a straightforward implementation of the motion compensation phase, only eight out of the 32 bits per texel are used. By storing four samples in each texel the pixels are packed as shown in Figure 1. Reducing the size of the textures used in motion compensation results in a reduction of video memory usage. In turn, this effectively reduces the number of shader evaluations and memory bandwidth. A. Implementation By using the SIMD architecture of the shader machines, four samples are motion compensated in roughly the same time as in the original decoder. Extra processing time is required for two problems that arise. First, when retrieving a sequence of four samples from the pixel packed texture the sample sequence can be packed in just one texel or in a pair of texels. The second issue concerns retrieving samples that are beyond the edges of a picture. The H.264/AVC standard defines that those samples are equal to the nearest edge sample. In the original decoder this was implemented using Direct3D clamp texture addressing mode. In the case of pixel packing this no longer works. Instead of returning the nearest edge sample, the nearest texel holding four different samples is returned. B. Results After solving these issues, the decoder with pixel packing was compared to the original decoder. For this test, a PC with an Intel Pentium D 2.8Ghz CPU and an NVIDIA GeForce 7800 GTX GPU was used. The results are shown in Table I. TABLE I PIXEL PACKING PERFORMANCE RESULTS (FPS) Resolution Original decoder Decoder with pixel packing 720x x x x For high resolution video the use of pixel packing resulted in an increase of decoding speed with a factor of up to The technique proved to be a performance drain for lower resolution video, but the decoder with pixel packing still manages to decode all sequences except the 2048x2048 sequence in realtime. The original decoder failed to do this for 1920x1080 and higher. Pixel Packing Fig. 1. Pixel packing of four samples into one texel Texel Sample III. DEBLOCKING FILTER In the second part of the thesis the deblocking filter defined in the H.264/AVC standard was implemented on the GPU and integrated in the original decoder in an attempt to offload this proces from the CPU. The H.264/AVC deblocking filter is an inloop filter as opposed to a postprocessing filter. The filter is

6 applied to an image after the reconstruction phase and before it is added to the image buffer. The process for luminance samples works by filtering the edges of 4x4 blocks. The filter s strength for a given edge is based on the average quantization parameter between the edge s neighboring blocks and a boundary strength parameter. All 16x16 macroblocks are filtered in raster scan order and for each macroblock the left vertical edge is filtered horizontally followed by the three internal edges from left to right. Next, the top edge of the macroblock is filtered vertically followed by the three internal edges from top to bottom. Filtering for chrominance samples is similar. The filtering occurs in place, meaning that when an edge is filtered it can use the already filtered results of previous edges. The GPU on the other hand is a stream processor. It processes a stream of data with many small processors at high speed. A major drawback is that these shaders cannot communicate with each other. The data that is output by the shaders cannot be read by them during a single render pass. So whenever a sample that may have been filtered already has to be read, a new render pass will be necessary. The source and destination streams will need to be kept synchronized. The deblocking filter was analyzed for dependencies to determine edges that can be processed in parallel. A. Dependencies One of the main properties of slices is that they can be decoded separately. This is not true for the deblocking process Rand A Rand B when the disable deblocking filter idc flag is set to 0. The flag Samples gelezen can be set to 2 to preserve separate decoding without door drift rand A or to 1 to disable filtering altogether. Samples aangepast door rand B A dependency exists between neighboring macroblocks. Samples can be read from neighboring macroblocks and samples from neighboring macroblocks can also be filtered as shown on Figure 2. Each macroblock will require up to date information on the macroblocks it reads from. At the edge level, the horizontal edges cannot be filtered before filtering of the vertical edges is completed. And an edge cannot be filtered before filtering of the previous edge has finished as illustrated in Figure 2. Filtered edge Read samples Filtered samples Fig. 2. Extent of the samples being read and written during filtering of an edge B. Implementation For each of the dependencies identified in Section III-A a separate rendering pass will be necessary and often an extra pass will be required to ensure synchronization between source and target textures. A few optimizations were made. In 75% of the cases synchronization was done parallel to the filtering process. When filtering slices that are not intracoded, shaders do not require the ability to filter edges with boundary strength three or four. The filtering of the Cb and Cr color channels was done in parallel reducing the number of render passes. Despite these optimizations the number of required render passes remains high. For example, an image with a resolution as low as 176x144 requires 1386 render passes to be filtered. This results in a high number of DirectX API calls which in turn results in a high CPU cost. C. Results The filter was tested for three videosequences on a machine with an Intel Pentium D 2.8 Ghz CPU and an NVIDIA GeForce 7800 GTX GPU. The performance was compared to a PC with a faster CPU, an Intel Core 2 Duo 2.4 Ghz, and a slower GPU, an NVIDIA GeForce 7600 GS, as shown in Table II. TABLE II DEBLOCKING PERFORMANCE RESULTS (FPS) Resolution without deblocking with deblocking 720x Pentium D 352x x x Core 2 Duo 352x x From these results the effect of a faster CPU in processing the high number of API calls is apparent. The Core 2 Duo renders the QCIF sequence in realtime but the goal of offloading the filtering process from the CPU was not met. IV. CONCLUSIONS While successfully optimizing the decoder by applying pixel packing to the motion compensation and reconstruction phases, the expansion of the decoder with a deblocking filter on the GPU was not so successful. The use of pixel packing decreases the use of video memory and bandwidth resulting in a performance gain when decoding high definition video (57% faster decoding at 1080p). The deblocking filter manages to render a video sequence of 176x144 in realtime but a powerful CPU is required. Due to the nature of the deblocking filter the GPU does not provide a means to efficiently perform deblocking of this sort. ACKNOWLEDGMENTS The author would like to thank R. Van de Walle for the opportunity to do this research, as well as Bart Pieters, Dieter Van Rijsselbergen, and Wesley De Neve for their support. REFERENCES [1] Bart Pieters, Motion Compensation and Reconstruction of H.264/AVCcoded Pictures using the GPU, M.S. thesis, Ghent University, 2006.

7 Inhoudsopgave 1 Inleiding Het beoogde doel Overzicht De GPU-gedreven H.264/AVC-decoder Werking van de decoder Bewegingscompensatie Reconstructie Overbemonstering, kleurenruimteconversie en visualisatie Pixelgroepering Conclusie Pixelgroepering bij bewegingsgecompenseerde texturen Bovenlimiet voor prestatiewinst Texturen Shaders Resultaten Bandbreedte-analyse Architectuur Pixelselectie Randcorrectie Shaders Resultaten Conclusie vi

8 4 Antiblokfiltering in de H.264/AVC-standaard Quantisatie Filtering in de decodeerlus Antiblokfilter in de H.264/AVC-standaard De randsterkte Het filterproces Conclusie Antiblokfiltering op de GPU Randsterkte Filteren Afhankelijkheden Architectuur Luminantiefilter Chrominantiefilter Optimalisaties Resultaten Conclusie Conclusies 53 A Testopstelling 55 A.1 Hardware A.2 Software B Inhoud DVD 57 C Shadercode 58 C.1 Pixelgroepering C.2 Antiblokfilter Bibliografie 71 vii

9 Lijst van figuren 2.1 Pixelgroepering De GPU-gedreven H.264/AVC-decoder Verband tussen het vertexrooster en het referentiebeeld Locatie van vol-, half- en kwartprecisiepixels ten opzichte van elkaar Schematische voorstelling van een renderstap bij bewegingscompensatie Selectie van submacroblokpartities door de vertexshader Halfprecisie-interpolatie Kwartprecisie-interpolatie Textuurbenutting bij pixelgroepering Opvraging van pixels uit texels bij volpixelprecisie Opvraging van pixels uit texels en interpolering voor verticale halfpixelprecisie Opvraging van pixels uit texels en interpolering voor horizontale halfpixelprecisie Opvraging van pixels uit texels en interpolering voor middelste halfpixelprecisie Performantie van de originele architectuur tegenover de testarchitectuur Procentuele prestatiewinst van pixelgroepering ten opzichte van de originele architectuur Beeldsnelheid bij pixelgroepering Effect van de quantisatieparameter op een beeld Decoder met een postprocessing -antiblokfilter Decoder met een antiblokfilter in de decodeerlus Effect van de antiblokfilter op een beeld Gefilterde randen van een macroblok viii

10 4.6 Pixelwaarden langs beide kanten van een rand Het stroommodel Afhankelijkheid tussen opeenvolgende randen bij luminantiefiltering Afhankelijkheid tussen opeenvolgende randen bij chrominantiefiltering Aangepaste en Gelezen pixels bij het filteren van een macroblok Filteren en kopiëren van een rand op de GPU Filteren en kopiëren van een rand in één stap Projectering van quad op een rand voor luminantiefiltering Projectering van twee quads op een macroblok voor chrominantiefiltering Beeldsnelheid van de antiblokfilter op de twee testmachines Invloed van de antiblokfilter op de beeldsnelheid van de twee testmachines 52 ix

11 Lijst van tabellen 2.1 Aantal instructies van de verschillende shaders Aantal textuuropvragingen bij originele architectuur en pixelgroepering Procentuele pixelverdeling tussen de verschillende shaders Bandbreedtegebruik bij bewegingscompensatie voor de verschillende videosequenties Aantal instructies bij originele architectuur en pixelgroepering Totaal aantal renderiteraties bij het filteren van een beeld x

12 Hoofdstuk 1 Inleiding Het stromen van multimediale data is tegenwoordig niet meer weg te denken. Verscheidene online diensten bieden massaal video-op-aanvraag aan (denk maar aan YouTube, Google Video maar ook TV-zenders zoals de BBC), wat gepaard gaat met een enorm verbruik aan bandbreedte. Daarom is het belangrijk dat de bitsnelheid van de gestroomde beelden zo laag mogelijk is, en dit zodanig dat de perceptuele kwaliteit van deze beelden toch aanvaardbaar blijft. In Mei 2003 werd de eerste versie van de H.264/AVC-standaard [1] voorgesteld. Deze videodecoderingsstandaard levert een verhoogde compressie ten opzichte van zijn voorgangers en biedt een antiblokfilter aan om de blokartefacten die optreden bij beelden die met hoge compressie gecodeerd werden te maskeren. Antiblokfiltering is helaas een vrij rekenintensief proces dat tot een derde van het decodeerproces [2] in beslag kan nemen. De hedendaagse PC heeft echter een zeer krachtige co-processor aan boord die in het verleden al voor verschillende uiteenlopende doeleinden gebruikt werd. Deze processor, de GPU, wordt gebruikt in talloze grafische technieken [3] maar werd bijvoorbeeld ook ingezet bij het oplossen van lineaire stelsels en het sorteren van data [4], in domeinen die niet direct met de GPU verbonden zijn. In het eindwerk van B. Pieters [5] werd de GPU gebruikt om een deel van het H.264/AVC-decodeerproces efficiënt op de GPU uit te voeren. Concreet werden bewegingscompensatie, reconstructie, kleurenruimteconversie en visualisatie door de GPU afgehandeld terwijl het parsen van de bitstroom, entropiecodering, quantisatie en inverse transformatie op de CPU uitgevoerd werden. Gegeven de computationele complexiteit van de antiblokfilter zou het daarom ook interessant zijn om voor de antiblokfilter de 1

13 rekenkracht van de grafische processor te bewerkstelligen. 1.1 Het beoogde doel In deze thesis wordt één van de optimalisaties die in de thesis van B. Pieters [5] vermeld werd onderzocht, namelijk pixelgroepering. Daarnaast wordt onderzocht of de antiblokfilter, zoals gedefinieerd in de H.264/AVC-standaard, efficiënt te implementeren is op de GPU. 1.2 Overzicht Deze paragraaf schetst een kort overzicht van de opbouw van deze thesis. Een hoofdstuk over de grafische pijplijn wordt niet voorzien. De lezer wordt verondersteld toch enigzins vertrouwd te zijn met de reeds ontwikkelde GPU-gedreven decoder. Daarom wordt de bespreking van de H.264/AVC-standaard ook beperkt tot relevante aspecten en wordt hiervoor geen apart hoofdstuk voorzien. Hoofdstuk 2 situeert de GPU-gedreven H.264/AVC-decoder ontworpen door B. Pieters. Een volledige uiteenzetting van de ontwikkelde decoder zou te ver leiden dus wordt de bespreking hier beperkt tot de relevante onderdelen. Voor een gedetailleerde bespreking wordt verwezen naar het eindwerk van B. Pieters [5]. Hoofdstuk 3 bespreekt pixelgroepering waarmee getracht wordt de decoder te optimaliseren. In dit hoofdstuk worden ook de implementatie van pixelgroepering en enkele experimenten besproken om een mogelijke prestatiewinst aan te tonen. In Hoofdstuk 4 wordt kort de werking van de antiblokfilter uit de H.264/AVC-standaard toegelicht. Eerst worden quantisatie en bewegingscompensatie geïdentificeerd als de oorzaak van de blokartefacten. Vervolgens wordt uiteengezet hoe de H.264/AVC-anitblokfilter deze artefacten probeert weg te filteren. Hoofdstuk 5 bespreekt de antiblokfilter zoals die werd geïmplementeerd op de GPU en de problemen die hierbij optreden. Ook wordt de prestatie van de decoder met filter vergeleken met de decoder zonder filter. Hoofdstuk 6 vat de behaalde resultaten samen en geeft enkele conclusies ter afsluiting van de thesis. 2

14 Appendices A en B geven respectievelijk een overzicht van de hard- en software die bij het testen gebruikt werd, en een overzicht van de inhoud van de DVD-ROM in bijlage. Appendix C bevat de code van de ontwikkelde shaders. 3

15 Hoofdstuk 2 De GPU-gedreven H.264/AVC-decoder In het eindwerk van Bart Pieters [5] werd de basis gelegd voor een GPU-gedreven H.264/AVCdecoder. De ontwikkelde decoder gebruikt texturen voor de intern representatie van de beelden. De beelden worden in de YCbCr-kleurenruimte verwerkt en er wordt een textuur voor elk kanaal gebruikt: één textuur voor Y, het luminantiekanaal. één textuur voor Cb, het blauwe chrominantiekanaal. één textuur voor Cr, het rode chrominantiekanaal. Een textuur is een blok geheugen dat door de GPU kan gelezen worden als een array en beschreven kan worden door middel van pixel- en textuurshaders. Er zijn ook een aantal filteroperaties en adresseringsmodi mogelijk voor texturen. Voor meer informatie wordt verwezen naar [6]. Er worden texturen met textuurelementen (texels) van 32 bit gebruikt, waarvan slechts 8 bits daadwerkelijk gebruikt worden om beeldpixels in op te slaan. Het gebruik van 32- bit-texturen heeft verschillende redenen: Op oudere hardware is het gebruik van 8-bit-texturen niet mogelijk. Het gebruik van 32-bit-texturen is doorgaans sneller dan dat van 8-bit-texturen. 4

16 De ontwikkelde decoder werd ontworpen met het oog op pixelgroepering. Pixelgroepering is een techniek waarbij een aantal pixels in één texel worden gegroepeerd zoals te zien is in Figuur 2.1. Deze techniek heet pixelgroepering (Eng. pixel packing) en werd voor het eerst voorgesteld in [7]. Texel Texel Sample Sample (a) (b) Figuur 2.1: Pixelgroepering voor vier pixels. a) Geen pixelgroepering, één texel bevat slechts één pixel. b) Pixelgroepering, in één texel worden vier pixels opgeslagen Voor de verdere bespreking wordt hier een duidelijk onderscheid tussen pixels en texels vastgelegd. Onder het begrip texel wordt een 32-bit-textuurelement verstaan ongeacht de data die het bevat. De term pixel duidt op een beeldelement van een bepaald kleurkanaal. Alvorens de implementatie van de pixelgroepering-optimalisatie in de GPU-gedreven H.264/AVC-decoder te bespreken wordt eerst de werking van de decoder kort toegelicht met het oog op pixelgroepering. 2.1 Werking van de decoder In Figuur 2.2 wordt de werking van het gedeelte van de decoder dat op de GPU wordt uitgevoerd geïllustreerd. De decoder verwerkt de beelden in de YCbCr-kleurenruimte, meer bepaald YCbCr 4:2:0 (of ook wel YUV 4:2:0 genoemd). Dit wil zeggen dat de chrominantiekanalen onderbemonsterd zijn. Voor elke vier luminantiepixels is er slechts één Cb en één Cr chrominantiepixel. De operaties worden afzonderlijk op het luminantiekanaal Y 5

17 Invoer Bewegingsvectoren Residu Eerder gedecodeerd beeld Bewegingscompensatie Bewegingsgecompenseerd beeld + Gereconstrueerd beeld Uitvoer Overbemonstering Kleurenruimteconversie Visualisatie Figuur 2.2: De GPU-gedreven H.264/AVC-decoder en de twee chrominantiekanalen Cb en Cr uitgevoerd. Zowel tussenresultaten als eerder gedecodeerde beelden worden in deze kleurenruimte bewaard met 32 bit per kleurkanaal. Eerst wordt op basis van vorige beelden en bewegingsvectoren een voorspelling van het te decoderen beeld gemaakt. Het resultaat hiervan is het bewegingsgecompenseerd beeld. Daaraan wordt een residu toegevoegd om het uiteindelijke beeld te bekomen. Dit beeld wordt dan toegevoegd aan een buffer van gedecodeerde beelden zodat het gebruikt kan worden in de decodering van volgende beelden. Ondertussen worden de chrominantiekanalen van het gedecodeerde beeld overbemonsterd en naar de RGB-kleurenruimte geconverteerd zodat het op het scherm getoond kan worden. In de decoder worden bewegingscompensatie, reconstructie met het residu, overbemonstering, kleurenruimteconversie en visualisatie volledig op de GPU uitgevoerd. Het eerste beeld in een videosequentie is altijd een intrabeeld. Bij de decodering van intrabeelden wordt geen gebruik gemaakt van eerder gedecodeerde beelden. De bewegingscompensatie wordt dus niet uitgevoerd voor intrabeelden. De H.264/AVC-standaard laat wel toe om macroblokken die intragecodeerd zijn te voorspellen op basis van reeds gedecodeerde macroblokken, maar dit is voorlopig nog niet mogelijk in de GPU-gedreven decoder. Vervolgens wordt het residu toegevoegd aan de predictie, die in dit geval een beeld is bestaande uit nullen. Een intrabeeld is dus volledig gecodeerd in het residu. 6

18 De overige beelden van een sequentie zijn P-beelden. Dit wil zeggen dat ze voorspeld worden op basis van een beeld (het referentiebeeld) dat chronologisch voor het beeld komt en een set bewegingsvectoren die de macroblokken uit dit beeld projecteren naar de juiste positie in het nieuwe beeld. Dit heet voorwaartse bewegingscompensatie. De H.264/AVC-standaard definieert naast intrabeelden en P-beelden ook nog B-beelden. Dit zijn beelden die naast voorwaartse bewegingscompensatie ook achterwaartse bewegingscompensatie ondersteund. Dit wil zeggen dat het beeld ook informatie kan bevatten uit een beeld dat chronologisch na het beeld komt. De chronologische volgorde van de beelden weerspiegelt dan ook niet de volgorde waarin beelden gecodeerd worden Bewegingscompensatie De bewegingscompensatie is de eerste stap in het decoderen van een beeld op de GPU. Het beeld wordt opgedeeld in 4x4 submacroblokpartities. Dit zijn de kleinst mogelijke eenheden waartussen bewegingsvectoren kunnen verschillen. Een vertexrooster stelt deze blokken voor zoals te zien is op de linkerhelft van Figuur 2.3. De vertices van het rooster houden de bewegingsvectoren bij voor het blok waartoe ze behoren. De bewegingsvectoren duiden de relatieve positie ten opzichte van het blok aan naar een gebied uit het referentiebeeld (Zie Figuur 2.3). Vertexrooster Referentiebeeld Figuur 2.3: Verband tussen het vertexrooster en het referentiebeeld Bewegingsvectoren worden uitgedrukt in kwartpixeleenheden. Een bewegingsvector met x-coördinaat gelijk aan vier refereert dus naar een blok pixels die één luminantiepixeleenheid rechts van de huidige pixel ligt. De rest van de bewegingsvectoren gedeeld Vertexshader Vertices Pixeldata Pixels - Bewegingsvectoren - Positie in het vertexrooster 7 - Textuurcoordinaten - Bewegingsvectorrest

19 door vier wordt berekend. Op basis van die rest worden drie types bewegingscompensatie gedefinieerd: Bij bewegingsvectoren waarbij beide coördinaten een rest gelijk aan nul hebben wordt de bewegingscompensatie volpixelprecies genoemd. Bij bewegingsvectoren waarbij de coördinaten een rest gelijk aan nul of twee hebben maar niet beide gelijk aan nul zijn wordt de bewegingscompensatie halfpixelprecies genoemd. Voor de overige bewegingsvectoren wordt de bewegingscompensatie kwartpixelprecies genoemd. Op Figuur 2.4 wordt dit nog eens geïllustreerd. Y=0 Volpixelprecisie Y=3 Halfpixelprecisie Kwartpixelprecisie Y=2 Y=1 Y=0 Rest X=0 X=1 X=2 X=3 X=0 Figuur 2.4: Locatie van vol-, half- en kwartprecisiepixels ten opzichte van elkaar De bewegingscompensatie gebeurt in zes renderstappen. Elke stap volgt het proces dat in Figuur 2.5 getoond wordt. Een vertexshader zet de vertices met bijbehorende bewegingsvectoren uit het vertexrooster om naar pixeldata. Een pixelshader gebruikt die data om texels op te vragen en daaruit de pixels te berekenen. Volpixelprecisie In een eerste stap berekent worden de blokken met volpixelprecisie als volgt berekend. Door middel van een vertexshader worden de vertices verwerkt en wordt pixeldata gege- 8

20 Vertices - Bewegingsvector - Positie in het vertexrooster Vertexshader Pixeldata - Textuurcoördinaten - Bewegingsvectorrest Pixelshader Pixels Figuur 2.5: Schematische voorstelling van een renderstap bij bewegingscompensatie nereerd bestaande uit een textuurcoördinaat en de bewegingsvectorrest voor elke pixel in de doeltextuur. De vertexshader filtert hierbij de blokken die niet volpixelprecies zijn weg zoals te zien is op Figuur 2.6. Een eenvoudige pixelshader gebruikt de textuurcoördinaten in de pixeldata om een texel op te vragen en door te geven naar het renderdoel. Vertexrooster Aangepast Vertexrooster Vertices Vertexshader Figuur 2.6: Selectie van submacroblokpartities door de vertexshader Halfpixelprecisie De bewegingscompensatie van blokken met halfpixelprecisie wordt opgedeeld in twee stappen: In een eerste stap worden halfpixelprecisieblokken waarvan de bewegingsvectorrest niet voor beide gelijk is aan twee bewegingsgecompenseerd. De niet-relevante blokken worden net zoals in de volpixelprecisie stap weggefilterd. De blokken met een bewegingsvectorrest van twee voor de x-coördinaat worden horizontaal gefilterd. Drie pixels aan beide zijden worden opgevraagd en geïnterpoleerd. Deze horizontale halfpixelinterpolatie is te zien op Figuur 2.7(a). De blokken met een bewegingsvectorrest van twee voor de y-coördinaat worden analoog verticaal gefilterd. Een generieke shader wordt gebruikt die zowel verticale als horizontale halfpixelinterpolatie uitvoert. 9

21 Een tweede stap voert interpolatie uit voor blokken waarvan de bewegingsvectorrest voor beide coördinaten gelijk is aan twee, middelste halfpixelprecisie. Er worden 36 texels opgevraagd en daartussen wordt geïnterpoleerd zoals te zien is op Figuur 2.7(b). Volsampleprecisie Volsampleprecisie Halfsampleprecisie Halfsampleprecisie (a) (b) Figuur 2.7: Halfprecisie-interpolatie. (a) Horizontale halfprecisie-interpolatie. (b) Middelste halfprecisie-interpolatie. Kwartpixelprecisie Voor de kwartpixelprecisiewaarden wordt het gemiddelde genomen van het paar half- en volprecisiepixels dat het dichtst bij de kwartpixel ligt zoals te zien is in Figuur 2.8. Dit proces vereist drie renderstappen. Voor de eenvoud wordt de bespreking rond kwartpixelprecisie bewegingscompensatie beperkt. Chrominantie Interpolatie in de chrominantiekanalen gebeurt op een andere manier. Hier is slechts één shader en slechts één renderiteratie nodig en wordt er geïnterpoleerd tussen de vier omliggende volprecisiepixels. 10

22 Volsampleprecisie Halfsampleprecisie Kwartsampleprecisie Figuur 2.8: Kwartprecisie-interpolatie Overzicht Om een idee te geven van de complexiteit van de verschillende pixelshaders actief in de bewegingscompensatie wordt in Tabel 2.1 het aantal instructies van de verschillende shaders vergeleken. Tabel 2.1: Aantal instructies van de verschillende shaders. arithmetische textuur totaal volpixelprecisie horizontale en verticale halfpixelprecisie midden halfpixelprecisie chrominantie Reconstructie Na bewegingscompensatie wordt aan het bewegingsgecompenseerd beeld residuele data toegevoegd, eveneens door middel van een shader. Het residu is net zoals het beeld opgedeeld in een luminantiekanaal en twee chrominantiekanalen. Bovendien is er voor de residudata 9 bits nodig per pixel, aangezien een voorspelde waarde in principe 255 eenheden van de correcte waarde verwijderd kan liggen en dit zowel positief als negatief. Bij de residutexturen wordt reeds gebruik gemaakt van pixelgroepering. De 9 residubits worden opgesplitst in een meest-significant en een minst-significant deel. De twee resulterende 8-bitwaarden worden dan in de eerste 16 bits van de texel geladen. De overige 16 bits worden analoog opgevuld met de residuwaarde rechts ervan. Zo passen er twee residuwaarden in één texel. 11

23 In de shader die het reconstructieproces uitvoert wordt deze 9-bitwaarde gereconstrueerd uit de twee 8-bitwaarden en wordt ook bepaald welke 16 bits er nodig zijn voor de te berekenen waarde. De drie resulterende texturen worden aan de beeldbuffer toegevoegd voor gebruik in bewegingscompensatie van nog te decoderen beelden Overbemonstering, kleurenruimteconversie en visualisatie In de laatste renderstap wordt via een shader gebruik gemaakt van de drie berekende texturen om overbemonstering en een kleurenruimteconversie naar de RGB-kleurenruimte uit te voeren. Het resultaat wordt naar de een buffer geschreven zodat het op het scherm getoond kan worden. 2.2 Pixelgroepering Uit de vorige sectie blijkt dat de 32-bit texturen die bij de bewegingscompensatie gebruikt worden voor het luminantiekanaal en de twee chrominantiekanalen onderbenut worden. Van de 32 bits die beschikbaar zijn per texel worden er slechts 8 gebruikt. Door gebruik te maken van pixelgroepering kunnen de overige 24 bits ook benut worden, analoog aan wat de pixelgroepering bij de residutexturen. In tegenstelling tot de residutexturen, waar twee 9-bit-waarden in een 32-bit texel worden gegroepeerd, is er per pixel slechts 8 bits van belang en kunnen er dus vier pixels in één texel gegroepeerd worden. Bij het renderen naar deze texturen moeten er nu vier keer minder pixels geëvalueerd worden. De verschillende shaders moeten nu wel vier keer zoveel werk verrichten maar dankzij de SIMD-architectuur (Single Instruction Multiple Data) van de GPU kan dit toch beperkt worden. Met SIMDinstructies kosten de meeste operaties op vectoren even veel als operaties op scalairen. Het aantal textuuropvragingen per shaderuitvoering zal ook niet verviervoudigen omdat we nu vier pixelwaarden met één textuurinstructie kunnen opvragen. 2.3 Conclusie Op het eerste zicht lijkt het erop dat pixelgroepering van de bewegingsgecompenseerde texturen voor een prestatiewinst kan zorgen. Door het groeperen van samples in texels 12

24 worden de texturen kleiner en nemen ze dus minder plaats in beslag in het videogeheugen. Een verkleining van de gebruikte texturen zal ook de gebruikte bandbreedte tussen GPU en videogeheugen verlagen. Door optimaal gebruik te maken van de SIMD-architectuur en de manier van pixelgroepering kan de bijkomende kost beperkt blijven en mag een winst van een factor vier verwacht worden. In het volgende hoofdstuk zullen we onderzoeken of deze stelling ook daadwerkelijk te realiseren is. 13

25 Hoofdstuk 3 Pixelgroepering bij bewegingsgecompenseerde texturen In het vorig hoofdstuk werd al vermeld dat het gebruik van pixelgroepering bij bewegingsgecompenseerde texturen een prestatiewinst zou kunnen opleveren. Aangezien de texturen bij pixelgroepering tot een kwart van hun originele grootte gereduceerd worden moet er dus vier keer minder texels berekend worden. Een prestatiewinst van factor vier lijkt dus aannemelijk. Bovendien eisen kleinere texturen minder plaats op in het videogeheugen, waardoor pixelgroepering noodzakelijk zou kunnen zijn bij HD-videosequenties. In de H.264/AVC-standaard staat beschreven dat de beeldbuffer tot 16 beelden kan bevatten. Voor een 1080p 1 -videosequentie is er dan maar liefst MB videogeheugen vereist voor de beeldbuffer. Tegenwoordig zijn de meeste grafische kaarten wel uitgerust met een geheugen van 256 MB, maar als we bij de beeldbuffer het vertexrooster, de texturen voor de tussenresultaten en het residu, en natuurlijk ook de back- en frontbuffer, is de 256 MB limiet niet meer zo ver af. In dit hoofdstuk wordt eerst een experiment uitgevoerd om een bovenlimiet te vinden voor de prestatiewinst die bij pixelgroepering verwacht mag worden. Vervolgens worden de problemen die ondervonden werden bij het implementeren van de pixelgroeperingarchitectuur besproken. Voor de eenvoud werd de implementatie beperkt tot volen halfpixelprecisie. Uiteindelijk wordt de ontwikkelde implementatie vergeleken met de originele architectuur door middel van enkele prestatiemetingen p refereert naar het 1920x1080 progressieve HD-videoformaat 14

26 3.1 Bovenlimiet voor prestatiewinst Er wordt eerst een bovenlimiet bepaald voor de prestatiewinst die bij pixelgroepering verkregen kan worden om te zien of de performantie daadwerkelijk tot 400% is op te drijven. Voor dit experiment wordt aangenomen dat het aantal aritmetische instructies van de originele shaders een ondergrens vormt voor het aantal instructies van de shaders die bij pixelgroepering zullen gebruikt worden. Dit is aannemelijk aangezien alle berekeningen die in de originele shaders uitgevoerd worden bij pixelgroepering zullen gebeuren. Met het aantal textuuropvragingen wordt wel rekening gehouden omdat geheugenbandbreedte wel eens een cruciale rol zou kunnen spelen. Het gaat hier uitsluitend over pixelshaders. In het experiment en ook bij de uiteindelijke pixelgroeperingarchitectuur wordt niets veranderd aan de vertexshaders Texturen In de originele architectuur wordt slechts één vierde van elke texel benut. Er kunnen dus vier pixels per texel gegroepeerd worden. Dit zorgt ervoor dat de grootte van de texturen bij pixelgroepering tot een vierde van de originele grootte gereduceerd worden. In Figuur 3.1 wordt dit uiteengezet. Het bovenste gedeelte van de figuur toont de voorstelling van 16 pixels in de originele architectuur. Het onderste gedeelte is de voorstelling van dezelfde 16 pixels in de pixelgroeperingarchitectuur. Textuurvoorstelling Texel Sample = Pixelgroepering Figuur 3.1: Textuurbenutting bij pixelgroepering. 15

27 Voor het experiment werd de breedte van de texturen in de beeldbuffer met eerder gedecodeerde beelden en de texturen die gebruikt worden voor de tussenresultaten gedeeld door vier Shaders Het experiment maakt gebruik van shaders die bijna identiek zijn aan die van de originele architectuur. Er werd een kleine aanpassing gemaakt om het gedrag van de textuuropvragingen in de pixelgroeperingarchitectuur te simuleren. Dit wordt gedaan om de computationele complexiteit die louter afhangt van aritmetische instructies te scheiden van eventuele invloeden die door de textuuropvragingen kunnen veroorzaakt worden. Textuuropvragingen zullen doorgaans ook zwaarder doorwegen op de performantie van een shader. Er wordt even stilgestaan worden bij het aantal textuuropvragingen dat bij pixelgroepering nodig zal zijn in elke shader. Textuuropvragingen Om het aantal textuuropvragingen te vinden voor de volpixelprecisie-shader wordt in Figuur 3.2 de opvraging van volpixelprecisiewaarden in de originele architectuur met de opvraging in de pixelgroeperingarchitectuur vergeleken. In Figuur 3.2(a) is de x-coördinaat van de bewegingsvector gelijk aan 0. De pixels moeten niet geïnterpoleerd worden en een kopieeroperatie volstaat. Op Figuur 3.2(b) is de x-coördinaat gelijk aan vier. De opvraging van een textuur is gebonden aan de texels. De hardware laat niet toe dat bijvoorbeeld drie pixels uit texel A en één pixel uit texel B in één textuuropvraging worden opgevraagd. Een dergelijke operatie moet verwezenlijkt worden door twee textuuropvragingen. Ook voor x = 8 en x = 12 zullen er bij pixelgroepering twee textuuropvragingen nodig zijn. Een x-coördinaat gelijk aan 16 komt overeen met het geval in Figuur 3.2(a), een x-coördinaat gelijk aan 20 met het daaropvolgende, enzovoort. Als de x-coördinaat deelbaar is door 16 zal er bij pixelgroepering één textuuropvraging nodig zijn maar in de andere gevallen zullen er twee nodig zijn. In de originele architectuur zijn er voor de shader die zowel horizontale als verticale halfpixelprecisiebewegingscompensatie uitvoert zes textuuropvragingen nodig. Door pixelgroepering is deze operatie niet meer zo generiek te implementeren. Voor verticale en 16

28 Originele Architectuur Originele Architectuur Originele Architectuur Originele Architectuur Pixelgroeperingarchitectuur Pixelgroeperingarchitectuur Pixelgroeperingarchitectuur Pixelgroeperingarchitectuur (a) x=0 (b) x=4 (c) x=8 (d) x=12 Figuur 3.2: Opvraging van pixels uit texels bij volpixelprecisie voor vier verschillende bewegingsvectoren horizontale halfpixelprecisiebewegingscompensatie worden dan ook afzonderlijke shaders gebruikt. De verticale variant wordt in Figuur 3.3 vergeleken met de manier waarop het proces in de originele architectuur gebeurt. Analoog aan de volpixelprecisiebewegingscompensatie zullen er hier zes textuuropvragingen nodig zijn in het geval de x-coördinaat van de bewegingsvector gelijk is aan 0 (Figuur 3.3(a). Voor x = 4 (Figuur 3.3(b)), x = 8 en x = 12 zullen er 12 textuuropvragingen nodig zijn. Dit fenomeen dat zowel in de volpixelprecisie-shader als in de verticale halfpixelprecisie-shader aanwezig is en ook in de andere shaders zal voorkomen wordt verder pixelselectie genoemd. Op Figuur 3.4 wordt de originele architectuur voor de horizontale halfpixelprecisiebewegingscompensatie met de pixelgroeperingsarchitectuur vergeleken. In de originele architectuur (Figuur 3.4(a) worden 6 pixels opgehaald voor interpolatie. Bij pixelgroepering (Figuur 3.4(b) zijn er vier keer zes pixels nodig voor de interpolaties, maar de 17

29 Originele Architectuur Pixelgroeperingarchitectuur Originele Architectuur Pixelgroeperingarchitectuur (a) x=0 (b) x=4 Figuur 3.3: Opvraging van pixels uit texels en interpolering voor verticale halfpixelprecisie bij verschillende bewegingsvectoren meeste benodigde pixels zijn duplicaten. Er zijn zoals te zien op de figuur negen unieke pixels nodig en dus volstaan drie textuuropvragingen. Ook hier treedt er pixelselectie op. De figuur toont de opvraging en interpolatie voor x = 2. De extra pixels die moeten opgehaald worden voor x = 6, x = 10 en x = 14 werden in het rood gekleurd. Rekening houdend met pixelselectie zijn er in totaal maximaal vier textuuropvragingen nodig. De midden halfpixelprecisie-shader is eigenlijk een combinatie van de verticale en horizontale halfpixelprecisie-shaders. Er wordt opnieuw een vergelijking gemaakt tussen de twee architecturen. In de originele architectuur (Figuur 3.5(a)) zijn er 36 textuuropvragingen nodig. In verticale groepen van zes pixels worden ze geïnterpoleerd waarna de resulterende waarden horizontaal geïnterpoleerd worden. Voor de pixelgroeperingsarchitectuur worden in stap één 54 pixels opgevraagd en eveneens in groepen van zes verticaal 18

30 Originele Architectuur Originele Architectuur Pixelgroeperingarchitectuur (a) Pixelgroeperingarchitectuur (b) Figuur 3.4: Opvraging van pixels uit texels en interpolering voor horizontale halfpixelprecisie geïnterpoleerd. Dit is te zien in Figuur 3.5(b). De pixels die nog extra kunnen opgevraagd worden omwille van pixelselectie zijn in het rood gekleurd. Op de geïnterpoleerde waarden worden dan analoog aan de horizontale halfpixelprecisieshader de vier resulterende pixels berekend. Zoals te zien moeten er uiteindelijk 24 texels opgehaald worden. Voor de shader die gebruikt wordt bij de bewegingscompensatie van de chrominantiekanalen zijn er zowel in de originele shader als in de shader die bij pixelgroepering gebruikt wordt vier textuuropvragingen nodig. Het aantal textuuropvragingen in de originele shaders en in de shaders ontworpen voor pixelgroepering worden in Tabel 3.1 uiteengezet. In de eerste kolom wordt het aantal textuuropvragingen in de originele shaders getoond. In de tweede kolom wordt eerst per texel en vervolgens per berekende pixel het aantal textuuropvragingen getoond voor de shaders bij pixelgroepering. Aangezien de nieuwe shaders vier pixels tegelijk berekenen zal dit slechts een vierde zijn van het aantal textuuropvragingen per texel. Per berekende pixel moeten er dus minder textuuropvragingen uitgevoerd worden. Voor het bepalen van de maximale prestatiewinst werd dan ook een stel shaders gebruikt met hetzelfde aantal aritmetische instructies en een aangepast aantal textuuropvragingen. Hierbij werd rekening gehouden met de lokaliteit van de textuuropvragingen zodat de 19

31 Originele Originele Architectuur Architectuur Originele Architectuur (a) Pixelgroeperingarchitectuur Pixelgroeperingarchitectuur Pixelgroeperingarchitectuur (b) (c) Figuur 3.5: Opvraging van pixels uit texels en interpolering voor middelste halfpixelprecisie pixelgroeperingsarchitectuur zo goed mogelijk gesimuleerd wordt. 20

32 origineel pixelgroepering per texel per pixel volpixelprecisie horizontale halfpixelprecisie verticale halfpixelprecisie midden halfpixelprecisie chrominantie Tabel 3.1: Aantal textuuropvragingen bij originele architectuur en pixelgroepering Resultaten Voor het experiment werd gebruik gemaakt van een NVIDIA GeForce 7800 GTX met 256 MB videogeheugen. Voor een uitgebreide specificatie van de testopstelling wordt verwezen naar Appendix B. Het experiment werd uitgevoerd op een reeks beeldsequenties in verschillende formaten: De walk videosequentie met een resolutie van 720x576. De shields videosequentie in 720p 2 -formaat. De blue skies videosequentie in 1080p 3 -formaat. Een gegenereerde sequentie met een resolutie van 2048 op De originele decoder werd vergeleken met de testarchitectuur die in de vorige sectie beschreven staat. In Figuur 3.6 worden de resultaten uiteengezet. Hieruit blijkt dat de maximale prestatiewinst kleiner is dan verwacht. Om de flessenhals te identificeren werd gebruik gemaakt van NVPerfHUD 4, een softwarepakket voor profilering van NVIDIA GPU s. Na profilering met NVPerfHUD blijkt dat voor de 720x576- en 720p-videosequenties de vertexshaders de grootste flessenhals vormen. Het moet gezegd worden dat de metingen die uitgevoerd worden door NVPerfHUD slechts beschouwd mogen worden als ruwe schattingen, maar ze kunnen wel een goed idee geven van de verdeling van het werk tussen de verschillende componenten van de GPU p refereert naar een HD-resolutie van 1280x p refereert naar een HD-resolutie van 1920x

33 originele architectuur testarchitectuur 150 Beeldsnelheid (Hz) x p 1080p 2048x2048 Resolutie Figuur 3.6: Performantie van de originele architectuur tegenover de testarchitectuur Uit de NVPerfHUD-metingen blijkt dat de tijd die besteed wordt aan het evalueren van de pixelshaders ongeveer gehalveerd wordt. De mogelijke prestatiewinst is veel hoger voor de 1080p-videosequentie (230.17%) en de gegenereerde sequentie (235.59%). Vermoedelijk is een gebrek aan bandbreedte in de originele architectuur hiervan de oorzaak. Het bandbreedteverbruik wordt in de volgende sectie onderzocht Bandbreedte-analyse Om een aanvaardbare bandbreedte-analyse uit te voeren wordt voor elke videosequentie het gemiddeld aantal uitvoeringen van elk type shader bepaald. De resulterende percentages zijn te zien in Tabel 3.2. Tabel 3.2: Procentuele pixelverdeling tussen de verschillende shaders. PAL 720p 1080p volpixelprecisie horizontale halfpixelprecisie verticale halfpixelprecisie midden halfpixelprecisie In combinatie met Tabel 3.1 die het aantal textuuropvragingen per shader catalogeert 22

34 kan nu de geheugenbandbreedte die door de bewegingscompensatie gebruikt wordt berekend worden. Ter illustratie wordt de geheugenbandbreedte voor de originele architectuur bij de 1080p-videosequentie berekend. Voor luminantie wordt het aantal pixels vermenigvuldigd met de gewogen som van de textuuropvragingen met de percentages uit Tabel 3.2 als gewichten: ( ) ( ) = Voor de chrominantiekanalen is er slechts één shader. Het aantal pixels wordt vermenigvuldigd met vier (het aantal textuuropvragingen van de chrominantieshader): ( ) 4 = De waarden die voor het luminantiekanaal en de twee chrominantiekanalen berekend werden worden bij elkaar opgeteld en vermenigvuldigd met het aantal bytes in een texel van de gebruikte 32-bit-texturen, namelijk vier: ( ) 4 = Dit resulteert in B ofwel MB aan textuuropvragingen per bewegingsgecompenseerd beeld. De uitvoer van pixels naar texturen zorgt voor een additionele MB wat voor een totaal van MB zorgt. Analoog wordt voor pixelgroepering een bandbreedte van MB per beeld berekend. De bandbreedte die door de pixelshaders bij de bewegingscompensatie gebruikt wordt per bewegingsgecompenseerd beeld wordt in Tabel 3.3 voor 1080p en de andere videosequenties op een rijtje gezet. Tabel 3.3: Bandbreedtegebruik (MB per beeld) bij bewegingscompensatie voor de verschillende videosequenties. 720x p 1080p originele architectuur pixelgroepering Opvallend is dat het verschil tussen de 720x576- en 720p-sequentie bijna verwaarloosbaar is in vergelijking met het verschil tussen de 720p- en de 1080p-sequentie. Dit is vooral te wijten aan het laag percentage van middelste halfpixelprecisie-shader uitvoeringen bij de 720p-sequentie. Van de NVIDIA GeForce 7800 GTX die gebruikt werd in de tests is geweten dat die een gegeheugenbandbreedte heeft van 54.4 GB/sec. Nu is 23

35 het niet ondenkbaar dat aan een snelheid van 50 beelden per seconde deze bandbreedte aanzienlijk benut wordt. Bij bewegingscompensatie wordt dan een bandbreedte van 5.30 GB/sec benut terwijl er bij pixelgroepering amper 1.24 GB/sec verbruikt wordt. Hoewel de benutting bij de originele architectuur slechts 10% is, zal dit toch voor een vertraging zorgen ten opzichte van de 2.3% bij pixelgroepering. 3.2 Architectuur In deze sectie wordt de architectuur van de GPU-renderer die gebruik maakt van pixelgroepering beschreven. Er wordt begonnen met enkele problemen die moeten opgelost worden, namelijk pixelselectie en randcorrectie Pixelselectie In de sectie rond textuuropvragingen (Sectie 3.1.2) in het begin van dit hoofdstuk werd gewezen op het probleem van pixelselectie. Hierbij worden een aantal textuuropvragingen uitgevoerd en worden dan de juiste pixels geselecteerd voor verwerking. Om dit probleem op te lossen zijn er twee mogelijkheden. Ofwel worden eerst de juiste bronpixels uit de texels voor de te berekenen pixels gekozen en wordt daarop de interpolatie uitgevoerd, ofwel wordt de interpolatie uitgevoerd op alle bronpixels en wordt daaruit het juiste resultaat gekozen. Welke techniek voor elk van de verschillende shaders gekozen werd staat beschreven in Sectie Randcorrectie In de H.264/AVC-standaard staat beschreven dat bij bewegingscompensatie het beeld zich gedraagt als een textuur in de Direct3D clamp-textuuradresseringsmodus. Dit wil zeggen dat wanneer er voor interpolatie pixels buiten het beeld nodig zijn, de pixels gebruikt worden die het dichtst bij de opgevraagde coördinaat liggen. In de originele architectuur wordt dit dan ook gerealiseerd door de textuur in clamp-textuuradresseringsmodus in te stellen. Deze modus wordt door de hardware ondersteund en vormt dus geen bijkomende overhead. Bij pixelgroepering geeft dezelfde adresseringsmodus echter de texel die dichtst bij de opgevraagde coördinaat ligt terug. Deze texel bevat echter vier verschillende pixels, 24

36 niet enkel de randpixel. Een modus die bij pixelgroepering de juiste waarden teruggeeft zou: Indien voorbij de linkerzijde van de textuur een texel opgevraagd wordt, de eerste 8 bits van de randpixel teruggegeven. Indien voorbij de rechterzijde van de textuur een texel opgevraagd wordt, enkel de laatste 8 bits van de randpixel teruggeven. Wanneer voorbij de boven- of onderzijde van de textuur bemonsterd wordt, volstaat het gedrag van de normale clamp-textuuradresseringsmodus. Aangezien de GPU in eerste instantie ontworpen is om 3D-werelden weer te geven en pixelgroepering in deze context niet van toepassing is bestaat een dergelijke modus helaas niet. De randcorrectie zal dus in de shaders uitgevoerd moeten worden, hetgeen resulteert in extra instructies evenredig aan het aantal te corrigeren waarden. Randcorrectie kan in sommige gevallen ook na de berekening van het resultaat uitgevoerd worden Shaders De shaders die in het begin van het hoofdstuk getest werden hadden een minimum aantal aritmetische instructies. Door het probleem van randcorrectie en pixelselectie zal een uitbreiding van de shaders niet te vermijden zijn. Bovendien kan door het gebruik van pixelgroepering de horizontale en de verticale halfpixelprecisiebewegingscompensatie niet meer in één renderstap met één enkele shader uitgevoerd worden door het gebruik van pixelgroepering. De manier waarop de berekeningen gebeuren verschillen te drastisch om dit efficiënt te implementeren. Voor de horizontale variant zijn bijvoorbeeld slechts vier textuuropvragingen nodig terwijl de verticale maar liefst 12 textuuropvragingen uitvoert. De horizontale en verticale halfpixelprecisiebewegingscompensatie wordt daarom in afzonderlijke shaders ondergebracht en er zijn dan ook afzonderlijke renderiteraties nodig. Er wordt verwezen naar Appendix C voor codevoorbeelden bij het oplossen van pixelselectie en randcorrectie. Volpixelprecisie De shader voor volpixelprecisiebewegingscompensatie is in de originele architectuur een eenvoudige shader. Er wordt enkel een textuuropvraging uitgevoerd en deze wordt naar 25

37 de uitvoer geschreven. Voor pixelgroepering wordt hieraan een extra textuuropvraging, de randcorrectie en de pixelselectie toegevoegd. Aangezien er niet geïnterpoleerd moet worden in deze shader is er geen sprake van pixelselectie en randcorrectie voor of na de berekeningen. Verticale halfpixelprecisie Voor deze shader zijn twaalf textuuropvragingen nodig. In de originele architectuur waren dit er zes. Omdat er hier geen overlap is tussen de bronpixels die nodig zijn om de vier resulterende pixels te berekenen kan pixelselectie achteraf gebeuren. De interpolering gebeurt loodrecht op de richting waarin de pixels gegroepeerd zijn, waardoor ook randcorrectie achteraf mogelijk is. De reden waarom dit voordeliger is, is omdat pixelselectie en randcorrectie meer instructies opeisen naar mate het aantal te corrigeren waarden stijgt. Indien de correcties vooraf zouden gebeuren zou randcorrectie twaalf texels moeten corrigeren in plaats van slechts twee en zou pixelselectie 24 pixels uit 48 bronpixels moeten selecteren in plaats van vier resultaatpixels uit acht geïnterpoleerde pixels. Horizontale halfpixelprecisie Bij de horizontale variant is er wel overlapping tussen de bronpixels waardoor het voordeliger blijkt de pixels vooraf te selecteren. De pixels worden horizontaal geïnterpoleerd waardoor het niet mogelijk is de randcorrectie achteraf uit te voeren. Het aantal extra instructies blijft toch beperkt aangezien het hier gaat om slechts vier textuuropvragingen. Midden halfpixelprecisie Deze shader bestaat uit twee delen. Een verticale interpolatie gevolgd door een horizontale interpolatie op de geïnterpoleerde waarden. Om dezelfde redenen als bij de verticale en horizontale halfpixelprecisie shaders gebeuren randcorrectie en pixelselectie na de verticale interpolatie en voor de horizontale interpolatie. Chrominantie Bij chrominantie is de interpolatie zowel horizontaal als verticaal. De randcorrectie gebeurt dus vooraf. Er is overigens ook overlapping en dus gebeurt pixelselectie eveneens vooraf. 26

38 Reconstructie De shaders die gebruikt worden om het residu aan het bewegingsgecompenseerde beeld toe te voegen werden eveneens aangepast. In de originele architectuur werd hier een vorm van pixelselectie toegepast aangezien de residutexturen reeds gebruik maakten van pixelgroepering. Twee pixels werden gegroepeerd in één texel. Pixelselectie is hier nu niet meer nodig. Overzicht Het is duidelijk dat pixelselectie en randcorrectie een negatief effect hebben op het aantal instructies van de shaders. Door de branch-instructies die bij pixelselectie en randcorrectie aanwezig zijn treden dan ook meer vertakkingen op. In Tabel 3.4 wordt een overzicht gegeven van het aantal instructies in de originele architectuur in vergelijking met het aantal instructies bij pixelgroepering. Analoog aan Tabel 3.1 worden ook het aantal instructies per pixel vermeld. Tabel 3.4: Aantal instructies bij originele architectuur en pixelgroepering. origineel pixelgroepering per texel per pixel volpixelprecisie horizontale halfpixelprecisie verticale halfpixelprecisie midden halfpixelprecisie chrominantie Hieruit volgt dat per pixel minder instructies uitgevoerd worden. De shaders zouden dus efficiënter moeten zijn. Om een beter zicht te krijgen op de efficiëntie van de verschillende shaders werden de originele shaders tegenover de nieuwe shaders geplaatst. Om de test zo neutraal mogelijk te houden werden de bewegingsvectoren aangepast zodat voor elke geteste shader een volledig beeld wordt berekend. De procentuele prestatiewinst waarvan pixelgroepering geniet is te zien op Figuur 3.7. Voor de meeste shaders werd een winst geboekt die het best merkbaar is wanneer het bandbreedteverbruik hoog is. De uitzondering is de horizontale halfpixelprecisie-shader. Deze shader geniet niet van een voordeel bij het groeperen van de pixels doordat de interpolatie gebeurt in de richting waarin de pixels gegroepeerd zijn en de pixels eerst 27

39 chrominantie volpixelprecisie verticale halfpixelprecisie horizontale halfpixelprecisie middelste halfpixelprecisie 60 Performantiewinst (%) x p 1080p Resolutie Figuur 3.7: Procentuele prestatiewinst van pixelgroepering ten opzichte van de originele architectuur moeten gekopieerd worden voor interpolatie mogelijk is. In de volgende sectie worden de resultaten van de geoptimaliseerde pixelgroeperingsarchitectuur besproken Resultaten In Figuur 3.8 wordt het verschil tussen de beeldsnelheid die verkregen werd bij pixelgroepering vergeleken met de originele architectuur. Het is duidelijk dat voor beelden van lagere resolutie zoals de 720x576- en 720pvideosequentie het gebruik van pixelgroepering een negatief effect heeft. De shaders worden al snel te complex zodat geen prestatiewinst verkregen wordt. Bij beelden van hogere resolutie blijkt de originele architectuur te kampen met een bandbreedteprobleem, wat door pixelgroepering deels verholpen wordt. Voor 1080p-beelden is pixelgroepering 57% sneller en voor de gegenereerde testsequentie stijgt de prestatiewinst tot 115%. 28

40 originele architectuur pixelgroepering Beeldsnelheid (Hz) x p 1080p 2048x2048 Resolutie Figuur 3.8: Beeldsnelheid bij pixelgroepering 3.3 Conclusie Pixelgroepering werd succesvol geïmplementeerd in de GPU-decoder tot op halfpixelprecisie. Voor een uitbreiding naar kwartpixelprecisie kan een gelijkaardige prestatie verwacht worden. De kwartpixelprecisie-shaders zijn combinaties van twee halfpixelprecisie-shaders of volpixelprecisie-shaders. De complexiteit zal dus op een gelijkaardige manier stijgen voor deze shaders. Voor 720p-beelden en beelden van lagere resolutie werd een klein snelheidsverlies gemeten. De beelden blijven echter decodeerbaar in ware tijd. Voor 1080pbeelden en hoger werd bovendien een snelheidswinst verkregen zodat de 1080p-sequentie in ware tijd te decoderen is terwijl dit in de oude architectuur niet het geval was. De bandbreedte blijkt een cruciale factor te zijn in de decodering van HD-beelden. Het is aannemelijk dat de resolutie van videosequenties in de toekomst nog zal toenemen. Er wordt reeds gewerkt aan een UHDV-formaat (Ultra High Definition Video 5 ) dat 16 keer groter is dan het 1080p-formaat. Het efficiënt beheren van geheugen en geheugenbandbreedte door middel van technieken zoals pixelgroepering zal daarom van groot belang zijn

41 Hoofdstuk 4 Antiblokfiltering in de H.264/AVC-standaard Bij de meeste hedendaagse videostandaarden worden beelden gecodeerd door een voorspelling van het beeld te maken op basis van een of meerdere eerder gedecodeerde beelden en daaraan een residu toe te voegen. Dit residu wordt niet gecodeerd in zijn geheel maar als een verzameling blokken. Het is namelijk efficiënter een serie kleine blokken te coderen dan één groot beeld. Langs de kant van de encoder wordt het residu bepaald door de voorspelling van het originele beeld af te trekken. Vervolgens wordt het residu in blokken opgedeeld en op elk blok wordt een Fourriertransformatie toegepast of een andere transformatie die de energie in de linkerbovenhoek van het blok verzamelt. In de H.264/AVC-standaard wordt bijvoorbeeld een variant van de discrete cosinustransformatie gebruikt zodat het resultaat uit gehele waarden bestaat. Het blok wordt gequantiseerd en de resulterende getallen worden via entropiecodering in de videobitstroom opgenomen. Bij de decoder en in de feedbacklus van de encoder wordt een inverse quantisatie gevolgd door een inverse transformatie uitgevoerd om het residu dat gebruikt wordt voor de reconstructie te bekomen. In de volgende sectie wordt even ingegaan op quantisatie en het effect ervan op de beeldkwaliteit. 30

42 4.1 Quantisatie Quantisatie gebeurt in de H.264/AVC-standaard op basis van een quantisatieparameter die de nauwkeurigheid van de quantisatie bepaalt. Een hogere quantisatieparameter resulteert in een hogere compressie, gepaard met een lagere nauwkeurigheid. Het kan dus gebeuren dat er bij quantisatie informatie verloren gaat. In Figuur 4.1 wordt het effect van de quantisatieparameter op een beeld geïllustreerd. (a) (b) (c) (d) Figuur 4.1: Effect van de quantisatieparameter op een beeld. Het originele beeld (a), het beeld gecodeerd met quantisatieparameter 28 (b), 35 (c) en 45 (d) Terwijl voor quantisatieparameter 28 (Zie Figuur 4.1(b)) het gecodeerde beeld een aanvaardbare representatie vormt voor het originele beeld (Zie Figuur 4.1(a)), kan bij quantisatieparameter 35 (Zie Figuur 4.1(c)) al enige artefacten worden opgemerkt en 31