Scalability of MB-level Parallelism for H.264 Decoding

Transcription

1 Scalability of Macroblock-level Parallelism for H.264 Decoding Mauricio Alvarez Mesa 1, Alex Ramírez 1,2, Mateo Valero 1,2, Arnaldo Azevedo 3, Cor Meenderinck 3, Ben Juurlink 3 1 Universitat Politècnica de Catalunya (UPC). Barcelona. Spain 2 Barcelona Supercomputing Center (BSC). Barcelona. Spain 3 Delft University of Technology (TUD). Delft. The Netherlands December 15, 2009

2 Outline Introduction 1 Introduction 2 3 4

3 Trends in digital video Towards high quality systems High definition video and high quality video codecs High computational complexity Towards Mobile and Integrated systems Convergence of mobile and multimedia systems Real-time, area and power constraints. Towards multiple formats and extensions: H.264 extensions and different video codecs (MPEG-2, VC-1) Programmable processors instead of application specific hardware

4 Trends in multicore computer architecture Towards manycore systems Hundreds of cores on a chip Power and complexity wall: simpler cores Massive Thread Level Parallelism Towards heterogeneous/asymmetric architectures Asymmetric cores: same ISA but different performance Heterogeneous cores: accelerators for different application domains Specialized architectures have better performance/power/area benefits

5 Challenges of video applications in the multicore era Requirements of digital video applications: Performance: High quality video translates in high computational complexity Efficiency: Embedded environments impose real-time and power constraints. Flexibility: Multiple video formats and new extensions requires programmability. Opportunities of multicore architectures Scalability Applications can benefit from multicores only if they can be parallelized

6 Outline Introduction H.264 video decoder Macroblock-level parallelism Theoretical Maximum Speed-up Abstract Trace-driven Simulation 1 Introduction 2 H.264 video decoder Macroblock-level parallelism Theoretical Maximum Speed-up Abstract Trace-driven Simulation 3 4

7 H.264 Decoder Introduction H.264 video decoder Macroblock-level parallelism Theoretical Maximum Speed-up Abstract Trace-driven Simulation Block based: MBs are the basic coding unit. Hybrid: motion compensation + transform coding (DCT)

8 MacroBlock-level parallelism H.264 video decoder Macroblock-level parallelism Theoretical Maximum Speed-up Abstract Trace-driven Simulation 2D-wave processing order satisfies MB dependencies and allows to exploit TLP. Scalability depends on frame resolution

9 Parallel model Introduction H.264 video decoder Macroblock-level parallelism Theoretical Maximum Speed-up Abstract Trace-driven Simulation Each frame in a video sequence can be represented with a finite Directed Acyclic Graph (DAG): Each node in the DAG represents the decoding of one MB by one processor.

10 Theoretical maximum performance 1 H.264 video decoder Macroblock-level parallelism Theoretical Maximum Speed-up Abstract Trace-driven Simulation Parallel macroblocks Time The maximum speedup can not be reached because: MB processing time is variable and input dependent Thread synchronization time is not negligible load unbalance and synchronization overhead 1 Meenderinck et al. Parallel Scalability of Video Decoders

11 Effects of variable decoding time H.264 video decoder Macroblock-level parallelism Theoretical Maximum Speed-up Abstract Trace-driven Simulation constant time blue_sky pedestrian riverbed rush_hour 26 speedup Number of frames Average speedup reduction: 33% Actual performance depends on input content

12 H.264 video decoder Macroblock-level parallelism Theoretical Maximum Speed-up Abstract Trace-driven Simulation Effects of thread synchronization overhead blue_sky pedestrian riverbed rush_hour speedup Overhead as a factor of MB decoding time Speedup reduction: 38%, when overhead = MB decoding time Observed overhead is greather than MB decoding time

13 Outline Introduction Experimental Platform Performance Analysis Removing the bottlenecks 1 Introduction 2 3 Experimental Platform Performance Analysis Removing the bottlenecks 4

14 Parallel architecture: SGI Altix Experimental Platform Performance Analysis Removing the bottlenecks Base module: 2 dual core Intel Itanium2 2 Distributed Shared Memory (cc-numa) 2 Rusu S., Circuit Technologies for Multi-Core Processor Design

15 Benchmark: HD-VideoBench 3 Experimental Platform Performance Analysis Removing the bottlenecks HD-VideoBench Test sequences: Full High Definition (FHD), 100 frames, 25 fps. H.264 decoder: FFmpeg modified for MB-level parallelization. 3

