Mercurial > pygar
changeset 74:31fef269ae58 pygar svn.75
[svn r75] presentation for wednesdaty
author | rlm |
---|---|
date | Wed, 12 May 2010 02:25:34 -0400 |
parents | 0f86d486e38e |
children | a15cc186e07d |
files | documents/Pygar-slides.odp documents/pygar-slides-handout.lyx documents/pygar-slides.pdf |
diffstat | 3 files changed, 217 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
1.1 Binary file documents/Pygar-slides.odp has changed
2.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000 2.2 +++ b/documents/pygar-slides-handout.lyx Wed May 12 02:25:34 2010 -0400 2.3 @@ -0,0 +1,217 @@ 2.4 +#LyX 1.6.4 created this file. For more info see http://www.lyx.org/ 2.5 +\lyxformat 345 2.6 +\begin_document 2.7 +\begin_header 2.8 +\textclass article 2.9 +\use_default_options true 2.10 +\language english 2.11 +\inputencoding auto 2.12 +\font_roman default 2.13 +\font_sans default 2.14 +\font_typewriter default 2.15 +\font_default_family default 2.16 +\font_sc false 2.17 +\font_osf false 2.18 +\font_sf_scale 100 2.19 +\font_tt_scale 100 2.20 + 2.21 +\graphics default 2.22 +\paperfontsize default 2.23 +\use_hyperref false 2.24 +\papersize default 2.25 +\use_geometry false 2.26 +\use_amsmath 1 2.27 +\use_esint 1 2.28 +\cite_engine basic 2.29 +\use_bibtopic false 2.30 +\paperorientation portrait 2.31 +\secnumdepth 3 2.32 +\tocdepth 3 2.33 +\paragraph_separation indent 2.34 +\defskip medskip 2.35 +\quotes_language english 2.36 +\papercolumns 1 2.37 +\papersides 1 2.38 +\paperpagestyle default 2.39 +\tracking_changes false 2.40 +\output_changes false 2.41 +\author "" 2.42 +\author "" 2.43 +\end_header 2.44 + 2.45 +\begin_body 2.46 + 2.47 +\begin_layout Title 2.48 +Pygar: Parallel Audio Processing 2.49 +\end_layout 2.50 + 2.51 +\begin_layout Author 2.52 +Laurel Pardue, Robert McIntyre 2.53 +\end_layout 2.54 + 2.55 +\begin_layout Subsection* 2.56 +Problem 2.57 +\end_layout 2.58 + 2.59 +\begin_layout Standard 2.60 +Music naturally comes in parallel sequences of samples called 2.61 +\emph on 2.62 +voices 2.63 +\emph default 2.64 + (ex. 2.65 + from multiple instruments). 2.66 + Pure-software mixers are forced to pass these voices through the Von Neuman 2.67 + bottleneck of a single processor, operating on these streams in series 2.68 + and switching between each one quickly. 2.69 + They are therefore naturally limited in the number of voices they can handle. 2.70 + Worse, since the processing of each voice has to share the same processor, 2.71 + too many voices at once can fully max out the processor and crash the system. 2.72 + On typical laptop hardware and a high end software tool like ProTools, 2.73 + this number is around 5. 2.74 + Embedded devices have an even tougher time at meeting any sort of reasonable 2.75 + timing requirements. 2.76 +\end_layout 2.77 + 2.78 +\begin_layout Standard 2.79 +[screenie Just 6 voices are enough to bring this session of ProTools to 2.80 + it's knees.] 2.81 +\end_layout 2.82 + 2.83 +\begin_layout Standard 2.84 +We want the power of writing transforms for voices in a high level language 2.85 + combined with a framework that applies these transforms to the voices in 2.86 + parallel. 2.87 +\end_layout 2.88 + 2.89 +\begin_layout Subsection* 2.90 +Vision --- Pygar 2.91 +\end_layout 2.92 + 2.93 +\begin_layout Standard 2.94 +Our system addresses the limitations of pure software mixers. 2.95 + It is a grid of SMIPS processors capped by a mixer. 2.96 + The voices flow through the processors in parallel and are combined at 2.97 + the final mixer into a single stream. 2.98 + Each processor can be loaded with any arbitrary C program. 2.99 +\end_layout 2.100 + 2.101 +\begin_layout Standard 2.102 +\begin_inset Float figure 2.103 +placement H 2.104 +wide false 2.105 +sideways false 2.106 +status collapsed 2.107 + 2.108 +\begin_layout Plain Layout 2.109 +\begin_inset Graphics 2.110 + filename ../../../../Pygar/documents/000402.png 2.111 + width 5in 2.112 + 2.113 +\end_inset 2.114 + 2.115 + 2.116 +\begin_inset Caption 2.117 + 2.118 +\begin_layout Plain Layout 2.119 +The audio data (“samples”) start in the memory, but are soon pulled into 2.120 + action by the DMA (direct memory access). 2.121 + The DMA sends the samples to a chain of 0 or more soft-cores, where they 2.122 + are transformed according to the soft-cores’ algorithms. 2.123 + After running the gauntlet of soft-cores, the samples flow first to a buffering 2.124 + FIFO, and finally to a mixer, which sends the samples off to be played 2.125 + by speakers or stored in a file. 2.126 + 2.127 +\end_layout 2.128 + 2.129 +\end_inset 2.130 + 2.131 + 2.132 +\end_layout 2.133 + 2.134 +\begin_layout Plain Layout 2.135 + 2.136 +\end_layout 2.137 + 2.138 +\end_inset 2.139 + 2.140 + 2.141 +\end_layout 2.142 + 2.143 +\begin_layout Subsection* 2.144 +Steps 2.145 +\end_layout 2.146 + 2.147 +\begin_layout Standard 2.148 +The difficult part of this project is managing code reuse. 2.149 + We need three things for success. 2.150 + 2.151 +\end_layout 2.152 + 2.153 +\begin_layout Itemize 2.154 +SMIPS processor -- Easy. 2.155 + Just use the Lab 5 processors. 2.156 +\end_layout 2.157 + 2.158 +\begin_layout Itemize 2.159 +Some way to program the processors 2.160 +\end_layout 2.161 + 2.162 +\begin_layout Itemize 2.163 +DMA (Direct Memory Access) to load voices into the processors. 2.164 +\end_layout 2.165 + 2.166 +\begin_layout Standard 2.167 +We use ScratchPad to load code into the processors. 2.168 + ScratchPad is an Intel module which implements a cache hierarchy. 2.169 + The hierarchy reaches all the way from RAM created on the FPGA to on-chip 2.170 + DRAM to RAM on the host computer all the way to the Hard Disk of the host 2.171 + computer. 2.172 + The first time a processor tries to access one of its instructions, the 2.173 + cache goes all the way to the hard disk of the host computer to retrieve 2.174 + the data. 2.175 + Subsequent attempts to access this data only go as far as the on-chip DRAM. 2.176 + Each processor has its own ScratchPad and thus can be programmed independently. 2.177 + The ScratchPad abstraction allows each processor to run a program of any 2.178 + size. 2.179 +\end_layout 2.180 + 2.181 +\begin_layout Standard 2.182 +Music access is achieved through RRR, another Intel abstraction which allows 2.183 + us to treat the hard disk of the host computer as if it were a normal FIFO. 2.184 +\end_layout 2.185 + 2.186 +\begin_layout Subsection* 2.187 +News 2.188 +\end_layout 2.189 + 2.190 +\begin_layout Standard 2.191 +We have run our system with 12 sample voices and various combinations of 2.192 + simple c voice processing programs and the results have been better than 2.193 + software implementations. 2.194 + Significantly, increasing the number of voices does not increase the processing 2.195 + load since each voice is processed in parallel. 2.196 +\end_layout 2.197 + 2.198 +\begin_layout Subsection* 2.199 +Contributions 2.200 +\end_layout 2.201 + 2.202 +\begin_layout Itemize 2.203 +Implemented Pygar, a system for quick parallel processing of audio. 2.204 + 2.205 +\end_layout 2.206 + 2.207 +\begin_layout Itemize 2.208 +Implemented 4 basic algorithms which serve as components for this system 2.209 + (identity, bit-shift, volume-change, and delay) 2.210 +\end_layout 2.211 + 2.212 +\begin_layout Itemize 2.213 +Demonstrated Pygar out-performs software-only systems. 2.214 + Pure-software systems have a limit of around 6 voices, while our system 2.215 + achieves 12 voices in parallel with no architecturally imposed limit on 2.216 + the number of voices. 2.217 +\end_layout 2.218 + 2.219 +\end_body 2.220 +\end_document
3.1 Binary file documents/pygar-slides.pdf has changed