# Architecture Exploration of a Backprojection Algorithm for Real-Time Video SAR
## 3 Architecture Exploration for Backprojection Based Video SAR
### Multi-Stream Based BPA Acceleration  
A GPU device has an execution engine, copy engines, a memory controller, and high-speed memory. The execution engine consists of many parallel processors called a multiprocessor in Nvidia terms. The copy engines are connected to the PCIe bus and transmit data between the host and GPU using direct memory access (DMA) controllers. The GPU device used for our study has one execution and six copy engines. Because these engines work independently, their operation can be overlapped in different streams. A stream in CUDA is a sequence of operations that execute on the device in the order in which the host issues them. All device operations, including kernels and data transfers in CUDA, run in a stream. Therefore, the BP-VISAR algorithm is executed in a stream in the order of H2D data transfer, range compression, image formation, and D2H data transfer. The execution stages of BP-VISAR can be categorized into two groups according to the hardware used in the device. The first is the computation group consisting of the range compression, image formation, and post-processing executed by the execution engine. The second is the data transfer group consisting of the H2D and D2H data transfers, which invokes the copy engines responsible for controlling DMAs between the host and the device irrespective of the CUDA kernel engine. All the BP-VISAR architectures with full or sub-aperture processing are designed in a single stream as in the previous sections. In a single stream execution of the BP-VISAR pipeline, because the operations of copy or kernel engines are blocked by the others, the execution engine and copy engines are not fully utilized. This is because the execution and data transfer operations are running in the order shown in Figures 4 and 5. For example, the execution engine may be idle if the range profile data is not transferred from the host in Arch. F2 and Arch S2. The execution engine cannot run for the next frame generation until the current frame is generated and transferred to the host. However, it is likely that the copy engines stay mostly in an idle mode because the BP-VISAR pipeline is computation-limited. Therefore, if the kernel execution and the data transfer in different streams overlap, the overall throughput can be improved over the single-stream architecture. To improve the performance of BP-VISAR, we propose a multi-stream BP-VISAR architecture with N-way concurrency as in Figure 6, which overlaps kernel execution and data transfers. We selected Arch. S3 as the reference single stream architecture due to its prominent performance, which is explained in the later section. The multi-stream processing architecture of BP-VISAR, Arch. S3-N, is designed by enabling N-way concurrency for generating video frames. The execution process of the BP-VISAR is not bandwidth-limited but computation-limited from the profiling results in Tables 2 and 3 or the performance measurement of Arch. S3, which is presented in the experimental section. Kernels are queued into the compute queue and executed in the order of their launching times. While executing the \begin{table}
\begin{tabular}{c c c} \hline \hline
**Processing Stage/Buffer** & **Non-Overlapped** & **Overlapped** \\ \hline I/O (source) & \(8 Kf_{PRF}\) & \(8 Kf_{PRF}\) \\ I/O (feed) & \(8 KN_{p}\gamma\) & \(8 KN_{p}(1-\alpha)\gamma\) \\ range compression & bandwidth & \(8N_{FFT}N_{p}\gamma\) & \(8N_{FFT}N_{p}(1-\alpha)\gamma\) \\ image formation & \(8N_{0}^{2}M_{\gamma}\) & \(8N_{0}^{2}M(1-\alpha)\gamma\) \\ post-processing & \(8N_{p}^{2}\gamma\) & \(8N_{p}^{2}\gamma\) \\ \hline SFB & buffer size & \(8N_{0}^{2}M\) & \(8N_{0}^{2}M\) \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Bandwidth in the BP-VISAR architectures with sub-aperture processing. image formation kernel in the GPU, the execution engine allocates all the available CUDA cores to the kernel threads because the number of threads for the kernel is larger than the number of CUDA cores in the GPU device.