16 Programming model Experimental Platform Performance Analysis Removing the bottlenecks Single Program Multiple Data: SPMD N+2 threads: 1 master, 1 CABAC, N workers Task pool for dynamic load balancing

17 Scheduling strategies Experimental Platform Performance Analysis Removing the bottlenecks Static scheduling Master thread: Checks the dependencies and inserts work in the task queue. Worker threads: Process tasks and update dependencies Dynamic scheduling Master thread: Inserts the first MB in the task queue and waits for the last MB. Worker threads: take work from the task queue, process tasks, update dependencies and insert ready MBs in the task queue Tail-submit: If at least one MB is ready process it directly

18 Speedup and scalability Experimental Platform Performance Analysis Removing the bottlenecks tail submit right-first tail submit down-left-first static scheduling dynamic scheduling Average Speedup Number of threads Static scheduling: load unbalance Dynamic scheduling: suffers from synchronization overhead Tail submit: reduces sync. overhead and exploits data locality

19 Profiling analysis Introduction Experimental Platform Performance Analysis Removing the bottlenecks Sync. overhead ratio [factor of MB decoding time] dynamic_scheduling_wo_tailsubmit dynamic_scheduling_w_tailsubmit Number of threads Significant reduction of synchronization overhead Submitting new tasks to the task queue is the main source of overhead

20 Experimental Platform Performance Analysis Removing the bottlenecks Impact of the CABAC entropy decoder control_thread hl_decode_mb decode_cabac Execution Time [us/frame] Number of threads CABAC should be executed sequentially. CABAC execution time behavior a side effect of the cc-numa architecture.

21 Experimental Platform Performance Analysis Removing the bottlenecks Identifying the acceleration requirements A scalable MB-level parallelization requires: Remove the CABAC bottleneck Low latency synchronization primitives. These limiting factors offer a potential for multicore acceleration Multicore acceleration evaluation: Dedicated and accelerated CABAC processor On-chip hardware supported synchronization Evaluated using a fast trace-driven multicore simulation

22 Experimental Platform Performance Analysis Removing the bottlenecks Accelerating CABAC entropy decoding 25 Speed-up Frames per second Number of processors (+1 master) cabac- 1.0X cabac- 1.5X cabac- 2.0X cabac- 3.0X cabac- 4.0X cabac- 5.0X cabac-10.0x real-time 25 fps real-time 50 fps real-time 100fps FHD 25 fps: CABAC 1X, 7 worker processors FHD 50 fps: CABAC 1.5X, 16 worker processors FHD 100 fps: not enough parallelism

23 Accelerating thread synchronization Experimental Platform Performance Analysis Removing the bottlenecks 25 Speed-up Frames per second Number of processors (+1 master) 1ns 10ns 100ns 500ns 1000ns 5000ns 10000ns sync-altix-1p sync-altix-sw real-time 25 fps real-time 50 fps real-time 100fps Altix sync. time: ns; without contention: ns FHD 25 fps : sync. latency 500 ns, 7 workers FHD 50 fps : sync. latency 100 ns, 16 workers

24 Outline Introduction Backup slides 1 Introduction Backup slides

25 Introduction Backup slides Limitations to scalability load unbalance synchronization overhead CABAC sequential bottleneck Implementation on a cc-numa machine Best scheduling strategy: dynamic scheduling + Tail-submit Acceleration potential Estimation of the required CABAC acceleration Limits of latency of thread synchronization

26 Acknowledgements Introduction Backup slides This work has been supported by: HiPEAC. European Network of Excellence on High Performance and Embedded Architecture and Compilation The European Commission in the context of the SARC project (contract no ) The Spanish Ministry of Education (contract no. TIN ).

27 Trace-driven DAG simulator Backup slides DAG Simulator Creates the DAG for each frame in the video using real execution traces Calculates the Task Processing Time (TPT) of every node as: TPT (n) = w n + s n + MAX (TFT (pr n )) (1) w n : the time required to process the task s n : the time required for thread synchronization; MAX (TFT (pr n ) is the maximum task finish time (TFT) of the immediate predecessors tasks of that task.

28 Backup slides Base architecture: dual core itanium2 processor Intel Itanium2 processor 1,6GHz, 90nm 16 KB I-L1, 16 KB D-L1 cache per core 1MB I-L2, 256 KB D-L2 cache per core Shared 8MB (I+D)-L3 8 GB of RAM